Is this SSL certificate chain broken and how to fix it?

Question

For the SSL cert on the domain example.com, some tests tell me that the chain is incomplete and since Firefox keeps its own certificate store, it might fail on Mozilla (1, 2, 3). Others tell me it is fine, as does Firefox 36, which tells me that the cert chain is fine.

UPDATE: I tested on Opera, Safari, Chrome and IE on both Windows XP and MacOS X Snow Leopard, they all work fine. It only fails on Firefox < 36 on both OSes. I dont have access to test on Linux, but for this website it is less than 1% of visitors, and most are probably bots. So, this answers the original questions "does this setup bring up warnings in Mozilla Firefox or not" and "Is this SSL certificate chain broken or not?".

Therefore, the question is how do I find out which certs do I need to place in the ssl.ca file so they can be served by Apache to keep Firefox < 36 from choking?

PS: As a side note, the Firefox 36 I used to test the cert was a brand new install. There is no chance it didn't complain because it had downloaded an intermediate cert during a previous visit to a site that uses the same chain.

Solution 1

I contacted Comodo and downloaded a bundle.crt file from them. I renamed it to ssl.ca, as per this server's setup, and now the cert passes all tests. The Chain issues = Contains anchor notice isn't a problem (see below).

SSL Labs, widely regarded as the most complete test, now shows Chain issues = Contains anchor, whereas before it used to show Chain issues = None (while the others showed a problem with the chain). This is really a non-issue (1, 2), aside from an extra 1kB the server sends to the client.

My conclusion

1. Ignore the SSL Labs test where it says Chain issues = Contains anchor OR remove the root cert from the bundle file (see this comment below).

2. Always run a secondary test on at least one of the other three test sites (1, 2, 3) to ensure your chain is really okay when SSL Labs says Chain issues = None.

Solution 2

If the chain is sufficient depends on the CA store of the client. It looks like Firefox and Google Chrome have included the certificate for "COMODO RSA Certification Authority" end of 2014. For Internet Explorer it probably depends on the underlying OS. The CA might not yet be included in trust stores used by non-browsers, i.e. crawlers, mobile applications etc.

In any case the chain is not fully correct, as can be seen from the SSLLabs report:

• One trust path needs that the new CA is trusted by the browser. In this case you still ship the new CA which is wrong, because trusted CAs must be built-in and not contained in the chain.
• The other trust path is incomplete, i.e. it needs an extra download. Some browsers like Google Chrome do this download, while others browsers and non-browsers expect all necessary certificates to be contained inside the shipped chain. Thus most browsers and applications which do not have the new CA built-in will fail with this site.

Comments

[BE77Y]

Not necessarily - in any case, if you are able to answer your own question you encouraged to do so :)

[Gaia]

Yes, I answered this one but it would be more useful to re-ask how to fix instead of is it broken. Is it ok to do so?

[Arunkumar]

Absolutely. It keeps the answers here relevant as well (from the time they were posted, they were right, right?)

[BE77Y]

@Gaia: ah, ok - I see what you mean now. I'm not 100% over what would be considered best practice on that, but my instinct would be to update your question to include "and how should this be resolved?" In your case, as per Steffen Ullrich's response, the "COMODO RSA Certification Authority" cert is missing from the chain - you can avoid any potential client errors but including it in your chain. This is only ever really considered bad practice in that it adds potentially unnecessary overhead to the handshake - otherwise it has no detrimental effect.

[Gaia]

@BE77Y Per my browserstack test, Firefox < 36 on all OSes has an issue, and Firefox 35 is modern AND still widely deployed.

[Gaia]

I am under the impression that Chrome and IE both use the Windows certificate store. Are you sure Chrome has its own supplemental store?

[Gaia]

SSLlabs states "Chain issues=None", but I do see the detailed chain analysis below.

[Steffen Ullrich]

There is a world outside Windows. Chrome on Linux does not share the CA store with Firefox or uses the system CA store. And I don't know of Chrome on Mac, but it might integrate with the systems CA store.

[Gaia]

Thanks, but I just tested on Opera, Safari, Chrome and IE on both Windows XP and MacOS X Snow Leopard, they all work fine. It only fails on Firefox < 36 on both OSes. I dont have access to test on Linux, but for this client it is less than 1% of visitors, and most are probably bots.

[Steffen Ullrich]

@Gaia: don't forget the mobile clients, they have their own certificate store which might also differ between various Android versions.

[Gaia]

@SteffenUllrich a one cert bundle fits all would be ideal.

[Steffen Ullrich]

@Gaia: take the second trust path shown by SSLLabs and just add the missing chain certificate. This chain then can be validated by both the browsers which have the newer CA and the ones which don't have this CA yet.

[Håkan Lindqvist]

There's really no point to including the actual "anchor" / "root" certificate. You very much do want the intermediate certificate, however. I presume you didn't have the intermediate certificate initially, which caused the problems.

[Gaia]

@HåkanLindqvist So I should decrypt the certs, find out which one is the root cert and remove it from the chain?

[Håkan Lindqvist]

I would suggest doing so even though it's not as serious a problem as missing intermediate certs (it's just a bit wasteful). Fwiw, Qualy's SSL Test indicates that it's 02faf3e291435468607857694df5e45b68851868 which is unnecessary.

[Håkan Lindqvist]

Are you able to reproduce that error? It's not obvious how that would be related to the changes you made.

[Gaia]

@HåkanLindqvist Both run on the same Apache 2.2.x server. SSLUseStapling is not present, and the Qualys' test shows OCSP stapling=No. The only difference is that this latter site's cert was renewed today. Both are SHA-2

[Gaia]

@HåkanLindqvist the OCSP warning is gone. it was temporary and there are other people on the Qualys forum complaining about the same thing. Thank you.

[Chris J]

Your conclusion regarding the "contains anchor" warning is valid - This answer on Security.SE is worth a read regarding; in summary there isn't any problem sending it: security.stackexchange.com/a/24566/7043