Acme.sh: ISRG X1 Root - option to continue to use X3 certificate chain

Created on 17 Apr 2019 · 15Comments · Source: acmesh-official/acme.sh

Firstly thanks for all your hard work on acme.sh. It really is an awesome tool.

I was reading this morning about the new X1 root that LetsEncrypt will transition to in July (see https://letsencrypt.org/2019/04/15/transitioning-to-isrg-root.html)

They mention that if you have alot of old clients, you can optionally configure your server to serve the old X3 certificate chain until September 2021 for better backwards compatibility.

We know we have alot of Android devices that don't support the new X1 root connecting to us, so wondered if there was a way that acme.sh could provide an option to use that older certificate chain in new issues/renewals for the time being?

We will of course be working to get that new root supported on those devices, but we don't have direct control over them so the longer we can give people to make that change the better!

enhancement

Source

alexharrington

👍3

Most helpful comment

Would it be possible to resurrect the PR from alexzorin so that we can have this option in a future release at all please?

alexharrington on 4 Jun 2020

👍2

All 15 comments

good suggestion.
The problem is how to.
let me think about it.

Neilpang on 17 Apr 2019

❤1

a toggle to allow to pick the old one, and put that in the domain cert folder

FernandoMiguel on 17 Apr 2019

How about a --compatibility-chain flag to --install-cert?

acme.sh would need to bundle the "compatibility chain" (the DST-signed Let's Encrypt Authority X3 issuer) inside the script.

When the flag is used, it would:

Check that the issuer in the fullchain matches the SKI of the Let's Encrypt Authority X3 issuer
Check that the "compatibility chain" expires after the leaf certificate does
Installs the fullchain with the "compatibility issuer"

This way, users could continue to use the cross-signed chain for as long as is safely possible, and acme.sh would automatically fall back to the default chain once that time passes.

I can have a go at a PR if that plan sounds good to you @Neilpang

alexzorin on 11 May 2019

@alexzorin

How about a --compatibility-chain flag to --install-cert?

No, we should implement this feature at the end of the isssue() function:
https://github.com/Neilpang/acme.sh/blob/master/acme.sh#L4431
and
https://github.com/Neilpang/acme.sh/blob/master/acme.sh#L4515

We should replace it in the ca file: CA_CERT_PATH and CERT_FULLCHAIN_PATH.

acme.sh would need to bundle the "compatibility chain" (the DST-signed Let's Encrypt Authority X3 issuer) inside the script.

No, we will not include the cert in the script.
just download from this link:
https://letsencrypt.org/certificates/
https://letsencrypt.org/certs/lets-encrypt-x3-cross-signed.pem.txt

Go ahead, please.

Neilpang on 12 May 2019

I don't agree about having this part of --issue. Chain selection seems to me to be an installation-time choice, not an issuance-time choice. Putting it in --install-cert would allow a user to switch between chains without having to re-issue the certificate.

alexzorin on 12 May 2019

@alexzorin

No, it's not installation-time choice.

When the issue process finishes, there are such files ready: domain.cer, ca.cer and fullchain.cer.

We must replace the cert in ca.cer and fullchain.cer.

--install-cert is only one of the ways to install/copy certs, we have also a lot of deploy-hook to deploy the certs. so, we should not implement it in --install-cert function.

For both ACME v1 and V2, we always produce the same certs: domain.cer, ca.cer and fullchain.cer.
We will fix them all in the same way.

Neilpang on 12 May 2019

I've implemented that approach in https://github.com/alexzorin/acme.sh/commit/4747d2655678e0bd51b79329ca94dd6e7ce9f1d7 and it seems to work for ACMEv1/v2, but my previous concerns still worry me. And I'm not sure if my use of date is portable.

alexzorin on 15 May 2019

Please implement it in the --issue function. There are a lot of users don't call --installcert or --deploy at all. They are using the cert files directly. So, we MUST replace the cert in the --issue function. It has the smallest requirement from the users.
Please download the PEM from the website. don't embed it in the script. I think it's stable enough. If you concern, I can create a new repo to hold the cert, and you can download the cert there.
You don't need to verify the chain. It can be simple, just check the key A8:4A:6A:63:04:7D:DD:BA:E6:D1:39:B7 and replace. There will be little users use this option, and if used, it must be that simple.