ACME Automation & SSL Renewal Best Practices for 2026

What Changed: Let's Encrypt in 2025-2026

Before diving into automation, it is worth understanding the recent changes that affect how you plan your renewal strategy:

• 6-day short-lived certificates — available since February 2025, subscribers can opt into certificates valid for only six days. These should be renewed every three days (50% lifetime). Short-lived certificates reduce the window of exposure if a private key is compromised and eliminate the need for revocation checking (OCSP/CRL).
• ACME Renewal Information (ARI) — Let's Encrypt now provides a renewal hint via the ARI extension (draft-ietf-acme-ari). Clients that support ARI receive a suggested renewal window from the CA, which helps spread renewal load and makes renewals exempt from rate limits.
• Authorization caching for 30 days — once a domain validation succeeds, the authorization is cached for up to 30 days. Repeat certificate requests for the same domain skip revalidation within this window.
• Updated rate limits — 300 new orders per account every 3 hours; 50 certificates per registered domain per week; 5 duplicate certificates per week. ARI-coordinated renewals are exempt from most limits.

Choosing an ACME Client

The two most widely deployed ACME clients are Certbot and acme.sh. Both are mature, well-maintained, and support the full ACME v2 protocol. Here is how they compare:

Recommendation: Use Certbot if you want the simplest path with Nginx/Apache auto-configuration. Use acme.sh if you need broad DNS API support, want to run unprivileged, or prefer zero external dependencies.

Step-by-Step: Certbot with Nginx

1. Install Certbot

# Ubuntu/Debian
sudo apt update && sudo apt install certbot python3-certbot-nginx -y

# Verify installation
certbot --version

2. Issue an ECDSA Certificate

# ECDSA P-256 — faster handshakes, smaller certificates
sudo certbot --nginx --key-type ecdsa --elliptic-curve secp256r1 \
  -d example.com -d www.example.com

Certbot's Nginx plugin automatically modifies your server block to add ssl_certificate and ssl_certificate_key directives and sets up the HTTP-to-HTTPS redirect.

3. Verify the Renewal Timer

# Check the systemd timer is active
systemctl status certbot.timer

# List scheduled timers
systemctl list-timers certbot.timer

The timer runs twice daily by default. Certbot only actually renews when a certificate is within 30 days of expiry.

4. Add a Deploy Hook

# Create a deploy hook that validates config before reloading
sudo mkdir -p /etc/letsencrypt/renewal-hooks/deploy
sudo tee /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh <<'EOF'
#!/bin/bash
nginx -t 2>/dev/null && systemctl reload nginx
EOF
sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh

5. Dry-Run Test

# Simulate renewal without touching real certificates
sudo certbot renew --dry-run

If the dry run succeeds, your automation is correctly wired. If it fails, check the troubleshooting section below.

Step-by-Step: acme.sh with DNS Validation

DNS-01 validation is the only challenge type that supports wildcard certificates and works behind firewalls where HTTP-01 cannot reach port 80. acme.sh has built-in support for 100+ DNS providers via API.

1. Install acme.sh

curl https://get.acme.sh | sh -s [email protected]

# Reload shell to pick up the alias
source ~/.bashrc

The installer creates ~/.acme.sh/, registers a daily cron job, and does not require root.

2. Export DNS API Credentials

# Example: Cloudflare API token
export CF_Token="your-cloudflare-api-token"
export CF_Zone_ID="your-zone-id"

3. Issue a Wildcard Certificate

acme.sh --issue \
  -d example.com \
  -d '*.example.com' \
  --dns dns_cf \
  --keylength ec-256

4. Install the Certificate for Nginx

acme.sh --install-cert -d example.com \
  --key-file /etc/nginx/ssl/example.com.key \
  --fullchain-file /etc/nginx/ssl/example.com.fullchain.pem \
  --reloadcmd "nginx -t 2>/dev/null && systemctl reload nginx"

The --reloadcmd is saved and re-executed automatically on every renewal. Always include nginx -t before the reload to prevent a broken config from taking Nginx down.

5. Verify the Cron Job

# Check the cron entry exists
crontab -l | grep acme.sh

# Expected output (time may vary):
# 0 0 * * * "/home/user/.acme.sh"/acme.sh --cron --home "/home/user/.acme.sh" > /dev/null

Adopting Let's Encrypt 6-Day Certificates

Short-lived certificates (valid for 6 days) reduce the risk window if a key is compromised and eliminate the dependency on OCSP for revocation. The tradeoff is that your renewal automation must be rock-solid — there is no 30-day buffer.

Renewal cadence

• 90-day certificates: renew every 60 days (30-day buffer)
• 6-day certificates: renew every 3 days (3-day buffer)

Requirements before switching

• Your ACME client must support the short-lived certificate profile. Check your client's documentation for the flag or configuration option.
• Renewal must run at least every 3 days — preferably multiple times daily for redundancy.
• DNS-01 validation must propagate reliably within minutes if you use DNS challenges.
• Monitoring and alerting must be in place to catch renewal failures within hours, not days.

Recommended cron for 6-day certificates

# Run renewal checks every 8 hours (3x daily)
0 */8 * * * /usr/bin/certbot renew --quiet --deploy-hook "nginx -t && systemctl reload nginx"

