Support ACME Renewal Information (ARI) #633

Open
opened 2025-12-29 01:28:03 +01:00 by adam · 2 comments
Owner

Originally created by @domrim on GitHub (Feb 4, 2025).

As Let's Encrypt is deprecating Expiration Mails (https://letsencrypt.org/2025/01/22/Ending-Expiration-Emails) it would be nice if dehydrate could support ACME Renewal Information (ARI). For more background, there is a blogpost

An in depth guide for implementing can be found in the Let's Encrypt blog: https://letsencrypt.org/2024/04/25/guide-to-integrating-ari-into-existing-acme-clients/

Originally created by @domrim on GitHub (Feb 4, 2025). As Let's Encrypt is deprecating Expiration Mails (https://letsencrypt.org/2025/01/22/Ending-Expiration-Emails) it would be nice if dehydrate could support [ACME Renewal Information (ARI)](https://datatracker.ietf.org/doc/draft-ietf-acme-ari/). For more background, there is a [blogpost](https://letsencrypt.org/2023/03/23/improving-resliiency-and-reliability-with-ari/) An in depth guide for implementing can be found in the Let's Encrypt blog: https://letsencrypt.org/2024/04/25/guide-to-integrating-ari-into-existing-acme-clients/
Author
Owner

@BtbN commented on GitHub (Feb 11, 2025):

https://github.com/dehydrated-io/dehydrated/pull/959

@BtbN commented on GitHub (Feb 11, 2025): https://github.com/dehydrated-io/dehydrated/pull/959
Author
Owner

@GTAXL commented on GitHub (May 31, 2025):

I agree, this feature should be added. While I don't agree that it's a solution to the expiration e-mails, and you are running dehydrated in a cron or sleep loop anyway to renew at <=32, I think it's a solution for revocation that happens CA side.

For example, in 2020 Let's Encrypt had to revoke approximately 3 million certificates due to not properly validating CAA records. In 2024 DigiCert had to revoke 83,000 certificates due to a bug in their CNAME-based DCV.

Both of these Certificate Authorities support ARI for their ACME servers. If dehydrated supported in, in the event one, or many of your certificates was affected and subsequently revoked, ARI would of sent a shorter expiration date and the certificate would of been renewed within whatever time frame you cycle your dehydrated. This process would of been completely automated in the background and resolved itself, rather than users having to check if their certs are affected and issuing a manual forced renew.

@GTAXL commented on GitHub (May 31, 2025): I agree, this feature should be added. While I don't agree that it's a solution to the expiration e-mails, and you are running dehydrated in a cron or sleep loop anyway to renew at <=32, I think it's a solution for revocation that happens CA side. For example, in 2020 Let's Encrypt had to revoke approximately 3 million certificates due to not properly validating CAA records. In 2024 DigiCert had to revoke 83,000 certificates due to a bug in their CNAME-based DCV. Both of these Certificate Authorities support ARI for their ACME servers. If dehydrated supported in, in the event one, or many of your certificates was affected and subsequently revoked, ARI would of sent a shorter expiration date and the certificate would of been renewed within whatever time frame you cycle your dehydrated. This process would of been completely automated in the background and resolved itself, rather than users having to check if their certs are affected and issuing a manual forced renew.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/dehydrated#633