I recently had problems with the chaining with Stripe and Samsung Smartphones.
SSLLabs, https://tools.keycdn.com/ssl and Stripe say that I have chain issues. But they should not appear.
I use this in the following Certificate Chain:
The certificate chain needs to be a continuous path from the leaf to root, it can’t have any branches. Sending both versions of the intermediate is an invalid configuration and many application will throw an error as soon as the chain is broken without checking any remaining certs for an alternative chain.
As you’re sending the one signed by ISRG Root X1 1st that one will be checked, as that root is not yet included in many trust stores that chain is untrusted by many browsers/OSes and services.
WoSign has/had this also. They used there own root and cross-signed the intermediate with Startcom. But that had no errors and the client could choose the CA whom to trust.
If I send the ISRG Root X1 to keycdn the chain errors disappear but in the browsers the site was on Android not usable. Also SSLlabs say’d that the chain is invalid because it contains the anchor.
There’s never any reason to include a self-signed cert (like ISRG Root X1) in a certificate chain, since there are only two possible cases:
The client already includes that self-signed cert in its trust store, in which case it doesn’t need you to provide a copy, OR
The client does not include that self-signed cert in its trust store, in which case sending a copy will not convince the client to trust it, because there is no signature from another trusted entity.
@cool110 also makes a good point: The order of certificates in a TLS ServerCertificate message is specified by RFC5246 and requires that they be strictly in order, each one certifying the one before it. In practice, PKIX tend to throw the intermediates from the chain into a big pool of certs, then run their own path-building algorithms on the pool, possibly choosing a trust path that doesn’t include the provided intermediates.
However, all that said, I don’t think that’s your problem. Looking at the current SSL Labs results for your site, it looks like you are serving the copy of the Let’s Encrypt Authority X3 cert signed by ISRG Root X1, when you should be using the one provided to you by the API, i.e. the one signed by DST Root X3. I would strongly recommend making sure your client pulls the chain from the API, rather than trying to fix this manually, because the chain we suggest will definitely change in the future.
I removed the ISRG Root X1 yesterday for testing purposes. Maybe your test overlaped with mine
But for now I reinstalled the ISRG Root X1 and the error is back
You explained that the client is building it’s trust path from the pool of available certificates that makes sense. But why is SSLLabs and Stripe crying
Why do you only deliver the DST Root X3 to the clients while you have your root deployed in the major root programs?
@Knight, clients need a path from a root certificate that they already trust. The great majority of clients out there don’t yet trust the ISRG root; even once it’s accepted by root programs, that doesn’t necessarily affect pre-existing clients from those vendors.
Therefore the ISRG root is not yet recommended to be used for any purpose, because only a minority of clients could accept it as trustworthy. Client compatibility is a very important priority for most Internet service operators.
As @cool110 suggests, offering multiple paths can be a compatibility problem in itself because PKI standards don’t officially permit this and some clients could regard the extra certificates as an error. This is likely to change over time with more relaxed path-building algorithms, but in any case the safest course is to offer a single path from the a widely-trusted root—which at the moment would be the DST root and not the ISRG root.
You’re currently also sending the “LE X3 signed-by ISRG Root X1” twice, but no “LE X3 signed-by IdenTrust” intermediate at all.
Assuming this is fixed, I think you’d still get a SSL Labs warning since it’s technically not permitted, as @schoen mentioned, but most modern TLS clients would be able to handle it. The best option for compatibility would definitely be just sending the “LE X3 signed-by IdenTrust” intermediate (and no others).
