How to Automate Certificate Renewal with ACME Protocol: A Practical Guide

Handling Common Failures

DNS-01 Propagation Delay

Problem: acme.sh creates the TXT record, but the CA’s validation servers query DNS before the record has propagated. Validation fails.

Fix:

# Increase sleep time between record creation and validation
acme.sh --issue -d "*.example.com" --dns dns_cf --dnssleep 120
# Waits 120 seconds for propagation (default is 20)

HTTP-01 Behind a Reverse Proxy

Problem: The CA hits port 80, but your reverse proxy doesn’t forward /.well-known/acme-challenge/ to the backend where certbot placed the file.

Fix (Nginx):

# Add to your server block (port 80)
location /.well-known/acme-challenge/ {
    root /var/www/certbot;  # Where certbot places challenge files
}

Rate Limits

Problem: Let’s Encrypt limits: 50 certificates per registered domain per week, 5 duplicate certificates per week, 300 new orders per 3 hours.

Fix:

• Use the staging environment for testing: --server https://acme-staging-v02.api.letsencrypt.org/directory
• Combine multiple subdomains into one certificate (SAN) instead of separate certificates
• If you hit limits, wait (there’s no override)

Renewal Succeeds But Service Doesn’t Reload

Problem: Certificate file updated on disk, but Nginx/Apache still serves the old cert from memory.

Fix: Always use a deploy hook:

# Certbot
certbot renew --deploy-hook "systemctl reload nginx"

# acme.sh
acme.sh --install-cert -d example.com --reloadcmd "systemctl reload nginx"

Monitoring Your ACME Automation

Automation that isn’t monitored is automation that fails silently. Here’s the monitoring architecture:

1. Certificate expiry monitoring:

# Prometheus blackbox_exporter checks actual served certificate
probe_ssl_earliest_cert_expiry - time() < 86400 * 14
# Alert if any certificate expires in less than 14 days

2. Renewal log monitoring:

# Check certbot renewal logs for failures
grep -i "failed\|error" /var/log/letsencrypt/letsencrypt.log

3. cert-manager metrics (Kubernetes):

# Alert on certificates not ready
certmanager_certificate_ready_status{condition="False"} == 1

# Alert on certificates expiring soon
certmanager_certificate_expiration_timestamp_seconds - time() < 86400 * 7

ACME for Internal/Private Certificates

ACME isn’t just for public CAs. You can run ACME internally:

# Example: Smallstep as internal ACME CA
step-ca --password-file /etc/step/password.txt

# Configure certbot to use your internal CA
certbot certonly --standalone \
  --server https://ca.internal.example.com/acme/acme/directory \
  -d service.internal.example.com

This gives you the same automation benefits for internal services — mTLS between microservices, internal APIs, development environments — without depending on external CAs.

Learn more: What is ACME Protocol covers the protocol internals in depth.

Beyond Let’s Encrypt: Other ACME CAs

ACME isn’t Let’s Encrypt-specific. Other CAs support it:

All use the same ACME protocol — switch CAs by changing one URL in your client configuration.

When ACME Isn’t Enough

ACME handles DV certificates beautifully. But enterprise environments have certificates that ACME can’t manage:

• OV/EV certificates — require manual organization validation
• Code signing certificates — different issuance process entirely
• Client certificates — for mTLS, device identity, email S/MIME
• Internal CA certificates — unless you run your own ACME-compatible CA
• Legacy systems — mainframes, embedded devices, IoT that can’t run ACME clients
• Multi-CA environments — some certs from DigiCert, some from Sectigo, some internal

For these, you need a Certificate Lifecycle Management platform that handles both ACME-automated and manually-managed certificates in one place.