They are two Certification Paths but all browsers seem to use only the first one.
Maybe I am missing something but I believe that the second path is not required and it appears as “Extra Download” so it might slow down page load.
Also, the Second Path appears to be untrusted because the root cert (ISRG Root X1) is not trusted.
So, why there is a second path? It is required by some clients? It affects SSL performance?
@rme, that’s correct; we’re applying to web browser root certificate programs, which would result in trusting the ISRG roots directly if the browsrs accept our application.
That’s expected.
Path #1 is the current cross-sign from IdenTrust and path #2 is the path to Let’s Encrypts own root certificate.
The only thing which is confusing for me is that the two “Let’s Encrypt Authority X1” intermediate certificates have a different hashes (@rme That’s also why extra download is showed there).
AFAIK these two should be the same…
That’s also expected. The fields of the certificate which reference the issuer are different (issuer, signature, authority key identifier, and probably AIA), thus the certificates’ hashes are different
Why is “ISRG Root X1” even included in fullchain.pem? I was under impression that root certificates should not be included in the chain provided by the server, as it (root cert) should already be on the client machine. Yes ISRG’s root is not yet in the trust store, but including it now and when it is trusted is pointless and just wastes server→client traffic.
Edit: after further investigation, the situation confused me a bit more. It looks like there’s no, in fact, root in the fullchain, but ssllabs test site gets it from somewhere for some reason. Is it a bug in ssllabs software?
It’s not a bug at all, it’s a feature. SSLLabs looks into the certificate meta data and finds http://cert.int-x1.letsencrypt.org/ as issuer where it downloads the certificate. That’s why it’s marked as extra download. Most browsers do not have implemented something like that, but they could also do something like that.
Thank you, this is the first time I hear about CA Issuers field in the certificate. I guess lack of implementation in the browsers results in the poor amount of information about this particular topic (and the need for inclusion intermediate certs in the chain).
It’s not just a few KB. DNS resolution, another TCP connection and another request, the size isn’t the important thing. That’s why certificates are just provided by the server directly, there we have just a few KB more.