12

My hosting provider has recently re-issued and re-installed an SSL certificate for my domain, after they let the old one expire by mistake.

I am now able to browse the website over HTTPS again, and so is my host, and so are a number of other users.

However, some users (at least a dozen out of hundreds) are still getting Your connection is not secure error messages on different browsers and platforms. (It is proving difficult to diagnose an issue I cannot reproduce.)

I understand different browsers use different lists of Certification Authorities (CA.)

  1. How come a user running the same version of Firefox as I am (45.0.1 on OS X) is getting a SEC_ERROR_UNKNOWN_ISSUER error (for my site only) while I'm not? What makes it possible? Said user cleared his cache and rebooted his laptop.

I ran an SSL check on digicert.com. The result is this:

SSL Certificate is not trusted

The certificate is not signed by a trusted authority (checking against Mozilla's root store). If you bought the certificate from a trusted authority, you probably just need to install one or more Intermediate certificates. Contact your certificate provider for assistance doing this for your server platform.

  1. How come I am able to connect to the site without SSL error if this is the case?
Community
  • 1
Fabien Snauwaert
  • 251
  • 2
  • 3
  • 9
  • 1
    `My hosting provider has recently re-issued and re-installed an SSL certificate for my domain, after they let the old one expire by mistake.` - How is it that you've left this responsibility in their hands? – joeqwerty Apr 11 '16 at 12:23
  • 3
    Merely because I'm no sysadmin, I rent a managed dedicated server from them. (For the little background story, I write language-learning material and code, on top of running the business, so doing sysadmin too, while interesting, would be one too many hats.) – Fabien Snauwaert Apr 11 '16 at 13:08
  • 7
    @joeqwerty: Because it's their job? He's literally paying them to sort this stuff out for him. – Lightness Races in Orbit Apr 11 '16 at 16:27
  • @LightnessRacesinOrbit: That's an assumption I didn't make, hence the question. – joeqwerty Apr 11 '16 at 16:29
  • @joeqwerty: I've yet to meet a hosting provider that would manage your SSL certificates for you out of the kindness of their hearts :P – Lightness Races in Orbit Apr 11 '16 at 20:38
  • @LightnessRacesinOrbit Well, in this case, paying them doesn't actually make it easier/faster either… – Fabien Snauwaert Apr 11 '16 at 20:57
  • @FabienSnauwaert: Indeed, so it seems the OP has discovered :) – Lightness Races in Orbit Apr 11 '16 at 21:46
  • 1
    https://bugzilla.mozilla.org/show_bug.cgi?id=399324 is the bug report requesting support for automatically downloading intermediate certificates in Firefox. The discussion (8 years long now) boils down to "IE does it!" / "To hell with IE, the RFC says it's optional!" / "Ever hear of the robustness principle?" / "Your server configuration is bad and you should *feel* bad!" –  Apr 12 '16 at 12:57

4 Answers4

22

The certificate chain of your certificate is incomplete. Most likely your provider failed to install some intermediate certificate when installing the new certificate.

Most times such intermediate certificates are provided by the SSL authority, to provide support for some older browsers and operating systems. That's the reason, that while it works for you, it doesn't work for some of your clients.

An really great utility to check for SSL issues with your website is the SSL Server test by SSLlabs. As you can see in the link above, not only are you having a chain issue here, but also the signature algorithm used to create your cert is a weak one, your webserver is still vulnarable to the POODLE attack and still supports RC4, which is also considered unsecure ...

I don't want to say anything against your webserver provider, but in your position I would mail them, that they fix all this issues ASAP, or change to another provider ...

s1lv3r
  • 1,155
  • 1
  • 14
  • 24
  • Thank you, that's very helpful. Out of sheer curiosity, any idea why a client on OS X and the same version of Firefox as mine is getting a `SEC_ERROR_UNKNOWN_ISSUER` error while I'm not? Could it be his OS version is different? – Fabien Snauwaert Apr 11 '16 at 13:14
  • 1
    @FabienSnauwaert Yeah, if you scroll down to "Handshake Simulation", the SSLLabs test will try to simulate various OS/Browser version combinations. The browser doesn't handle SSL connections totally on it own, but partly relies on the implementation of the OS. So definitely the OS version makes a difference. – s1lv3r Apr 11 '16 at 13:21
  • 4
    It's not just that clients may have different lists of CAs. It is also possible that some of the clients cache intermediate certificates such that a site with a missing intermediate certificate may work if the browser has previously visited a site that has correctly configured that intermediate certificate. – kasperd Apr 11 '16 at 21:17
  • The SSLlabs site is a nice tool. Thanks for the reference. – Parapluie Jan 30 '19 at 17:42
12

In order for a certificate to be trusted, it must be signed by an entity that is itself trusted by your browser/OS combination, or that has in its own turn been signed by such an entity. This is usually done by one trusted root CA which signs an intermediate CA, and the intermediate CA signs your certificate. This creates a chain, like this:

  1. Root CA which is trusted by your computer, and signs
  2. Intermediate CA, which signs
  3. Your certificate, which is only trusted due to the chain leading back to the root CA.

The problem here is with the intermediate CA certificate. In order to make sure that everyone can validate the chain all the way back to the root CA, your provider should include the intermediate certificate in its server config. In this case, they haven't.

The reason why it works for some users is that they have the intermediate certificate in their own "trust store". In those cases, they will accept your certificate because they already trust the intermediate. But in the case where your visitors have a different OS/browser, they don't have the intermediate certificate, so they would need to get it from your webserver - and your webserver doesn't hand it out, so they have no way of verifying it.

Jenny D
  • 27,780
  • 21
  • 75
  • 114
  • Thank you, it helps me see the issue clearly now. Is there any trick to get users to add the intermediate certificate to their own “trust store” while waiting for my host to fix the certificate? e.g.: visiting another SSL site that relies on it or so? – Fabien Snauwaert Apr 11 '16 at 13:16
  • 1
    @FabienSnauwaert There's no trick, unfortunately. Just visiting a site that has the same intermediate certificate won't help; they would need to actually download the certificate and manually add it to their browser. I believe this particular certificate is included in newer browsers - it works in Firefox 45.0.1 but not in 43.0.4, so it was included somewhere between those two versions. So if you could get your clients to upgrade their browsers, that would help. – Jenny D Apr 11 '16 at 13:26
  • 4
    @JennyD Intermediate certificates are cached by modern browsers, so visiting a different site that uses the same intermediate is fairly likely to work. However, that's really not something one should be asking of their users... (see: https://bugzilla.mozilla.org/show_bug.cgi?id=629558, https://sslmate.com/blog/post/chrome_cached_sha1_chains) – Bob Apr 11 '16 at 14:23
0

I had the same error, and it turns out I had neglected to include an SSLCertificateChainFile directive pointing to my fullchain.pem. Once I added that, I got the "TLS Certificate is correctly installed" from digicert.

SSLCertificateFile /etc/letsencrypt/live/unternet.net/fullchain.pem
SSLCertificateChainFile /etc/letsencrypt/live/unternet.net/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/unternet.net/privkey.pem
jcomeau_ictx
  • 262
  • 4
  • 13
0

If you were using HTTP Public Key Pinning and your provider gave you a new certificate, the public keys might have changed already. These keys are saved in the client's browser for the period you specified.

jarvis
  • 2,006
  • 4
  • 18
  • 31