[Interest] SSL & Let's Encrypt certificate expiration

Thorsten Glaser t.glaser at tarent.de
Wed Oct 6 18:55:21 CEST 2021


On Wed, 6 Oct 2021, Thiago Macieira wrote:

> If OpenSSL has any path to a still-valid root certificate, then it can ignore 
> the others. That's one way of dealing with expirations: you add a new link in 
> the chain that will continue to be valid when the other path(s) aren't. You 
> can also prune the tree that isn't necessary any more -- I looked into what 
> Let's Encrypt has been giving me for months and it hasn't included the 
> expiring certificate in the certchain.pem collection.

You don’t add root certificates to the chain the server delivers to the
client though, which creates a problem if the depth changes, like with
LE:

LE before:

server cert ← R3 intermediate ← X1 intermediate ← X3 root
└─────────────────────────────────────────────┘

Only those within the bracket are shipped by the server.

Now X1 is also a root. The client has no way to know that
*EXCEPT* if it has the X1 certificate in its *root* store
ahead of time (with a self-signature), because otherwise,
the X1 certificate shipped by the server has an Issuer that
is not X1, so it’s obviously not a root certificate (in the
role the certificate has in that chain).

Older OpenSSL versions now also fail with this unless patched
to add the workaround from later OpenSSL versions, namely, that
if a certificate of the chain is also part of the local root
store (now a root/intermediate trusted store), it’s accepted.

This means LE’s transition *cannot* work with lazy loading,
specifically because the client *cannot* know that there even
*is* anything to load, because the depth changed.

The situation would have been different if X1 would now be
signed by another root, but that would mean every user would
have needed to get the certificate chain updated at the same
time. That’s the less likely to succeed variant.

New LE certificates still ship the X1-signed-by-X3 in their
chain and fullchain. I’ve reported this to LE, but apparently
they continue doing so, against the spec (which says root
certificates shall not be shipped as part of the chain) because
old Android devices apparently don’t check root certificates’
expiry date, so the X1-signed-by-X3 continues to work for them.

On my own servers I’ve adapted my dehydrated hook to remove the
faulty intermediate, but of course this depends on server admins
to DTRT, plus it’ll apparently cause more trouble for Android…

tl;dr: don’t lazy-load the root certificate store, you may never
know when you’re going to need which certificates.

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

                        ****************************************************
/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against      Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also,     https://www.tarent.de/newsletter
╱ ╲ header encryption!
                        ****************************************************


More information about the Interest mailing list