ACME Renewal Information (ARI)

ARI is a protocol extension that allows the CA to suggest the optimal renewal window for each certificate. Instead of blindly renewing at a fixed offset (e.g., 30 days before expiry), the client asks the CA when to renew and receives a time window.

Benefits of ARI:

• Rate limit exemption — ARI-coordinated renewals are exempt from most Let's Encrypt rate limits.
• Incident-driven renewal — if Let's Encrypt needs to revoke certificates (e.g., due to a CA incident), ARI can push the renewal window forward, triggering early renewal before revocation.
• Load distribution — ARI staggers renewals to prevent thundering-herd spikes on the CA infrastructure.

To benefit from ARI, ensure your ACME client is up to date. Certbot 2.7+ and recent versions of acme.sh include ARI support. The client handles it transparently — no manual configuration is required beyond keeping the client updated.

# Update Certbot to the latest version
sudo apt update && sudo apt install --only-upgrade certbot -y
certbot --version

# Update acme.sh
acme.sh --upgrade

Understanding Let's Encrypt Rate Limits

Hitting rate limits during an incident is a nightmare scenario — you cannot renew when you need it most. Here are the current limits and how to stay clear of them:

Best practices to avoid rate limit issues:

• Use the staging environment (--staging or --test) for all testing and development. Staging has much higher limits.
• Consolidate domains into fewer certificates using SANs instead of issuing one certificate per subdomain.
• Fix validation errors (DNS propagation, firewall rules) before retrying — failed validations eat into your hourly limit.
• Use ARI-enabled clients — ARI-coordinated renewals bypass most limits.

Monitoring and Alerting

Automated renewal is only as good as your monitoring. Silent failures — a DNS API key that expired, a firewall rule that changed, a full disk — will not announce themselves.

Certificate expiry check (cron)

#!/bin/bash
# check-cert-expiry.sh — alert if certificate expires within N days
DOMAIN="example.com"
WARN_DAYS=14

EXPIRY=$(echo | openssl s_client -servername "$DOMAIN" -connect "$DOMAIN":443 2>/dev/null \
  | openssl x509 -noout -enddate | cut -d= -f2)
EXPIRY_EPOCH=$(date -d "$EXPIRY" +%s)
NOW_EPOCH=$(date +%s)
DAYS_LEFT=$(( (EXPIRY_EPOCH - NOW_EPOCH) / 86400 ))

if [ "$DAYS_LEFT" -lt "$WARN_DAYS" ]; then
  echo "WARNING: $DOMAIN certificate expires in $DAYS_LEFT days ($EXPIRY)" | \
    mail -s "Certificate Expiry Warning: $DOMAIN" [email protected]
fi

What to monitor

• Certificate expiry date — alert at 14 days (90-day certs) or 2 days (6-day certs).
• Renewal log output — check /var/log/letsencrypt/letsencrypt.log (Certbot) or ~/.acme.sh/acme.sh.log for errors.
• Deploy hook execution — verify Nginx actually reloaded by checking systemctl status nginx after renewal.
• Certificate serial/fingerprint change — confirm the served certificate is actually the new one, not a stale cached copy.

Troubleshooting Checklist

When renewal fails, work through this checklist:

certbot --version        # should be 2.7+
acme.sh --version        # update with: acme.sh --upgrade

# Test outbound HTTPS connectivity
curl -sI https://acme-v02.api.letsencrypt.org/directory | head -1
# Expected: HTTP/2 200

# From an external machine:
curl -sI http://example.com/.well-known/acme-challenge/test
# Should return 404 from your server, not a firewall block or CDN error

# Check if the TXT record is visible
dig -t TXT _acme-challenge.example.com +short
# Should return the challenge token value

# Check recent certificate issuance for your domain
# Visit: https://crt.sh/?q=example.com
# Count certificates issued in the last 7 days

# Test the API directly (Cloudflare example)
curl -s -H "Authorization: Bearer $CF_Token" \
  "https://api.cloudflare.com/client/v4/zones/$CF_Zone_ID" | jq '.success'

df -h /etc/letsencrypt
df -h ~/.acme.sh

# Test the hook manually
nginx -t && systemctl reload nginx && echo "Hook OK"

FAQ

References

• Let's Encrypt Documentation — official docs covering ACME protocol, rate limits, and certificate lifetimes.
• acme.sh GitHub Repository — full documentation for the acme.sh ACME client.
• Certbot Documentation — official Certbot user guide and API reference.
• RFC 8555 — Automatic Certificate Management Environment (ACME) protocol specification.
• Let's Encrypt Rate Limits — current rate limit values and override request process.

Conclusion

Certificate renewal automation is no longer optional — it is the baseline. With Let's Encrypt now offering 6-day certificates and ACME Renewal Information, the ecosystem is pushing toward shorter-lived credentials that are renewed frequently and automatically. The security benefits are real: a compromised key is useful for days instead of months.

The investment is modest: choose your ACME client, wire up a deploy hook that validates before reloading, add expiry monitoring from an independent vantage point, and test with --dry-run regularly. Get this foundation right and you will never page on an expired certificate again.