Root(s) missing, main cert chain not supported


#1

Just issued my first cert(s) with official chain support in certonly mode, and things work great – just had to re-issue three times for finding out how to specify the --rsa-key-size. Local deployment is manual through some local Makefiles down to creating the proper intermediate and OCSP Stapling chains on my own.

I see that the currently resulting LE output files miss two features:

  1. The root CA’s pem is missing from the live/ directory where key and all other certs are stored. For a legacy HTTPS server deployment, the root CA is not needed (actually it would be wrong to send it as part of the chain), but for OCSP Stapling it is vital for it to be part of a separate full CA chain file (ssl_trusted_certificate). Without the file in place, it’s a nice game to search for the actual required root CA certificate. Searched and found this list of LE certificates, but the actual DST root CA is not properly served on this page, neither in this post with similar links. The only thing available is a link to IdenTrust with a very awkward display of their certificate. It’s rediculous to have this link as the only source of the root CA certificate – consider scripting. It’s a shame that IdenTrust makes a game out of it through their silly ‘download’ page instead of supporting a direct download link for the PEM file.
    However, it seems as if the certificate was part of every well equipped /etc/ssl/certs/ folder, on my server it can be found as /etc/ssl/certs/DST_Root_CA_X3.pem which comes to no surprise actually, but it’s not great to require this manual investigation.
  2. The official, main route to the ISRG Root X1 (SHA1 fingerprint cabd2a79a1076a31f21d253635cb039d4329a5e8) is not offered yet, the respective intermediate cert for the Let’s Encrypt Authority X1 (SHA1 fingerprint e045a5a959f42780fa5bd7623512af276cf42f20) is missing from the installed chain.pem and fullchain.pem. I’d have expected that the only missing move before LE signed servers would be served through ISRG Root X1 was the inclusion of the new ISRG Root X1 certificate in the browsers. If the e045a5… cert would already be part of the chain of every deployed server, all users could automatically authenticate this certificate chain with the new root CA as soon as they update to the browser to the supporting release.

(btw, how does an OCSP Stapling setup look like with cross-signed roots? Would I include both roots in the ssl_trusted_certificate pem file or just rely on the fallback IdenTrust root?)


#2

Just following up on myself.

I’m actually running my server with both intermediate certificates, the one pointing to ISRG ROOT X1 and the legacy one pointing to DST Root CA X3, in this order. This works for Firefox, Chrome, Edge, SSL Labs and even on Firefox on Android. However, Chrome on Android gives an error.

If I swap the two intermediate certificates, Android’s Chrome starts to like my server again, but then SSL Labs indicates a certificate ordering problem.

I know that I’m ahead of my time using LE Authority X1’s e045a5a9 intermediate, but I thought that I shouldn’t have to wait for ISRG ROOT X1 to be included in major browsers before sending the matching intermediate certificate. Or is Android’s Chrome just too smart for the new root CA? Perhaps Google implemented some kind of pinning for any LE-certified site which doesn’t expect and accept an alternative certificate path to other root CA beside the legacy DST Root CA X3?


Which browsers and operating systems support Let's Encrypt
#3

Very unlikely. :smile:


#4

is that even possible, as far as I know a webserver (at the very least apache specifies that in its config) can supply only one cert/chain per cert type (rsa,dsa,ec)


#5

@My1, I think you’re after something completely different. I’m referring to the questions, how to find the current Root CA certificate, and how different certificate paths from the same LE key/cert should work (especially in the context of OCSP Stapling), especially since the new (RSA) root + signing CAs from LE have already been created and disclosed.

Your topic is about having multiple keys/certs on a single web server entry. Different story.


#6

THIS is my point, I wonder why this is even possible…


#7

Again, this is not special in any way. If you ever did TLS before/beside LE you might’ve noticed that most signing CAs issue multiple intermediate certificates, not just because they have a multi-level signing CA system but because they support different Root CAs over different certificate paths. LE is about to follow a similar approach, so I expected to succeed in supplying the upcoming intermediate certificates, but failed.

It’s not about multiple server keys at all.


#8

I mostly did it with CACert before and they had only 1 immediate iirc.


#9

Oh come on, cacert is not even trusted by any browser I know of. Bad example.

For example, just check www.ssllabs.com themselves. https://www.ssllabs.com/ssltest/analyze.html?d=www.ssllabs.com

They definitely send out two intermediate certs in addition to the actual server certificate, which lead to two different root CAs over two paths as shown in the ‘Certification Paths’ section. The second path is actually there as a fallback and is used by older browsers or other clients that don’t trust their G2 Root CA yet.

Note that with Entrust there are two certificates with the same name involved: Entrust Root Certification Authority - G2 as a real Root CA with a self-signed certificate, SHA1 fingerprint 8cf427fd790c3ad166068de81e57efbb932272d4, and again Entrust Root Certification Authority - G2 as an intermediate certificate, fingerprint 9e1a0c35e714b69792d090b2cc4bba45833c3015. They not only share the same name but also the same private/public key – that is what allows either of these certificates to be used for validating the signature of the L1K certificate over one of the two paths.


#10

this is a cross signed root case, which is different from the LE situation.

for one they send their intermediate (sha1 print cca27d33c735a7d06d1fecad980e498da681c963) and then the entrust g2 (signed by the old one, 9e1a0c35e714b69792d090b2cc4bba45833c3015). the latter one can be ignored by browsers because they have the entrust g2 (this time self-signed) in the store. The older ones use the G2 sent by the server to trace back. the path is linear while in LE you have 2 direct intermediates which makes it a wholly different situation.

also even if CACert is the CA I mainly used, it was (and still is) the only practical free CA, as there are yet no SAN compatible win clients available and manual with 14+ domains (incl. subs, spread over 3 root domains) which are mapped on my windows PC/Server is a pain.

also since CACert needs a face-to-face with at least 3 people (aka assurance) which are already “assured” to get certs for longer than 6 months, so I have a lot more trust in them than in LE.

also they do real domain validation (over whois/admin mail) and not just host-behind-domain validation.