From the reply in that latter post:
From Chain of Trust:
RSA 2048, O = Let's Encrypt, CN = Let's Encrypt Authority X3 )
RSA 2048, O = Let's Encrypt, CN = R3 )
My eyes spot a cross-signed R3 intermediate! 
It was added to the website 18 hours ago.
Very astute observation. 
Hope you didn't steal the thunder. 
Doesn't really help the OP though. As R3 has a different public/private key pair and no way to force Boulder to use it, OP can't force R3 before it's in use by default.
Specifically what's going on is this: The "chain" was once specified as explicitly a chain of certificates, starting with the leaf ("your" certificate) and then each subsequent certificate is for the issuer of the previous certificate. However in practice - and this is formally spelled out in the TLS 1.3 standard - this "chain" is just your leaf plus a pile of other certificates a client might find useful to decide it trusts that leaf.
In a modern browser this pile of "maybe useful" certificates is an ingredient for a process in which the browser tries to figure out any way to decide it trusts the certificate, rather than picking one "chain" and then deciding if that chain is trusted or not. Other ingredients can include certificates the browser saw on other web sites recently, certificates it found on the web using "AIA chasing" (a certificate can incorporate URLs for the issuer's certificate in the Authority Information Access section) and the browsers own store of trust information. If you have Internet Explorer for example that does AIA chasing, if you have a recent Firefox it keeps track of every known intermediate CA.
As a result, what your browser tells you does not necessarily relate to the chain presented by the site, if you're trying to diagnose chain problems you should use tools intended for that purpose.
Unfortunately unlike web browsers, many other clients do require that the "chain" specifically form a chain issuer by issuer such that they trust this exact path, even though you've no way to be sure what exactly any particular client will trust. Generally newer clients are better than older ones, but if you run a service that has very picky clients you may need to actually debug this carefully unless you can get users to upgrade to a better client.
Unfortunately unlike web browsers, many other clients do require that the "chain" specifically form a chain issuer by issuer such that they trust this exact path, even though you've no way to be sure what exactly any particular client will trust.
One such client would be galera (the layer that makes MySQL databases into a cluster. If you want to use SSL for connections between the nodes, you specify a "socket.ssl_ca" option for a file which can contain root and intermediate certificates. I have no reason to believe it also uses system-installed certificates from elsewhere. The annoying thing here is that you need to install new root and intermediate certificates before you start using new leaf certificates (or the nodes can't communicate amongst each other).
So the file we have now contains the following certificates:
Issuer: C=US, O=Internet Security Research Group, CN=ISRG Root X1
Subject: C=US, O=Internet Security Research Group, CN=ISRG Root X1
Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3
Subject: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3
Issuer: C=US, O=Internet Security Research Group, CN=ISRG Root X1
Subject: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3
Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3
Subject: O=Digital Signature Trust Co., CN=DST Root CA X3
Does the change mean that we have to install an extra intermediate certificate, or are we good?
@oseibert you are referring to the change of root certificate rather than the change of intermediate certificate?
You only need one root, and if your program doesn't verify against system-installed certificates, you can choose yourself which one. You either need the 2nd and 4th (old root, will expire) or the 3rd and 1st (new root); there is no point including chains to both roots if you're not depending on roots installed on your system.
For the intermediate certificate change: you don't have the new one yet. So you want to add Let's Encrypt R3 signed by ISRG Root X1 to the file (new intermediate for new root), and then keep the 3rd cert (old intermediate for new root) and 1st cert (new root). The preferred order of the file is: root last.
@AlbertJP Thanks! Yes I see that our list is redundant. Apparently that isn't so much of a problem for galera. We also have some old certs in there for certificate providers we used in the past.
I have added Let's Encrypt R3 signed by ISRG Root X1. I had been wondering when such a certificate would become available but I hadn't noticed that it already was. Thanks for pointing it out.
Redundant certificates are generally not a problem in the sense that they don't generate errors, but they do take bandwith during the TLS handshake, so if performance is important for you or if users are on metered connections I would advise removing them anyway.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.