Howto obtain a full certificate chain without a cross-signed ISRG Root X1

jow · October 1, 2021, 2:24pm

Hi,

I am looking for a way to obtain a certificate chain through Let's Encrypt that does not append a cross-signed ISRG Root X1 certificate at the end. Right now, when requesting a certificate for a domain using the latest acme.sh client, I receive a certificate chain which includes a ISRG Root X1 that is cross-signed by the DST Root CA X3, for Android compatibility I presume.

Sources on the web, like the OpenSSL compatibility blog entry here: Old Let’s Encrypt Root Certificate Expiration and OpenSSL 1.0.2 - OpenSSL Blog (Workaround #3) suggest to "Configure the server to use the alternative certificate chain which can be requested from Let’s Encrypt with most up-to-date ACME protocol clients." which, I guess, translates to the "preferred chain" option that was implemented in most clients a while back.

My problem is that both using --preferred-chain "ISRG Root X1" or --preferred-chain "DST Root CA X3" will produce me a certificate chain that contains the cross-signed X1 CA cert.

I could manually edit the resulting cert chain and remove or replace the offending X1 CA cert with a non-cross-signed one (e.g. taken from the Let's Encrypt website) but I'd prefer to request a proper one in the first place.

Is there any "preferred chain" value that will tell the Let's Encrypt servers to produce a chain that contains a non-cross-signed ISRG Root X1? Or am I facing a potential client specific issue?

For reference, there's also a pending issue against acme.sh describing my particular problem:

github.com/acmesh-official/acme.sh

Validation issue with fullchain file (nginx server / windows client)

opened 07:43AM - 01 Oct 21 UTC

nitrotm

Steps to reproduce ------------------ Note: unsure if that could happen for …newly issued certificate. In our case, this happened on an existing certificate we just renewed (`--renew --force ...`) Deploy a Let's Encrypt certificate, eg: ``` acme.sh --install-cert -d mydomain.com \ --cert-file /etc/nginx/certs/mydomain.crt \ --key-file /etc/nginx/certs/mydomain.key \ --fullchain-file /etc/nginx/certs/mydomain-full.crt \ --reloadcmd "systemctl reload nginx.service" ``` where nginx is provided the fullchain: ``` server { listen 443 ssl; server_name mydomain.com; ssl_certificate /etc/nginx/certs/mydomain-full.crt; ssl_certificate_key /etc/nginx/certs/mydomain.key; ... } ``` Issue ----------------- The problem is that the fullchain contains an obsolete root certificate (`ISRG Root X1`), which means nginx emit the following certificates to the client: 1. the domain's certificate 2. the `R3` intermediate certificate 3. the `ISRG Root X1` certificate (old one, signed by `DST Root CA X3`) On Windows clients (and maybe other platforms), when nginx sends the `ISRG Root X1` to the client, the Windows validation procedure evaluate it could be an intermediate certificate signed by `DST Root CA X3` which is now expired. There is an alternative path using the newer `ISRG Root X1` in store but it seems Windows strategy is to fail first. ![image](https://user-images.githubusercontent.com/805632/135583313-79ca5f59-d280-49d2-96bd-e8fd5fd2bb99.png) Solution ----------------- Manually remove the `ISRG Root X1` from the fullchain file and restart nginx server. In this case, the `R3` validation is done against the correct / up-to-date / trusted `ISRG Root X1` and it succeed. So the chain file for nginx should only contain: 1. the domain's certificate 2. the `R3` intermediate certificate ![image](https://user-images.githubusercontent.com/805632/135583620-2bc49b60-b168-44f5-b1fb-35234123d381.png) The problem is there is no way to call `acme.sh` to generate a file with just the domain certificate followed by *only* intermediate certificate(s). Or at least a way to generate a file with the intermediate certificate(s) - without the root ca. Alternatively, `acme.sh` should append the correct root certificate.

I am not interested in extended Android compatibility but I need to support (unmodified) OpenSSL 1.0.2 clients as well as older wolfSSL clients that exhibit similar logic problems as OpenSSL 1.0.2 (rejecting the entire cert because one of the alternative chains is expired).

Tugzrida · October 1, 2021, 2:41pm

What certbot version are you using? Using --preferred-chain "ISRG Root X1" will get you the leaf < R3 < ISRG Root X1 chain you are looking for for certbot versions 1.12.0 and newer

jow · October 1, 2021, 2:53pm

Thank you, it works for me too, now. My mistake was trying to switch the preferred chain during a certificate update, I had to re-issue the certificate completely instead of updating it (in acme.sh terms) for the setting to become effective.

system · October 31, 2021, 2:53pm

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.

Topic		Replies	Views
ACME self signed ISRG Root X1 certificate Help	6	1100	October 31, 2021
Certificate chain no longer includes ISRG Root X1? Help	10	2237	December 24, 2023
How do we stick to IdenTrust cross-signed after September Help	5	1210	September 17, 2020
Certificates requested through acme.sh are not issued as ISRG Root X1 Help	14	160	October 12, 2024
DST Root CA X3 Expiration Help	16	2708	December 12, 2021

Howto obtain a full certificate chain without a cross-signed ISRG Root X1

Related Topics