Prevent browser from prompting for client certificate for IIS app - iis

We have an application deployed to IIS and every time we connect to it, we get the following browser prompt:
Select a certificate to authenticate yourself to sitename
We do not have a reason to challenge for a client certificate and seems like this setting was introduced by mistake
How can we remove it?
Research:
This question on How can I prevent browsers from prompting Users for a Client Certificate? looks similar, but doesn't have an answer yet, and also is about setting this up on kestrel-http-server
This question on Browser is not prompting for a client certificate is for how to make sure there is a prompt, and didn't provide enough hints as to how to prevent one

Open IIS and navigate to your web site or application and go to the SSL settings
Set the Client Certificate setting to "Ignore"
Both 'Accept' and 'Require' will both challenge for a client side cert
Recycle your app pool and re-launch your browser to test
Note: SSL settings are inherited from your Site > Application, so you may need to apply these SSL Settings at multiple levels
Further Reading:
Why does google chrome prompts to "select a certificate to authenticate yourself"
How to prevent browser from prompting for a client certificate and allow the IIS to accept it (not require it)?

Related

IIS Client Certificate is Not Accepting, Not getting any Certificate Prompt

In one of my applications, I enabled the configuration on IIS to accept the client certificate, by enabling like the below picture. The same configuration I did on the local IIS server and it works.
but it's not working. Any configuration that I am missing..?? At least it should prompt for the Certificate.
It will prompt the client to provide a certificate only when accessing https:
You need to check whether to access the service via https.
I think you need to install the cert in cert store in current user for the browser to show up the dialog box with list of certificates

Client certificate authentication on IIS 8 - 401.1 Unauthorized

We are developing ASP.NET application and we need to use Client Certificate Authentication on IIS 8.
I followed guides to setup SSL and Client Certification authentication.
https://blogs.msdn.microsoft.com/asiatech/2014/02/12/how-to-configure-iis-client-certificate-mapping-authentication-for-iis7/
and
https://blogs.iis.net/rlucero/iis-7-walkthrough-one-to-one-client-certificate-mapping-configuration
I've setup client certificate and added one-to-one mapping to map it to local administator account (once it works, i will change it to more resticted user).
I validated that both server and client certificate are valid and trusted on server and on clinet. So there is no problem with certification authority.
When i try to acces the web page i am promted to choose client certificate. When i confirm selected certificate i allways get 401.1 result: Unauthorized.
I think that it can be related with that in IIS Authentication settings i disabled all authentication types. When i enable Windows Authentication, it seems to work - I am prompted to select certificate and when i confirm selected certificate, i am prompted for username and password and then page is displayed correctly. Of course i do not want user to enter windows user name and password.
PS: Error log file from IIS is here https://www.dropbox.com/s/pe8qwxpgilr347l/fr000156.xml?dl=0
Thank you for any tips.
In my case, i needed to install and activate "client certificate mapping authentication" in Windows Server Manager "Roles and Features" and the IIS configuration editor here: system.webServer/security/authentication/clientCertificateMappingAuthentication

MVC 5 Intranet Application - your connection to this site is not private

I built out a few applications - published intranet environment - and all of them are prompting for a username and password in order to access the application (connection to this site is not private).
I am not sure if this is an IIS Setting that needs to be adjusted, I have tried adding everything on my end with the web config settings. Even explicitly turning authentication off and allowing anonymous users, does not do anything.
So my main question is could this security prompt feature be turned off through IIS since the application web.config is yielding no results?
I have the default settings that visual studio generates along with my database connection string.
There's two different things here. First, the prompt is because Anonymous Authentication is not enabled. If you don't want any sort of authentication or authorization, you can simply enable that. However, more likely, since this is an intranet, you do actually want people to be authenticated; you just don't want them to have to "login". For that, you should enable Windows Authentication.
The second piece, "Your connection to this site is not private", is either because you're running on HTTP, rather than HTTPS, or you are using HTTPS, but don't have a valid SSL cert. The latter is a very common issue in intranet scenarios, since there's usually not a public domain you can bind a cert to. In that scenario, you need to generate a self-signed cert and install it on all machines that need to access the site. Alternatively, you can set up your own internal CA, such that you can issue and validate your own internal certificates.
In either case, the message is there to let the user know that communication with this site will not be encrypted, so sensitive things, like say a username and password, will be transmitted in plain-text and can therefore be intercepted by monitoring the network traffic. That may or may not be a concern for your intranet environment, but the message is not internet/intranet-specific.

