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)
Related
I am trying to access an HTTPS page using a 11.3 version Ipad. The server certificates are signed by a custom CA, and thus, it causes Safari to show the "untrusted site" message. But if I install the CA certificates profile, and mark it as a trusted CA, when I try to hit the same pages, Safari goes all berserk constantly reloading the page 200 times a minute without actually showing the page. This isn't a constant behavior, the same tablet may work for some addresses and not for other ones (both using the same CA signing certs).
Is anybody aware of any known issues on Safari regarding non-bundle CA certificates?
We are also using non default ports (non 443) for the HTTPS server, in case this is of some significance.
I have little to none knowledge about ipad and safari, is there any way to get safari logs from the ipad?
Thank you!
After some deep digging in Wireshark traces, I found a difference in the SSL handshake between a server where safari was behaving as expected, and a server where the same safari was behaving erratically.
The working connection looked like:
And the non working one:
I took a deep dive into the Server Hello and find a slight difference:
Working:
Non working:
The server on the working scenario was providing two of the certificates in the signing chain, while the other server was providing only the server certificate. Seems that Safari does not like the last one.
I modified the server configuration to provide also the issuer cert in the cert chain and the bad server started to work fine.
So, I have a wildcard SSL cert from Go Daddy, and it has been installed on a few servers. However, on one particular server I cannot seem to get this thing done. Here's the process that has worked on all servers but this one:
1. Create CSR
2. Having gotten the certificate from the provider, I open the MMC certificates snap-in and import the intermediate cert to the intermediate authority store (or personal store, both have been tried). This is successful, in that I can view the certificate from the MMC
3. Go to the IIS server and under Server Certificates, I complete the CSR, point to the provided certificate and it imports into the web server successfully.
4. I go to an individual web site to assign the certificate to the web site under binding. When I select https and the IP address, the drop-down menu activates, but the certificate I just installed is not available for choosing.
5. I go back to the server Certificates, and the cert I just viewed is no longer there.
Go Daddy says to rekey, however, this makes no sense, since immediately prior to this, I installed that same wildcard cert to a different server, and it works fine. Obviously, this is something with IIS or Windows on this particular server.
Does anyone have any idea how to fix this without rekeying? Server platform is Windows 2008R2, IIS 7.5
If you have followed steps described in https://www.godaddy.com/help/iis-7-install-a-certificate-4801 then from your side it's done. And for more references, you can also check out this https://stackoverflow.com/a/43247419/7738413
Otherwise, rekeying is the last option.
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.
Salam,
I installed *.domain.com SSL Certificate in a CentOS 7.1 (apache2) Server, it was Ok first but now some of our client having problem with it,
I tried Server Update.
I tried Cache clear in clients Browsers
I tried different browsers
and I check the date and time.
and I actually do not know it's from the server or its from client side.
Error:
Your connection is not private
Attackers might be trying to steal your information from subdomain.domain.com (for example, passwords, messages, or credit cards). NET::ERR_CERT_REVOKED
Automatically report details of possible security incidents to Google. Privacy policy
ReloadHide advanced
subdomain.domain.com normally uses encryption to protect your information. When Chrome tried to connect to subdomain.domain.com this time, the website sent back unusual and incorrect credentials. Either an attacker is trying to pretend to be support.shamal.net, or a Wi-Fi sign-in screen has interrupted the connection. Your information is still secure because Chrome stopped the connection before any data was exchanged.
You cannot visit support.shamal.net right now because this certificate has been revoked. Network errors and attacks are usually temporary, so this page will probably work later.
Your certificate had been revoked. This can be seen here:
https://www.ssllabs.com/ssltest/analyze.html?d=support.shamal.net
This is a problem with the cert configured on the server. You'd need to ask GoDaddy why this happened - could be you asked to get it reissued, could be they think your untrustworthy for sone reason.
So in theory EVERY client should get a message like that above. But there are some subtleties, which might explain why this is not the case:
If the browser was unable to contact the CA which issued the cert then it will assume he best and assume it's not revoked (so called "soft fail").
Unlike other browsers, Chrome does not do real time checks as whether a cert is revoked by default (as they think it is slow and doesn't add that much protection because of reasons like "soft fail" - a contentious opinion). Instead they rely on a concept call CRLSets which are downloaded periodically by Chrome. This contains a list of revoked certificates. So there is obviously a delay in getting into Chrome and there is some question as to how complete CRLSets are. So this might explain why some Chrome clients are rejecting this and some not. Are the ones that reject it newer version perhaps?
Lastly some tools (particularly Antivirus like Avast or Corporate proxy tools) deliberately replace the cert with one of their own so they can still read the traffic to scan for viruses or for other reasons. Of course they shouldn't do this if a cert is revoked like in this case but stranger things have happened. Double click the green padlock to view the certificate and its chain to see if it was issued by a someone other than GoDaddy.
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.