For development, my team is using a self-signed SSL certificate. After installing the certificate in my machine's Trusted Root Certification Authorities store, the SSL certificate is recognized as valid in Chrome and IE 11:
Internet Explorer 11:
Chrome 69:
But Edge (version 42) seems to be ignoring the certificate:
Based on the message I'm getting from Edge ("This might be because the site uses outdated or unsafe TLS security settings"), I thought that my local development server might be using an outdated TLS version, but I can verify in Chrome's development tools that traffic is being encrypted using TLS 1.2:
Why does Edge seem to be ignoring my self-signed certificate that I have installed as a Trusted Root Certificate? How can I fix it?
Things I've tried:
Installing the same certificate in my Personal and Intermediate Root Certification Authorities stores
Restarting my machine
After quite a bit of investigation, we discovered the root cause - our company's antivirus software (Sophos) is blocking Edge (and only Edge) from reaching internal IP addresses. Edge's error message - "outdated or unsafe TLS security settings" - was misleading; Edge's requests weren't able to make it to the wire at all.
Try to follow steps below may help you to solve the issue.
(1) Open Run window and type 'inetcpl.cpl' to open Internet properties.
(2) Go to 'Security' tab.
(3) Click on 'Custom level' button.
(4) Find option for 'Display mixed content'.
(5) Enable it.
Then go to 'Advanced' tab in the same dialog.
Verify that below options are checked.
If it is not checked then check it and apply the changes and click on ok button.
If you are using outdated network drivers then also this issue can occur. so try to check that you are using the latest drivers.
Related
On a particular website, in firefox, I click the lock in the address bar to see if the connection is secure. It is reported secure, see first image, it also says which CA verified the certificate. All seems well but if I click on more information, i get what is shown on the second image, firefox suddenly reports that the site is not encrypted. The website runs on IIS. This happens with both internal CA issued certificate (the ca is imported into firefox as trustworthy root) as well as with letsencrypt issued certificate. Neither internet explorer nor chrome find any anomalies and report the site as trustworthy and all certificates in order. Why is this happening and what kind of problem does this indicate? (i have another server at the same site running also IIS with exchange where the certificate shows correctly in firefox)
I'm adding Google reCaptcha v3 to my J2EE application that runs under WebSphere 6.1. (I know, its no longer supported. A software upgrade is on the plan, just not immediately.)
I've followed the steps below to add the www.google.com:443 cert to WebSphere's NodeDefaultTrustStore, and after restarting WebSphere, the SSL cert is accepted no problem. My servlet code that does the reCaptcha verify logic works fine and all is well.
However, the following day, the certificate I imported is no longer accepted. When I import it again, I see that the Fingerprint (SHA digest) is different than the previous day. It looks like Google changes their SSL cert on a daily basis. Is this true? If so, how do I get around this problem in WebSphere?
CWPKI0428I: The signer might need to be added to the local trust store.
You can use the Retrieve from port option in the administrative console to retrieve the certificate and resolve the problem.
If you determine that the request is trusted, complete the following steps:
Log into the administrative console.
Expand Security and click SSL certificate and key management.
Under Configuration settings, click Manage endpoint security configurations.
Select the appropriate outbound configuration to get to the (cell):ServerNode01Cell:(node):ServerNode01 management scope.
Under Related Items, click Key stores and certificates and click the NodeDefaultTrustStore key store.
Under Additional Properties, click Signer certificates and Retrieve From Port.
In the Host field, enter www.google.com in the host name field, enter 443 in the Port field, and www.google.com_cert in the Alias field.
Click Retrieve Signer Information.
Verify that the certificate information is for a certificate that you can trust.
Click Apply and Save.
"Retrieve from port" adds the leaf certificate. To do something more reliable, trust the issuer. The current issuer for is GlobalSign root CA R2 which you can grab from https://pki.goog/ (GS Root R2)
Unfortunately it is hard to automate grabbing the root CA in tools like "retrieve from port" because many SSL toolkits do not send the root CA over the wire during the handshake -- because the client should already have it.
Here's an approach for WebSphere Liberty that might work for 6.1, I haven't tried it.
https://www.ibm.com/support/knowledgecenter/en/SSEQTP_liberty/com.ibm.websphere.wlp.doc/ae/twlp_add_trust_cert.html
Use the openssl method but take the -second- certificate in the list (which doesn't expire until 2021).
We have installed the certificate chain on our Load balancer. When we visit the site in chrome, we don't get any issue and the chain in visible.
But, in certain versions of Firefox the certificate chain is not displayed and hence we get the "The connecting is untrusted error".
What could be causing this, we have cleared the cache. But the certificate is not getting displayed with the chain.
This is typically the case if the chain is not send (fully) by the server (or in this case the load balancer). Chrome looks for this missing chain certificates by itself while Firefox does not. But Firefox caches intermediate certificates from earlier connections to other sites so if the right sites were visited before then the missing certificates are already known by Firefox and will be used to complete the trust chain. But if you would use a fresh Firefox profile no certificates are cached and thus you get the validation error.
Browsers are not a good tool to check what is actually sent by the server. A better tool is openssl s_client. If the site is public accessible you might also check it against SSLabs which also shows if the chain sent by the server is incomplete and which certificates are missing from the chain.
Background:
I am updating an internal application to a two-step authentication process. I want to add a client certificate authentication process (via a smart card) on top of a traditional username/password form. The application is written in C#, hosted on IIS7, and targeting Chrome and IE8.
Problem:
I am having issues with getting the application to prompt the user for a client certificate. I have been debugging the application with the help of Fiddler. When I have a test client certificate saved in Fiddler's user's directory (C:\Documents and Settings\USER\My Documents\Fiddler2), the application works as expected. I am prompted for a PIN number protecting the smart card, and, when entered correctly, takes me to the login form. When I close Fiddler, the application throws a 403 Forbidden error instead (since Fiddler is no longer running and pointing to its certificate). What I haven't been able to figure out is why the application won't prompt for a certificate normally.
Current Server Setup:
Self Signed Certificate was created
443 Binding is pointing at Self Signed Certificate
Anonymous Authentication is Enabled
The Self Signed Certificate was added to both the Trusted Root CA and Intermediate CA (I read that another person had it in both rather than just the Trusted Root CA and that solved their issue, though neither set up has worked for us).
I cleared out the rest of the certificates in the Trusted Root CA that I didn't need (I read elsewhere that having too many certificates would cause SSL to choke).
I am out of ideas to try other than starting from scratch on another server. Does anyone know what the issue might be? This seems like it should be fairly straight forward and that I'm missing something minor. Any ideas are welcomed.
Update:
After spending more time with this issue today, I strongly believe it has to do with IIS7 not being configured correctly (I did not set up it originally). I think this because I enabled Failed Request Tracing, looked at the subsequent .xml files being generated, and saw that a 500 error was being thrown.
Chrome is throwing a "Access to the webpage was denied" message rather than a "403 - Forbidden: Access is denied". I don't know if this helps. I do know that when I do not make certificates required, the site will work as intended. Requiring a certificate is where it fails.
The Application Pool is set to .Net 4.0 | Classic | Network Service.
Your problem is that the browser doesn't either get the request to provide client certificate or there is a security related option to block it from happening. IE offers certificate only if the web site is in correct zone (intranet or trusted sites). Please check this before everything.
If that doesn't help then see this answer for next step. The netsh documentation says:
clientcertnegotiation
Optional. Specifies whether the negotiation of certificate is enabled or disabled. Default is disabled.
Enable that and even the dumbest browser should notice that it is supposed to offer certificate for authentication. To diagnose your problem further you can use WireShark to see the negotiation in action.
In every browser I've seen, the browser will not prompt you to select a certificate if it does not have any certificates signed by a CA the server trusts. So make sure your server is configured with the correct CAs. As Boklucius suggested, you can use openssl to examine the list of trusted CAs your server is sending to clients and see whether the CA you have signed your client certificates with is among them.
Try openssl s_client -connect yourip:443 -prexit
And see if the CA (your self signed cert) is send to the client in the Acceptable client certificate CA names.
you need to install openssl first if you don't have it
I'll throw in a "try restarting the browser" suggestion, particularly if you installed the certificate while the browser was running.
To add a rather painful lesson to the mix: Make sure you quit Skype (or any other application) that eats port 443.
So the idea here is if you are running a dev environment on the same machine (both client and IIS), and your team uses Skype or some other app to communicate.
Watch the hours go by as you try and debug this problem, seemingly doing everything "right", netsh http sslcerts and such, even rebooting but to no avail. Well, turns out Skype will eat 443 so turn it off and "poof" there goes your certificate prompt.
Then feel free to throw things at the wall, shout obscenities or just "Rage, rage against the dying of the light".
Also, make sure Fiddler isn't getting in the way. If you have it decrypting the SSL, it'll corrupt the message back to IE, and it doesn't have the certificate installed, so it can't offer it. Turn off fiddler, and voila, the certificate prompt appears.
In Firefox, if you press 'Cancel' the first time you're prompted for a certificate, and you left the sneaky 'Remember this decision' box checked, then Firefox will remember that and never offer it again.
You can view and delete your previous remembered decisions in Firefox Preferences -> Privacy & Security (about:preferences#privacy), View Certificates, and check the Authentication Decisions tab.
Just connecting to my VPN and trying showed me the certificate prompt. Needs to be done only the first time.
For some of my site visitors, the SSL certificate is failing. Whatever tests I do on various browsers for me the SSL certificate is valid.
I can't think of how to test this on client side, and to identify the problem.
How would you do this?
One client gets: fatal certificate unknown
While RouMao's answer is mostly correct, he has missed what is (IME) the most common problem with SSL certificates - the certificate you are using requires an interim certificate from the CA which you have not included in your certificate chain. Most CAs provide an online tool for analysing the certificate - try the one located here.
Also, is there any correlation with which browser being used? Notably, Chrome does not handle SSL v2 by default
Most of the failing of SSL certificates were caused by visitors themselves. Somehow could not tests or verified by server implementation.
Here are some obvious examples:
Your cert is validated since April 1st 2012, but the client's local machine time is set to 2010 -- one year later than current time. In this case, the visitor should encounter problem all the times, until his machine time is later than April 1st 2012.
visitor is behind a restricted firewall. The firewall could terminate the SSL/TLS connection and re-crypt the link with a pseudo/self-sign certificate. Indeed this could be considered as a man-in-middle attach.
The Trusted Root Certification was removed by client himself
it is very hard to fix all these problem. Sometimes, you need to create a client side native application to detect or fix all the possible problems, and require client browser to execute the application each time before it enter the HTTPS mode.
P.S. most of the e-bank application do like this.