We highly recommend testing against our staging environment before using our production environment. This will allow you to get things right before issuing trusted certificates and reduce the chance of your running up against rate limits.
The ACME URL for our ACME v2 staging environment is:
https://acme-staging-v02.api.letsencrypt.org/directory
If you’re using Certbot, you can use our staging environment with the --test-cert or --dry-run flag. For other ACME clients, please read their instructions for information on testing with our staging environment.
Note that ACME accounts are scoped to each environment, and thus a separate account for the staging environment is required. Certbot handles this for you.
Rate Limits
The staging environment uses the same rate limits as described for the production environment but with different values:
- The New Registrations per IP Address limit is 50 per 3 hours.
- The New Registrations per IPv6 Range limit is 500 per 3 hours (the same as production).
- The New Orders per Account limit is 1500 per 3 hours.
- The New Certificates per Registered Domain limit is 30000 per second.
- The New Certificates per Exact Set of Identifiers limit is 30000 per week.
- The Authorization Failures per Identifier per Account limit is 200 per hour.
- The Consecutive Authorization Failures per Identifier per Account limit is 3600 per 6 hours.
The Overall Requests Limits are:
| Endpoint | Requests per IP (per second) | Burst Capacity |
|---|---|---|
| /acme/new-nonce | 20 | 10 |
| /acme/new-account | 5 | 15 |
| /acme/new-order | 20 | 40 |
| /acme/revoke-cert | 10 | 100 |
| /acme/renewal-info | 1000 | 100 |
| /acme/* | 20 | 20 |
| /directory | 40 | 40 |
Staging Certificate Hierarchy
The staging environment has a certificate hierarchy that mimics production. The names have been modified with a prefix of (STAGING) and unique name to make them clearly distinct from their production counterparts.
Root CAs
The staging environment has four active root certificates which are not present in browser/client trust stores: “(STAGING) Pretend Pear X1”, “(STAGING) Bogus Broccoli X2”, “(STAGING) Yearning Yucca Root YE”, and “(STAGING) Yonder Yam Root YR”.
If you wish to modify a test-only client to trust the staging environment for testing purposes you can do so by adding their certificates to your testing trust store. Important note: Do not add the staging root or intermediate to a trust store that you use for ordinary browsing or other activities, since they are not audited or held to the same standards as our production roots, and so are not safe to use for anything other than testing.
- Pretend Pear X1
- Bogus Broccoli X2
- Yearning Yucca Root YE
- Yonder Yam Root YR
The staging environment has intermediate certificates that mimic production, issued from the untrusted roots detailed above. Like in production, not all are in use at any time. The full list of current intermediates is:
- (STAGING) Pseudo Plum E5
- (STAGING) False Fennel E6
- (STAGING) Puzzling Parsnip E7
- (STAGING) Mysterious Mulberry E8
- (STAGING) Fake Fig E9
- (STAGING) Counterfeit Cashew R10
- (STAGING) Wannabe Watercress R11
- (STAGING) Riddling Rhubarb R12
- (STAGING) Tenuous Tomato R13
- (STAGING) Not Nectarine R14
- (STAGING) Artificial Amaranth YE1
- (STAGING) Baloney Bulgur YE2
- (STAGING) Cad Corn YE3
- (STAGING) Dastardly Durum YR1
- (STAGING) Ersatz Emmer YR2
- (STAGING) Fake Farro YR3
These intermediates are subject to change at any time, and should not be pinned or trusted by any system. In general, you can expect the staging intermediates to parallel the corresponding production (trusted) intermediates. If strictly necessary, you can get full certificate details here.
Certificate Transparency
The staging environment uses several test CT logs. SCTs from these logs are included in staging certificates. However, as staging is a test environment only, CT cannot be used to observe staging issued certificates reliably.
These logs include Let’s Encrypt Testing Logs, as well as test logs from other Certificate Transparency log operators.
Additionally, some ct-test-srv logs may be used, which are not actual logs and do not store issued certificates.
Continuous Integration / Development Testing
The staging environment has generous rate limits to enable testing but it is not a great fit for integration with development environments or continuous integration (CI). Making network requests to external servers can introduce instability and the staging environment offers no way to “fake” DNS or challenge validation success which makes for more complicated test setups.
In addition to the staging environment Let’s Encrypt offers a small ACME server purpose built for CI and development environments called Pebble. Running Pebble on your development machine or in a CI environment is quick and easy.