Documented steps

Use Certbot's --staging flag (equivalent to --server pointing at the staging ACME directory) or --dry-run (which uses the staging server by default unless a custom --server is given) to test issuance without consuming production rate limits or getting a real, trusted cert: certbot certonly --staging --nginx -d example.com
For a no-write-to-disk sanity check of a whole config: certbot renew --dry-run
Note the staging ACME v2 directory URL is https://acme-staging-v02.api.letsencrypt.org/directory; ACME accounts are scoped per environment, so Certbot automatically creates/uses a separate staging account — you don't need to manage that yourself.
Staging certs chain up to untrusted (STAGING)-labeled roots, so browsers/clients will show them as invalid — that's expected; don't add staging roots to a real trust store.
Once staging succeeds, drop --staging/--dry-run and rerun the real command (e.g. certbot certonly --nginx -d example.com) to get a trusted production certificate; ACME accounts differ per environment, so if you used --staging/--test-cert or a custom --server originally you must pass the same flag again for any later 'certbot revoke' on that cert.
Before relying on production issuance at scale, read the current numeric rate limits below so your automation/retry logic respects them.
As of the rate-limits page (last updated 2026-08-05): New Registrations per IP = 10 accounts/3h (refill 1/18min); New Orders per Account = 300/3h (refill 1/36sec), each order may include up to 100 identifiers; New Certificates per Registered Domain = 50/7 days (global, refill 1/202min); New Certificates per Exact Set of Identifiers = 5/7 days (global, refill 1/34h); Authorization Failures per Identifier per Account = 5/hour (refill 1/12min); Consecutive Authorization Failures = up to 1,152 before the identifier is paused.
Official docs: https://letsencrypt.org/docs/staging-environment/, https://letsencrypt.org/docs/rate-limits/, https://eff-certbot.readthedocs.io/en/stable/using.html

Known gotchas

Staging uses the SAME rate-limit categories as production but with much higher values (e.g. staging's New Certificates per Registered Domain is 30000/second, and New Orders per Account is 1500 per 3 hours), so staging success doesn't guarantee you're under production limits.
Revoking certificates does NOT reset rate limits — the resources used to issue them were already consumed, per the rate-limits page.
Renewals coordinated via ACME Renewal Info (ARI) are exempt from ALL rate limits; renewals detected only by matching the exact same identifier set are exempt from New Orders per Account and New Certificates per Registered Domain, but are still subject to Authorization Failures and New Certificates per Exact Set of Identifiers limits.
New Certificates per Exact Set of Identifiers is only 5 per 7 days globally (across all accounts) for the exact same domain list — repeatedly deleting/reinstalling your client config and re-requesting the identical domain set is a common way people trip this.
The staging environment is explicitly documented as a poor fit for CI/dev-environment integration testing (network instability, no way to fake DNS/challenge validation); Let's Encrypt suggests their separate 'Pebble' ACME test server for that use case instead.
Rate-limit error responses include a Retry-After header and a message naming when capacity resets — if you exceed more than one limit at once, the message returned is for whichever limit resets furthest in the future.

Safely test certificate issuance against Let's Encrypt's staging environment before touching production, and understand the current production rate limits so you don't get throttled once you switch.

Documented steps

Known gotchas

Give your agent this knowledge — and 17,300+ more routes

Need this verified for your stack — or a route we don't have yet?