I ran my first cert renewal this morning following the switch from X3 to R3 intermediate...
Having read some of the posts in recent months, I was expecting to see R3 signed by the ISRG root, but I'm seeing it as signed by the DST root.
It's working just fine for me at the moment, but I'm curious as to why I didn't get the DST root and whether there's anything I need to do differently in future?
I'm using CertifyTheWeb on Windows, latest version of the client. Wildcard certificate with manual DNS verification. Client configured to install the issued certificate to the local certificate store only - I'm then exporting the full chain & using OpenSSL to split the resulting PFX into various .pem and .key files for a few different applications.
As a side note, my current method seems to include the root in the certificate chain (above the intermediate), which I know is wrong, but I haven't found an ideal fix for this yet. I could manually edit the .pem files to remove the root, but not sure about whether I need to do anything with the PFX in that instance.
I only realised recently that in addition to the certificate store, I think it leaves a copy of the PFX elsewhere, so I need to check if that one includes the root and if not, probably start using that copy instead.
I'm relatively new to Let's Encrypt (and certs in general) - first cert 10/08/19...
I'm in no rush! This deployment is my home server, so 3 users total including me. One of the other two has an aged Android device where I've manually installed the ISRG root, so I was planning to test it whilst the DST root is still valid. (Yes, I read that Android ignores expiry on trust anchors, but still...)
I managed to find the link to the 'test' sites on the page you shared before I posted, so I'll use that to check that device's functionality for now.
So have you configured your preferred chain? It's set when you create the Certificate Authority account under Settings > Certificate Authorities (see the Advanced tab, preferred chain option) or you can set it for specific managed certs under Certificate> Advanced > Certificate Authority > Preferred Chain. The name must exactly match the root of the chain.
LE planned to default to the ISRG root a while ago but they haven't done that yet, so it's still DST Root CA X3. The LE plans have changed significantly regarding android handling etc, so the goal posts have moved a little for this feature.
If you've set the ISRG Root X1 as your preferred I'll investigate to see if there's a bug.
It may also be relevant that some tools (the built in windows cert ui vs the windows certmgr UI for instance) get confused about Roots for the R3 and will show DST even when the root is ISRG. Some browsers do that as well. Here is a screenshot for the same cert, both showing different roots:
As you said, I just issued a new certificate (preferred-chain "ISRG Root X1") using acme.sh.
Both Windows and Firefox regard it as "DST Root CA X3", but "ISRG Root X1" is displayed correctly on ssllabs.
Have just checked again and looks like that was/is my issue. Force of habit, I exported the cert PFX from the Windows certificate store rather than the ProgramData PFX (originally I hadn't realised it was saved there). The PFX exported from the store shows DST root. The PFX in ProgramData shows ISRG root.
This is most likely due to caching. Implementations like Firefox cache CA certificates (for example the R3 certificate) and use their cached version for validation. Since these implementations identify certificates by key fingerprints rather than full hashes, this can cause the browser to display a chain that does not match the one send by the server.
SSLabs on the other hand always shows the chain that was send by the server and does not use any kind of trust anchor/certificate caching.
