2025-04-30T00:00:00Z

---

In collaboration with the Internet Engineering Task Force (IETF) community, we have developed the ACME standard to facilitate fully automated certificate issuance. This open standard has gained widespread support, now utilized by dozens of clients across various platforms. On the server-side, many may not be aware that we offer not just one but two distinct open-source ACME server implementations that cater to different needs.

The primary implementation that we utilize in our production environment is known as Boulder. Boulder is a robust solution that encompasses all the essential elements necessary for operating a production certificate authority (CA). This includes crucial features such as policy compliance, database interfaces, challenge verifications, and comprehensive logging mechanisms. For organizations looking to manage their own internal, non-publicly-trusted ACME certificate authority, Boulder can be adapted for such purposes, providing a flexible solution for internal needs.

On the other hand, we also have a smaller implementation called Pebble. Unlike Boulder, which is meant for production use, Pebble is specifically designed for testing purposes. It serves as an invaluable tool for developers and ACME client creators who need a reliable environment to perform various automated and manual testing tasks. For instance, the widely used client Certbot has incorporated Pebble into its development workflow for several years, leveraging it to conduct a series of essential yet realistic checks related to certificate requests and issuance from an ACME server.

Pebble is Easy to Use for ACME Client Testing

For developers and teams engaged in the creation of ACME client applications, Pebble addresses a multitude of challenges. It effectively answers the pressing question of how to verify that an ACME client has been implemented correctly so that it can successfully request and receive certificates from a CA. Pebble allows developers to perform these tests without the need for real domain names or the risk of encountering CA rate limits during routine testing.

Setting up Pebble is a straightforward process. It runs entirely in RAM without the need for any external dependencies or persistent storage. Developers can initiate Pebble with a single command in Golang, getting it operational within seconds. This ease of use makes it an ideal candidate for inclusion in a client's integration test suite, enabling realistic integration tests without the complications tied to third-party domains, CA rate limits, or potential network outages.

Many ACME client projects have already adopted Pebble within their official testing suites, including getssl, Lego, Certbot, simp_le, and several others. In these scenarios, every change made to the ACME client codebase is routinely tested against Pebble, ensuring that new features and fixes maintain compatibility and functionality.

Pebble is Intentionally Different From Boulder

Notably, Pebble is designed to differ from Boulder in strategic ways, providing developers with the opportunity to interact with a variety of ACME implementations. The Pebble codebase explicitly states that in situations where the ACME specification allows for customization or CA choice, Pebble aims to make different choices than Boulder. For example, while the Lets Encrypt service offers its newAccount resource at the path /acme/new-acct, Pebble adopts a different endpoint name: /sign-me-up. This distinction encourages clients to verify the directory structure instead of making assumptions about path names.

Further differences include:

• Pebble intentionally rejects 5% of all requests as having an invalid nonce, even if the nonce was otherwise valid, allowing clients to test their responses to this error condition.
• Pebble reuses valid authorizations only 50% of the time, enabling clients to verify their validation processes under unexpected circumstances.
• Pebble truncates timestamps with a different level of precision than Boulder.
• In contrast to Boulder, Pebble adheres to the notBefore and notAfter fields specified in new-order requests.

The ability for ACME clients to function seamlessly with both versions serves as an effective gauge of their adherence to the ACME specification, rather than relying solely on the behaviors exhibited by the Lets Encrypt service. This design ensures that clients remain compatible with various ACME CAs and prepares them for future updates of Lets Encrypts own API.

Pebble is Useful to Both Lets Encrypt and Client Developers as ACME Evolves

We often leverage Pebble to experiment with new ACME features, implementing them in a simplified format before introducing them to Boulder. This approach allows both our team and client developers to explore and test new functionalities even prior to their deployment on our staging service. The rapid development cycle is feasible because features tested in Pebble do not require the complexities associated with a full-scale CA backend.

We continually encourage ACME client developers to utilize a version of Pebble for testing their clients functionalities and interoperability with ACME. This practice not only streamlines the testing process but also enhances the correctness and stability of their client applications.

Try Out Pebble Yourself

If you're interested in trying Pebble with your ACME client right now, simply execute the following commands on a Unix-like system:

git clone https:cd pebblego run ./cmd/pebble

After a few seconds, youll have a functioning ACME CA directory available at https:

We welcome contributions to the Pebble project. For instance, ACME client developers may wish to incorporate simplified versions of ACME features that are not currently tested in Pebble, thereby enhancing the comprehensiveness of their test suites. Furthermore, if you identify any unintended discrepancies between Pebble and Boulder or between Pebble and the ACME specification, we encourage you to reach out and let us know.

Link copied to clipboard!

Erik Nilsson

Source of the news:   Letsencrypt.org