Setting up secure web sockets (wss) service for my https web app

I have this web app that is served via https, and now it needs to use a websocket service that is served from another server. Chrome, Firefox and Internet Explorer complain right away that if the application is secure (https), then it is not allowed to connect to an insecure websocket service (ws:// URI). Strangely, Apple Safari doesn't complain so.
Well, fair enough, I assumed any globally trusted certificate would be fine to be installed at the websocket server side, to enable secure service (wss:// URI). However the company that maintains the socket server claims that they have to install there the very same certificate that secures my web application. I read in webs that the wss will not run with self-signed certificate, but nowhere that it must be the same certificate that the calling web site runs on.
Since we are talking sharing a certificate key file with 3rd party, I wanted to double check this. If my secure site runs at domain first.com, and the websocket server at IP address a.b.c.d, what kind of certificate should be installed on the websocket server to enable the communication? On one hand, that would be a kind of cross-site scripting, but perhaps the browser security model allows it, assuming the user knows what they want?
What I understand from above, the browser connects to your web application and is then redirected to the other server. If that be the case, then browser would complain about being redirected to unsecured site from a secured URL. The way forward actually depends on the domain of the server that the redirect is happening to, for example, if your main site has URL form www.mainsite.com and the target site has URL form abc.secondsite.com or an IP, the second server must have configured an SSL certificate that has been issued to either abc.secondsite.com of the IP i.e. the name of the host requested must match exactly with the SSL ceritficate that is provided by the secondsite.
The secondsite technically does not have to have the same certificate as your mainsite, it just have to be a certificate issued by a trusted source (like Verisign etc.).
On the other hand, if you have a wildcard subdomain certificate i.e. a certificate issues is valid for all the *.mainsite.com domains and the URL form of the secondsite is sub_domain.mainsite.com, then the same certificate can be used on both the servers.
Hope this helps.
thanks
Since we are talking sharing a certificate key file with 3rd party, I
wanted to double check this. If my secure site runs at domain
first.com, and the websocket server at IP address a.b.c.d, what kind
of certificate should be installed on the websocket server to enable
the communication? On one hand, that would be a kind of cross-site
scripting, but perhaps the browser security model allows it, assuming
the user knows what they want?
You cannot provide a certificate for an IP address. In order to use WSS:// you need to connect to a domain name, and have a valid certificate for that domain name. So you need a SSL certificate for the domain name of your WebSocket server.
As far as I know, it does not need to be the same than the one on the site. You can check by entering here: http://vtortola.github.io/ng-terminal-emulator/ and executing the command websocket wss://echo.websocket.org, you will connect to a WebSocket in websocket.org that echoes your inputs.
WebSockets are not constrained by the SOP (Same Origin Policy), you can connect anywhere, and the server is responsible of checking the HTTP request header "Origin" and accept or refuse the connection.

How Web broswer's ssl works

When a user selects using the ssl of web browser, for example,
a user selects the option of using ssl in FireFox, how the Web browser sets the ssl connection? Does the browser has a public key ?
The browser has public keys from root certificate authorities. If a key from a website is signed by one of the root CA's in the browser, it can be verified as trustworthy automatically and ssl communication can start. Otherwise, you get prompted by the unknown/self-signed certificate dialog and decide for yourself whether to trust it or not.
When a user selects the option of using ssl in firefox,it allows the the browser to establish connection with ssl enabled websites.The browser has a set of root certificate authorities like verisign which are well known around the world.So when a website gives a certificate signed by these CAs then our browser automatically recognizes the identity of the website.However,if that certificate is signed by a unknown authority ,then the browser gives a pop-up of unknown certificate and it depends on the user to trust it or not.If you trust it then it gets installed in your browser and that pop up does not come up the next time you connect to that website.Similarly,some websites require client certificates in order to recognize the client.In that case,you need to install your certificate(generally provided by them to a set of users) in the browser so that those websites can identify you.You can say that it is a two communication and involves exchange of certificates from both server and client.

Resources