Add support for alternate chains

Question

Add support for alternate chains

progval opened this issue 4 years ago · comments

Hi,

First of all, thank you for acme-tiny, I've used it for years and it always works perfectly!

Let's Encrypt just published this blog post: https://letsencrypt.org/2020/11/06/own-two-feet.html

where they announce they will change their root certificate, but still offer the old one via an "'alternate' link" to support old OSs. Could acme-tiny add support for this feature?

Thanks!

Walter Hop · Answer 1 · Tue Dec 08 2020 05:39:41 GMT+0800 (China Standard Time)

Is there a reasonable chance that this feature will be implemented soon? We don't have much time since Let's Encrypt will change the default to the ISRG root on Jan 11 which is just a month away. I've surveyed some alternative ACME clients but most seem so bloated and I would strongly prefer to stay using acme-tiny.

Since it's so tiny, it looks very amenable to contributing. If there's no plans, I will try to contribute the feature, we have a Python guru in our team and we're willing to sponsor his work on it. The script might get a little less tiny, but I think supporting the old Android <=7.0 devices for some additional time is really vital. (About 5% of Android devices for us in our research.) Offers of testing would be welcome; if I understand it correctly the Let's Encrypt ACME api already has the future in production (you can get an ISRG chain already now if you want) so we don't have to wait for the switchover to try it out.

pavhofman · Answer 2 · Wed Dec 16 2020 19:08:54 GMT+0800 (China Standard Time)

Hi Walter, I would happily test your patches for the alternate chain. I am in the same situation - using acme-tiny for its simplicity and easy integration (it does just the key part, no further steps, the rest is handled by my update script) and I want to keep the DST root as long as possible.

Thanks a lot in advance,

Pavel.

Walter Hop · Answer 3 · Wed Dec 16 2020 19:58:17 GMT+0800 (China Standard Time)

Hi @pavhofman , we are currently working on it, and are hoping to provide a PR for this feature.

Patrick Damery · Answer 4 · Thu Dec 17 2020 00:14:29 GMT+0800 (China Standard Time)

Hey @pavhofman, we've created a fork of this repo with the updated script here.

It works exactly as the current script does except that it has a new parameter --alternate-chain. If defined it will download the alternate certificate from LetsEncrypt otherwise it'll download the default certificate.

Let us know if you run across any errors in your tests.

pavhofman · Answer 5 · Tue Dec 22 2020 17:56:10 GMT+0800 (China Standard Time)

Hi, thanks a lot! The --alternate-chain param seems to work OK. Perhaps some log.info() could inform about using the alternate chain, maybe.

Now with the latest agreement between LE and IdenTrust to extend the cross-signing R3 to 3 years https://letsencrypt.org/2020/12/21/extending-android-compatibility.html the certificate obtained via the alternate chain seems to be the same as directly - R3 in both cases. It seems LE has changed the setup on their side and does not offer the X3 cert anymore.

Anyway thanks a lot for your work, I believe your patch should make it to acme-tiny.

With regards,

Pavel.

PieceX · Answer 6 · Fri Dec 25 2020 16:53:32 GMT+0800 (China Standard Time)

Hi there @patrickdamery . I ran into an error with the updated script:

File "acme_tiny_ac.py", line 68, in _send_signed_request
    alt_link = alternate_links[0] # It is possible to have more than 1 alternate link, currently only 1 is available for LetsEncrypt.
IndexError: list index out of range

Switching back to the old version without the parameter for alternate chains worked fine.

Marcus Furlong · Answer 7 · Fri Jan 22 2021 22:41:22 GMT+0800 (China Standard Time)

Ran into this issue and the updated version linked here worked for me. Would it be possible to open a PR from that fork?

Roland Häder · Answer 8 · Sat Feb 27 2021 08:56:20 GMT+0800 (China Standard Time)

That would be cool! Please see my topic: https://community.letsencrypt.org/t/ssllabs-and-extra-certs-to-be-downloaded/146271

Walter Hop · Answer 9 · Sun May 16 2021 16:52:02 GMT+0800 (China Standard Time)

Hi @furlongm, sorry for the late reply, I created a pull request for the change here: #259

Daniel Roesler · Answer 10 · Sun Aug 22 2021 05:02:39 GMT+0800 (China Standard Time)

I believe this has been made a non-issue by https://letsencrypt.org/2020/12/21/extending-android-compatibility.html correct?

Daniel Roesler · Answer 11 · Sun Sep 12 2021 03:24:30 GMT+0800 (China Standard Time)

Closing as no longer relevant

rajeevn1 · Answer 12 · Sat Oct 02 2021 05:14:51 GMT+0800 (China Standard Time)

Can we please support alternate chains. This issue is not moot- please check.

https://forum.xda-developers.com/t/all-devices-private-dns-broken-with-lets-encrypt-even-on-new-devices.4341355/#post-85714319

Saga Musix · Answer 13 · Sun Oct 03 2021 04:27:00 GMT+0800 (China Standard Time)

Indeed, this has become more relevant again because of clients stuck on OpenSSL 1.0.2 (which is e.g. still used by CentOS). They will fail to connect to a server using the default chain that is supposed to help with old Android devices, so now we have to decide whether old Android devices or old CentOS boxes are more relevant to us. There are workaround for OpenSSL if you can edit its trust store, but not every user may be able to do that.

Walter Hop · Answer 14 · Wed Oct 06 2021 00:55:11 GMT+0800 (China Standard Time)

I agree. We are having some trouble with niche HTTP clients that do not validate the default chain (for instance TortoiseSVN, a Windows Subversion client which uses its own bundled OpenSSL). We need to serve those customers the alternate chain.

To make a long story short: the default chain works well on old Android devices, but not on old OpenSSL clients. The alternate chain will not support old Android, but works well with OpenSSL.

So an admin must make a choice which chain to use. For us, it depends on the clients consuming the service. We'd need the alternate chain on a subset of servers. Therefore this feature has become essential for us.

Our fork at https://github.com/SlikNL/acme-tiny has the alternate chain feature, but it could use more testing. Unfortunately, the developer who made the PR is no longer with us, and my Python knowledge is low, so it may need a bit of love before it can be integrated, but feel free to incorporate it.