Free Certificate Auto-Renewal: acme.sh Configuration, crontab, and Troubleshooting

Free certificates typically have a validity period of 90 days. Manual renewal means remembering to renew four times a year, and things left to human memory will inevitably be missed—the moment you miss one is when your entire site’s HTTPS fails and users see security warnings.

Therefore, auto-renewal is not about “saving trouble,” but is the only reliable approach. However, there is a trap with auto-renewal: it may fail silently at some point without notifying you, until the certificate actually expires.

Installation and Issuance

# Install
curl https://get.acme.sh | sh
source ~/.bashrc

# Set default CA (optional)
acme.sh --set-default-ca --server letsencrypt

Method 1: HTTP Validation (Requires Port 80 Accessibility)

acme.sh --issue -d example.com -d www.example.com -w /var/www/html

Method 2: DNS Validation (Required for Wildcard Domains)

# Example using DNS API; configure credentials in environment variables first
export DP_Id='Your_ID'
export DP_Key='Your_Key'

# Issue certificate (including wildcard)
acme.sh --issue --dns dns_dp -d example.com -d '*.example.com'

Wildcard certificates can only use DNS validation; this is a protocol requirement, not a tool limitation.

Installing Certificates to Nginx

acme.sh --install-cert -d example.com 
  --key-file       /etc/nginx/ssl/example.com.key 
  --fullchain-file /etc/nginx/ssl/example.com.crt 
  --reloadcmd      "systemctl reload nginx"

server {
    listen 443 ssl http2;
    server_name example.com www.example.com;

    ssl_certificate     /etc/nginx/ssl/example.com.crt;   # fullchain
    ssl_certificate_key /etc/nginx/ssl/example.com.key;

    ssl_protocols TLSv1.2 TLSv1.3;
}

--install-cert will automatically copy the renewed certificate to the specified location and execute the reload command. This step cannot be skipped—if you directly reference files under ~/.acme.sh/, issues may arise due to path structure changes.

Note: Use the fullchain (--fullchain-file); otherwise, the certificate chain will be incomplete, causing browsers to work correctly while some clients fail.

Auto-Renewal

# acme.sh automatically adds a crontab entry upon installation; verify first
crontab -l | grep acme

# Manually add if missing
0 0 * * * "/root/.acme.sh"/acme.sh --cron --home "/root/.acme.sh" > /dev/null

# View existing certificates and expiration dates
acme.sh --list

The default is to check once daily, but it only actually renews when nearing expiration, so it won’t request issuance every day—no need to worry about triggering rate limits.

Common Causes of Renewal Failure

Troubleshooting Commands

# Manually trigger a renewal check
acme.sh --cron

# Force renewal (without waiting for expiration)
acme.sh --renew -d example.com --force

# Debug mode to view detailed process
acme.sh --renew -d example.com --debug

# View logs
tail -50 ~/.acme.sh/acme.sh.log

# Confirm actual certificate expiration time (based on server side)
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null 
  | openssl x509 -noout -enddate

# Verify chain completeness
acme.sh --list | grep -i example

Add Expiration Monitoring

Auto-renewal cannot replace monitoring. Renewals can fail, and failures are silent—so someone must monitor the expiration date.

#!/bin/bash
# check-cert.sh: Alert if expiration is within 15 days
DOMAIN="example.com"
END=$(openssl s_client -connect ${DOMAIN}:443 -servername ${DOMAIN} </dev/null 2>/dev/null 
      | openssl x509 -noout -enddate | cut -d= -f2)
END_TS=$(date -d "$END" +%s)
NOW_TS=$(date +%s)
DAYS=$(( (END_TS - NOW_TS) / 86400 ))

if [ "$DAYS" -lt 15 ]; then
    echo "Warning: ${DOMAIN} certificate has only ${DAYS} days left"   # Connect alert notification here
fi

# Check once a day
0 9 * * * /root/check-cert.sh

Decision Tree

Certificate Expiry / Renewal Anomaly
├─ Check local records via acme.sh --list
├─ Check actual server-side expiry via openssl ← Trust this value
├─ Force renewal --force
│  ├─ Success           → Confirm nginx reloaded and chain is complete
│  └─ Failure           → Review --debug output
│     ├─ Validation method failed → Switch to DNS validation
│     ├─ API key invalid          → Reconfigure
│     ├─ Rate limited             → Wait; do not retry repeatedly
│     └─ reloadcmd failed         → Fix config with nginx -t
└─ Expired and unable to renew    → Temporarily switch to another cert to restore service

Scenario Walkthrough: Auto-renewal Configured, Yet Certificate Expires

Symptom: The site was configured for auto-renewal, yet the certificate expired in production,
causing the entire site’s HTTPS to become unavailable. Upon inspection, the script itself was fine, and manual execution succeeded.

