100% of our funding comes from people like you. Donate today.

Staging Environment

Se på Dansk

Auf Deutsch ansehen

Ver en español

Voir en Français

לעבור לעברית

Megtekintés magyar nyelven

日本語で表示する

한국어로 보기

Pokaż w języku polskim

Ver em Português (do brasil)

Просмотреть на русском

Visa på svenska

Переглянути українською

阅读简体中文页面

使用正體中文閲讀本網頁。

Last updated: | 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 or --dry-run flag. For other ACME clients, please read their instructions for information on testing with our staging environment.

Rate Limits

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

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 two active root certificates which are not present in browser/client trust stores: “(STAGING) Pretend Pear X1” and “(STAGING) Bogus Broccoli X2”.

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.

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:

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 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.