Let's Encrypt short-lived certificates are quite strict, so you should use an ARI-capable client

Let's Encrypt short-lived certificates are much harder than they look if you think of them as just a shorter version of 90-day certificates.

If you issue and renew multiple certificates for multiple subdomains in a short interval, you can hit certificate issuance rate limits more easily. Short-lived certificates increase the number of renewals, so these limits become much more visible.

https://letsencrypt.org/docs/rate-limits/

You should test in the staging environment first

For development and testing, you should use the staging environment instead of production. It has the same kind of behavior, but the limits are much looser. That makes it safer when you are still deciding how to split certificates and how to renew them.

https://letsencrypt.org/docs/staging-environment/

Short-lived certificates hit rate limits more easily

Short-lived certificates are valid for only 160 hours. Let's Encrypt recommends renewing them every 3 days. That means many more renewals than 90-day certificates, so rate limits become much easier to hit.

https://letsencrypt.org/2026/01/15/6day-and-ip-general-availability

https://letsencrypt.org/docs/faq/

The strictest limit here is the one for the same exact set of domain names: 5 certificates per 7 days. If you keep issuing certificates for the same set of names, you get close to that limit quickly.

Also, this limit does not fully reset all at once after 7 days. Let's Encrypt says the ability to request new certificates for the same exact set of identifiers refills at a rate of 1 certificate every 34 hours. With short-lived certificates, the renewal interval is short, so this refill speed matters too.

https://letsencrypt.org/docs/rate-limits/

If you split certificates by subdomain, the number of certificates grows. Also, subdomains under the same registered domain share the same bucket, so there is less room than it first seems.

It gets worse if you issue both RSA and ECDSA certificates

If you use both RSA and ECDSA, you need two certificates for the same domain names.

That means the number of certificates doubles immediately.

With short-lived certificates, the renewal interval is already short, so a setup that splits certificates by subdomain and also keeps both RSA and ECDSA certificates can hit rate limits quite easily.

That is why you should use an ARI-capable client

This is where ARI becomes important. ARI means ACME Renewal Information. It is a mechanism that lets the CA tell the ACME client when it should renew a certificate.

With Let's Encrypt, renewals that use ARI are exempt from all rate limits. Since short-lived certificates assume renewal every 3 days, this difference is large. It matters even more if you want both RSA and ECDSA certificates.

If you want to use short-lived certificates, you should use an ARI-capable client.

ARI is not inside the certificate

ARI is not a certificate extension. Even if you inspect a certificate with openssl x509 -text, you cannot tell whether it was renewed with ARI.

ARI works through ACME renewalInfo, so it is part of the ACME protocol, not part of the certificate itself. To know whether ARI is being used, you need to look at the client and the CA interaction, not only at the certificate.

lego is very useful for this

If you want to use short-lived certificates, you need both shortlived profile support and ARI support. lego supports both, so it is very useful for this use case.

https://github.com/go-acme/lego

Its usage is also simple. Use run for the first issuance, then use renew for later renewals. For short-lived certificates, --profile shortlived is the important option, and renew --dynamic is a simple way to run renewals. If you change --server to the staging URL, you can test the same setup in staging.

For example, the first issuance looks like this:

lego \
  --accept-tos \
  --email [email protected] \
  --server https://acme-v02.api.letsencrypt.org/directory \
  --dns route53 \
  --domains example.com \
  --domains www.example.com \
  run \
  --profile shortlived

Renewal looks like this:

lego \
  --accept-tos \
  --email [email protected] \
  --server https://acme-v02.api.letsencrypt.org/directory \
  --dns route53 \
  --domains example.com \
  --domains www.example.com \
  renew \
  --dynamic \
  --profile shortlived

If you want to test in staging, change --server to this:

--server https://acme-staging-v02.api.letsencrypt.org/directory

I still do not know whether it is ready for real production use

I still do not know how practical short-lived certificates are for real production services.

At least for now, I am using them on personal domains, and that already showed several problems.

First, short-lived certificates increase the number of renewals, so CA logs also increase. There is simply too much to monitor.

Also, the maximum validity is only 160 hours, so common certificate monitoring services tend to stay in a critical state all the time.

And as described above, these certificates are also more likely to hit rate limits.

Because of these characteristics, my own site started breaking more often after I switched to short-lived certificates. The feature is interesting, but I think stable operations are still hard if you want to use it widely in real services.

Conclusion

With Let's Encrypt short-lived certificates, it is easier to hit certificate issuance limits.

It gets even harder if you want both RSA and ECDSA certificates, because the number of certificates simply doubles. Since short-lived certificates also renew more often, a setup with multiple subdomains can get close to rate limits much faster than expected.

To make this easier to operate, it is very important to test in staging first and to use an ARI-capable client.