1. First, check if the task ever ran → Check task execution records; found that it hadn’t triggered even once in recent months.
   This narrows the scope from “script error” to “not being called”.
2. Check the status of the task scheduler itself → The scheduled task service was not running
   and did not recover after system restart. This is the most easily overlooked link: the renewal script depends on the scheduler,
   which does not start itself.
3. Run manually once to confirm the script still works → Manual execution successfully issued a certificate,
   indicating the script logic and configuration were correct; the issue lay solely in the scheduling环节.
4. Restore the scheduler and confirm it starts on boot → Not only start it, but ensure it automatically starts after reboot.
5. Add an independent expiration check → Instead of relying on whether renewal succeeds,
   directly check how many days remain on the certificate and alert if below threshold.
6. Incorporate “days remaining” into routine monitoring → Even if the renewal chain fails silently again,
   there is a second path to detect it early.

# Did the task run? First check the scheduler service itself
systemctl status cron 2>/dev/null || systemctl status crond 2>/dev/null
systemctl is-enabled cron 2>/dev/null || systemctl is-enabled crond 2>/dev/null

# Check if this specific task has execution records
grep -i 'cron|acme' /var/log/syslog 2>/dev/null | tail -20
journalctl -u cron --since '30 days ago' | tail -20

# Manually force renewal (confirm script itself is not broken)
acme.sh --renew -d example.com --force

# Independent check of remaining days—not dependent on renewal success
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null 
  | openssl x509 -noout -enddate

Root Cause: The scheduled task service did not automatically recover after system restart,
and the renewal script was never triggered. What caused the incident was not a script error, but rather no part of the entire chain proactively alerted that “renewal did not run”.

Two key takeaways:

• The biggest risk of automated renewal is “silent failure”—it doesn’t error out, it just doesn’t run.
  Therefore, do not just monitor the renewal task; independently check the certificate’s remaining days. The two cannot replace each other.
• After configuring automation, confirm two things: the scheduler is running, and it is set to start on boot.
  Many renewal failures occur because these prerequisites cease to hold after a reboot.

8 Common Pitfalls

1. Configuring renewal and ignoring it: You must have expiration monitoring; otherwise, you won’t know when it fails.
2. Directly referencing files in the .acme.sh directory: Use --install-cert to copy them to a fixed path.
3. Using cert instead of fullchain: Incomplete certificate chain causes some clients to fail.
4. Using HTTP validation for wildcard domains: Wildcards only support DNS validation.
5. Incorrect reloadcmd: Renewal succeeds but nginx isn’t reloaded, so the server still uses the old certificate.
6. No verification after renewal: Use openssl to check the actual server-side expiration time; don’t rely solely on command return codes.
7. Repeated retries triggering rate limits: Investigate the cause before retrying blindly.
8. Moving servers without migrating acme.sh configuration: The new machine lacks renewal tasks, leading to immediate expiration.

Real Customer Feedback (From Cloud Market Reviews and Consultations for Similar Products)

The following excerpts are taken from real buyer reviews and consultations for similar operations services on Alibaba Cloud / Tencent Cloud / Huawei Cloud Cloud Markets (service providers include our store and peers, provided for reference only, not fictional tickets from this site):

10***28 2020-06-23 5.0 Skilled technology good

10***99 2024-08-13 5.0 Affordable price | Skilled technology | Complete after-sales Professional 10***15 2024-07-17 5.0 On-time delivery | Affordable price | Skilled technology 10***45 2024-06-12 5.0 Comprehensive features | Affordable price | Skilled technology Found a reliable merchant for SSL certificate configuration on the cloud market 10***37 2023-08-01 5.0 Affordable price | Skilled technology | Complete after-sales Useful service 10***64 2022-05-24 5.0 Safe and reliable | Complete after-sales | Skilled technology Dedicated for beginners. Easy to use and affordable. 10***65 2021-01-23 5.0 Affordable price | Patient and professional | Skilled technology Fast configuration. 10***54 2020-09-22 5.0 Skilled technology | Affordable price | On-time delivery Handled well. Not bad 10***39 2020-07-30 5.0 Safe and reliable | On-time delivery | Skilled technology The technical guy is very professional and great. Problems are solved promptly. Excellent. Thank you 10***39 2020-07-30 5.0 Safe and reliable | On-time delivery | Patient and professional The technical guy is very professional and great. Problems are solved promptly. Excellent. Thank you 10***39 2020-06-07 5.0 Safe and reliable | Skilled technology | Complete after-sales The guy is very serious and good

10***55 2020-11-09 5.0 Affordable price | Complete after-sales | Skilled technology Price is not expensive. Service is useful 10***75 2020-09-22 5.0 Safe and reliable | Skilled technology | Timely reply Top notch