How to use the Certbot staging environment

Testing Certbot against a production ACME certificate authority can spend rate-limit budget while a domain, webroot, DNS record, firewall rule, or authenticator plugin is still wrong. The staging environment points Certbot at the test ACME service so the certificate flow can be checked before requesting a browser-trusted certificate.

Certbot can target staging with –staging or its equivalent –test-cert flag when requesting or revoking test certificates. For renewal checks, –dry-run uses the staging server for certonly and renew tests and does not save the temporary certificate files to disk.

Staging ACME accounts are separate from production, and saved staging certificates are test certificates even when Certbot stores them under the normal live and renewal paths. A staging certificate is intentionally untrusted and appears as a test certificate in Certbot output, so remove staging flags and any staging server setting before the final production request.

1. Open a terminal on the server that normally runs Certbot.
2. Choose the same authenticator and domain names planned for production.

   The examples use the webroot authenticator. Keep the same challenge method, webroot path, domain list, and plugin options that the production certificate command will use.

3. Register or reuse a staging account.

   $ sudo certbot register --staging --email admin@example.net --agree-tos --no-eff-email -n
   Saving debug log to /var/log/letsencrypt/letsencrypt.log
   Account registered.

   Certbot can also create the staging account during the first staging certificate request. Registering first makes the staging account boundary visible before any domain challenge is attempted.

4. Confirm Certbot is using the Let's Encrypt staging directory.

   $ sudo certbot show_account --staging
   Saving debug log to /var/log/letsencrypt/letsencrypt.log
   Account details for server https://acme-staging-v02.api.letsencrypt.org/directory:
     Account URL: https://acme-staging-v02.api.letsencrypt.org/acme/acct/<staging-account-id>
     Email contact: admin@example.net

5. Run the certificate request with –staging added to the normal Certbot command.

   $ sudo certbot certonly --webroot -w /var/www/html -d www.example.net --staging

   A staging certificate is not trusted by browsers or ordinary TLS clients. Do not leave it installed for public service after the test.

6. Check the saved certificate entry when the staging request succeeds.

   $ sudo certbot certificates --cert-name www.example.net
   Saving debug log to /var/log/letsencrypt/letsencrypt.log
   Found the following certs:
     Certificate Name: www.example.net
       Domains: www.example.net
       Expiry Date: 2026-09-09 12:00:00+00:00 (INVALID: TEST_CERT)
       Certificate Path: /etc/letsencrypt/live/www.example.net/fullchain.pem
       Private Key Path: /etc/letsencrypt/live/www.example.net/privkey.pem

   The (INVALID: TEST_CERT) marker confirms the certificate came from staging. It is useful proof for testing Certbot storage paths and renewal configuration, not a production TLS result.

7. Use –dry-run when the goal is a renewal or challenge test without saving a staging certificate.

   $ sudo certbot renew --cert-name www.example.net --dry-run
   Saving debug log to /var/log/letsencrypt/letsencrypt.log
   Processing /etc/letsencrypt/renewal/www.example.net.conf
   Congratulations, all simulated renewals succeeded:
     /etc/letsencrypt/live/www.example.net/fullchain.pem (success)

   –dry-run can temporarily adjust and reload web server configuration when web server plugins are involved. Deploy hooks do not run unless –run-deploy-hooks is also used.

   Related: How to test Certbot certificate renewal

8. Request the production certificate after the staging command succeeds.

   $ sudo certbot certonly --webroot -w /var/www/html -d www.example.net --force-renewal

   Remove –staging, –test-cert, and any staging –server value before the production request. A global staging server in Certbot configuration can keep future commands pointed at the test CA.

9. Confirm the replacement certificate no longer has the staging marker.

   $ sudo certbot certificates --cert-name www.example.net
   Saving debug log to /var/log/letsencrypt/letsencrypt.log
   Found the following certs:
     Certificate Name: www.example.net
       Domains: www.example.net
       Expiry Date: 2026-09-09 12:00:00+00:00 (VALID: 89 days)
       Certificate Path: /etc/letsencrypt/live/www.example.net/fullchain.pem
       Private Key Path: /etc/letsencrypt/live/www.example.net/privkey.pem