15

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.

Gaia
  • 1,855
  • 5
  • 34
  • 60
  • 1
    Not necessarily - in any case, if you are able to answer your own question you [encouraged to do so](http://serverfault.com/help/self-answer) :) – BE77Y Mar 17 '15 at 15:48
  • 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? – Gaia Mar 17 '15 at 15:56
  • 1
    Absolutely. It keeps the answers here relevant as well (from the time they were posted, they were right, right?) – Canadian Luke Mar 17 '15 at 16:04
  • @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. – BE77Y Mar 17 '15 at 16:20
  • Further to the above, it's also worth noting that most if not all modern clients should be absolutely fine with the setup as it currently stands (as per the SSLlabs test) – BE77Y Mar 17 '15 at 16:21
  • @BE77Y Per my browserstack test, Firefox < 36 on all OSes has an issue, and Firefox 35 is modern AND still widely deployed. – Gaia Mar 17 '15 at 16:26

2 Answers2

9

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.

Michael
  • 239
  • 2
  • 10
Gaia
  • 1,855
  • 5
  • 34
  • 60
  • 3
    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. – Håkan Lindqvist Mar 17 '15 at 19:16
  • @HåkanLindqvist So I should decrypt the certs, find out which one is the root cert and remove it from the chain? – Gaia Mar 17 '15 at 20:12
  • 1
    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 Mar 17 '15 at 20:19
  • @HåkanLindqvist using `openssl x509 -fingerprint -in ssl.ca` i nailed that the part of the file that has fingerprint `02faf3e291435468607857694df5e45b68851868` was the first PEM. I removed it, and now I get http://i.imgur.com/1iG2UCz.png and http://i.imgur.com/m8gYbdG.png (OCSP ERROR: Request failed with OCSP status: 6 [http://ocsp.comodoca.com]) – Gaia Mar 17 '15 at 21:24
  • Are you able to reproduce that error? It's not obvious how that would be related to the changes you made. – Håkan Lindqvist Mar 17 '15 at 21:34
  • @HåkanLindqvist to be clear, I applied the same `ssl.ca` to another domain (http://www.text2image.com/user_images/text2image_X49632_20150317_215251.gif), and this is where I am getting the error. It's the same cert, same issuer. – Gaia Mar 17 '15 at 21:53
  • @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 Mar 17 '15 at 22:00
  • @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. – Gaia Mar 18 '15 at 01:04
  • 3
    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: http://security.stackexchange.com/a/24566/7043 – Chris J Jun 17 '15 at 10:03
8

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.
Gaia
  • 1,855
  • 5
  • 34
  • 60
Steffen Ullrich
  • 13,227
  • 27
  • 39
  • 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 Mar 17 '15 at 11:04
  • SSLlabs states "Chain issues=None", but I do see the detailed chain analysis below. – Gaia Mar 17 '15 at 11:05
  • 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. – Steffen Ullrich Mar 17 '15 at 11:49
  • 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. – Gaia Mar 17 '15 at 12:10
  • 1
    FWIW, Chrome under OS X does indeed use the OS certificate store, @SteffenUllrich. – BE77Y Mar 17 '15 at 15:14
  • 1
    @Gaia: don't forget the mobile clients, they have their own certificate store which might also differ between various Android versions. – Steffen Ullrich Mar 17 '15 at 17:03
  • @SteffenUllrich a one cert bundle fits all would be ideal. – Gaia Mar 17 '15 at 17:36
  • 1
    @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. – Steffen Ullrich Mar 17 '15 at 17:41