I encountered the same issue as others on Debian, using certbot 0.31.* on a Ubuntu server version 16.04.* LTS.
Newly requested certificates were still signed with the R3/X3 intermediate certificate which expired on September, 30th, 2021.
When trying to update the apt package there is no updated apt package of certbot available for Ubuntu 16.04.
Hi @hdepp, welcome to the LE community forum 
[I moved your post because the other topic was for a Debian issue]
Please add more detail about your specific issue here so that it can be better addressed.
Much better; thank you.
That is a very unexpected situation.
Is your web service behind a load-balancer or proxy?
Which web server are you using?
I'm using a VPS running Virtualmin, but I request the certificates manually using Certbot in the terminal like this:
certbot certonly --manual --preferred-challenges dns --server https://acme-v02.api.letsencrypt.org/directory --manual-public-ip-logging-ok -d „*.mydomain.com“ -d „mydomain.com“ --config-dir ./config --work-dir ./work --logs-dir ./logs
Then I manually paste the DNS TXT challenge records to my provider's DNS zone tool, and I successfully get the certificates. However, the certificates get signed by the deprecated X3/R3 certificate.
When I activate the new certificates on my Webserver I still get the issues.
I just tried to do the same from my local machine (macOS 11.*, certbot 1.19.0) -> same issue
Not possible (that intermediate stopped being used in May 2021).
Please show the chain.pem file (or fullchain.pem file if that one is served).
Is it safe to share the chain.pem or fullchain.pem content here? Can I verify it on my side and write the infos here and how?
Yes, both can be publicly served by your web service.
The only private file is the key - never share/show the key file.
@rg305 I found that requesting a certificate with the following command will generate a certificate with the deprecated intermediate X3 certificate:
certbot certonly --manual --preferred-challenges dns --server https://acme-v02.api.letsencrypt.org/directory --manual-public-ip-logging-ok -d „*.mydomain.com“ -d „mydomain.com“ --config-dir ./config --work-dir ./work --logs-dir ./logs
I tested it with certbot 1.19.0, probably this is a bug as the ISRG Root X1 should be used by default now.
The solution is to add --preferred-chain "ISRG Root X1" as parameter. This will sign the certificate with the correct root certificate. I found this solution in another thread.
Older certbot versions do not support the --preferred-chain parameter, so I had to update certbot first.
To verify the chain.pem and fullchain.pem (fullchain.pem = cert.pem + chain.pem) , I used this online service: Certificate Checker - Verify and Decode Intermediate Certificates | KeyCDN Tools
How can I directly verify the chain.pem/fullchain.pem via openssl?
echo | openssl s_client -connect EXAMPLE.COM:443 -servername EXAMPLE.COM | head
That is not correct. The default chain is the 'long chain' but the 'short chain' can be selected with the --preferred-chain parameter. See:
@hdepp I was going to try your command but I do not understand the syntax for -d that you show. Why are there empty domains noted by the consecutive commas and what is the purpose of the oddly quoted string following the first -d?
Is that specific syntax necessary to produce the result you see?
I think the copy/paste has replaced the quotes with and upside-down one.
@rg305 Yeah, likely, still the commas are odd and why quotes are there at all with one set of -d and not the other is odd.
I do not think the command is resulting in the wrong chain. But, before I spend time experimenting with their command I would like to know the actual format
Erase commas from your mind...
See only quotes:
-d "*.mydomain.com" -d "mydomain.com"
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.