Caddy/CertMagic/ACMEz: ACMEz is the underlying Go library that facilitates ACME transactions, and CertMagic is the higher-level Go package that maintains certificates over time. Caddy, of course, is the web server that uses the CertMagic+ACMEz stack for its certificate automation. (For disclosure, I authored these.)
Caddy 2.8 and newer uses CertMagic (and ACMEz), so ARI "just works". You won't have to think about it. You will see ARI-related messages in logs from time to time.
While the ARI spec is still in draft state, expect that all the clients in this thread will have to change or update things in the near future.
Yes Certify The Web got draft 03 support at the start of May 2024, we had an implementation of the old draft before that released in May 2023. We implement per-certificate renewalInfo checks twice per day (we also do OCSP checks at the same time) and replaces CertID support.
Posh-ACME also has work in progress ARI draft 03 Support but that's not yet released: https://poshac.me
Tailscale uses ARI but I can't see if they have updated to draft 03, presumably they will if they haven't already.
For those implementing ARI, things to watch out for include:
an invalid replaces certID (wrong format, not the current cert id, previous cert is issued from a different CA etc) will cause the order to error with a Conflict status code [this response could vary between implementations]. Catch your errors and consider skipping "replaces" if you've had a few repeated failures, otherwise you could end up in a self imposed denial of service by way of an unforeseen combination of circumstances.
when checking for renewal info, obviously be prepared for it to go very wrong, so that it doesn't derail any other processes.
the ARI spec doesn't provide a way for CAs to indicate their respective implementation version, so as a result it's not really practical to support multiple versions of the spec.
and in general, always assume your users will not upgrade their client version until their certificates are literally expiring due to a new problem. Consider whether having a direct way to contact users might be necessary in your case. Let's Encrypts service implementation changes fairly frequently and subtle changes can have an unanticipated impact which is specific to your implementation or users context.
Pebble, Let's Encrypt's test ACME server used for developing clients, now has ARI support, so we can more easily test various scenarios as we implement ARI into clients:
As @mholt noted above, Pebble finally has ARI support. I suspect this will make ARI support much more widespread, as Pebble is the test system for many clients.
I didn't bother implementing it on our client, because we had no way to test it (we use Pebble). I assume many other developers are the same. Now that it is supported, integration is now at the top of my list.
Certbot recently ditched Boulder for Pebble in their testing environment. I think this is what finally got ISRG to allocate resources to develop ARI support into Pebble. I would not be surprised to see Certbot supporting ARI in the very near future.
It was not, the work was borne purely out of curiosity. I wanted experience writing a client library hence the eggsampler/acme work which then required a server to support it hence the work on a boulder integration test (to test that the client was working) and pebble (because I couldn't test against it at the time).
Well, thank you (again) for that effort Phil! I tried to write that support multiple times, then gave up. I have not had enough time to learn enough Go to pull it off.
Thanks to your work, so many clients (especially Certbot) will finally be able to support ARI.