Last updated: Jun 13, 2022 | 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:

https://acme-staging-v02.api.letsencrypt.org/directory

If you’re using Certbot, you can use our staging environment with the --test-cert flag. For other ACME clients, please read their instructions for information on testing with our staging environment. Please note the v2 staging environment requires a v2 compatible ACME client.

Rate Limits

The staging environment uses the same rate limits as described for the production environment with the following exceptions:

The Certificates per Registered Domain limit is 30,000 per week.
The Duplicate Certificate limit is 30,000 per week.
The Failed Validations limit is 60 per hour.
The Accounts per IP Address limit is 50 accounts per 3 hour period per IP.
For ACME v2, the New Orders limit is 1,500 new orders per 3 hour period per account.

Staging Certificate Hierarchy

The staging environment has a certificate hierarchy that mimics production.

Intermediate Certificates

The staging environment has two active intermediate certificates: an RSA intermedite “(STAGING) Artificial Apricot R3” and an ECDSA intermediate “(STAGING) Ersatz Edamame E1”.

ECDSA issuance was enabled in Staging on 24 March 2021 and all requests for Staging certificates with ECDSA keys are signed by “(STAGING) Ersatz Edamame E1” and utilize the ECDSA hierarchy. Similarly all requests for Staging certificates with RSA keys are signed by “(STAGING) Artificial Apricot R3” and use the RSA hierarchy. There is no way to get an RSA-signed certificate for an ECDSA key, nor vice versa; the way to control which issuer you get is to control what kind of key you generate locally.

Root Certificates

The staging environment has two active root certificates which are not present in browser/client trust stores: “(STAGING) Pretend Pear X1” and “(STAGING) Bogus Brocoli X2”. If you wish to modify a test-only client to trust the staging environment for testing purposes you can do so by adding the “(STAGING) Pretend Pear X1” and/or “(STAGING) Bogus Broccoli X2” certificate to your testing trust store. You can find all of our staging certificates here. Important: 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.

Certificate Transparency

The staging environment submits pre-certificates to the Let’s Encrypt Sapling and Google testtube CT test logs and includes returned SCTs in the 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.