The acme.sh staging trap, scheduled for 60 days from now

Why it is silent

Let's Encrypt runs two separate environments. Production signs with roots that browsers trust. Staging speaks the same protocol and runs the same flow, but signs with a deliberately fake root — and says so in the name: "Pretend Pear", "Artificial Apricot".

Staging exists so you can rehearse automation without burning through strict rate limits. The trouble starts when a rehearsal becomes a permanent setting. acme.sh writes the domain configuration at first issuance and never asks again:

# ~/.acme.sh/example.com/example.com.conf
Le_API='https://acme-staging-v02.api.letsencrypt.org/directory'

As long as that line stands, every run of acme.sh --cron goes to staging. And if the certificate currently installed is a valid production one issued by hand, there is no symptom at all. This is a genuinely time-delayed fault: its trigger is not a code change but the calendar.

Detection

One line scans every domain on the server at once:

grep -r 'acme-staging' ~/.acme.sh/*/*.conf

Empty output means you are clean. Every matching line is a domain that will break at its next renewal.

You can also ask the live server who actually signed the certificate it is serving:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -issuer -dates

If the issuer line contains "(STAGING)" or "Pretend", the problem is already live today. If it does not, but grep found a match, the problem is scheduled.

One more trap: a single server may host dozens of domains and only one of them may point at staging. Run the check across the whole directory, not per domain.

The fix

Editing the configuration file by hand is not enough, because acme.sh can regenerate it. The correct route is to reissue the certificate with the production server named explicitly:

acme.sh --issue -d example.com -d www.example.com \
  --server letsencrypt \
  --webroot /usr/local/lsws/Example/html \
  --force

--force is required because acme.sh would otherwise skip the job: the existing certificate has not expired yet. --server letsencrypt pins Le_API back to production.

So the same mistake does not repeat on new domains, set the default CA once:

acme.sh --set-default-ca --server letsencrypt

Do not forget the install step — obtaining a certificate is not the same as deploying it. Define the target files and the reload command with --install-cert so renewals complete end to end:

acme.sh --install-cert -d example.com \
  --key-file       /etc/letsencrypt/live/example.com/privkey.pem \
  --fullchain-file /etc/letsencrypt/live/example.com/fullchain.pem \
  --reloadcmd      "/usr/local/lsws/bin/lswsctrl reload"

Verification

After the fix, check three things in order:

# 1) Does the configuration point at production now?
grep Le_API ~/.acme.sh/example.com/example.com.conf

# 2) Who signed what the server is actually serving?
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -issuer -enddate

# 3) Does a renewal dry run complete cleanly?
acme.sh --cron --home ~/.acme.sh --dry-run

The third step is the valuable one: instead of waiting for renewal day, you see today what will happen on it.

Early warning

What faults in this class have in common is that they stay invisible until you go looking. A simple scheduled check removes the surprise: read the certificate's expiry and issuer once a day, and alert when fewer than 21 days remain or the issuer is not what you expect.

Run the check from outside, over a TLS connection, not against the file on disk. The file can be correct while the web server is still serving something else; what matters is the certificate a visitor is handed.

Summary

Staging environments exist for testing, and test settings have a habit of leaking into permanent configuration. In acme.sh that leak hides in a single line and stays quiet for weeks. When you inherit a server, or whenever you are investigating certificate trouble, make grep -r 'acme-staging' ~/.acme.sh/*/*.conf the first command you type — it costs three seconds and saves a day later.