Staging Environment - Let's Encrypt

Staging Environment - Let's Encrypt
Staging Environment
See all Documentation
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:
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 Hostnames
limit is 30000 per week.
The
Authorization Failures per Hostname per Account
limit is 200 per hour.
The
Consecutive Authorization Failures per Hostname 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
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
Subject:
O = (STAGING) Internet Security Research Group, CN = (STAGING) Pretend Pear X1
Key type:
RSA 4096
Certificate details:
der
pem
txt
Test websites:
valid
revoked
expired
Bogus Broccoli X2
Subject:
O = (STAGING) Internet Security Research Group, CN = (STAGING) Bogus Broccoli X2
Key type:
ECDSA P-384
Certificate details (self-signed):
der
pem
txt
Certificate details (cross-signed by Pretend Pear X1):
der
pem
txt
Test websites:
valid
revoked
expired
Yearning Yucca Root YE
Subject:
O = ISRG, CN = (STAGING) Yearning Yucca Root YE
Key type:
ECDSA P-384
Certificate details (self-signed):
der
pem
txt
Certificate details (cross-signed by Bogus Broccoli X2):
der
pem
txt
Test websites:
valid
revoked
expired
Yonder Yam Root YR
Subject:
O = ISRG, CN = (STAGING) Yonder Yam Root YR
Key type:
RSA 4096
Certificate details (self-signed):
der
pem
txt
Certificate details (cross-signed by Pretend Pear X1):
der
pem
txt
Test websites:
valid
revoked
expired
Subordinate (Intermediate) CAs
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
Internet Security Research Group
GitHub
Trademark Policy