Skip to content
Permalink
master
Go to file
…#5105)

@jsha suggested I re-implement a PR against Pebble regarding Authorization
reuse into Boulder (see letsencrypt/pebble#325).

This is an initial attempt. I opted to handle this by creating a new file for
"Implementation Details" that are RFC conformant and are known to have
confused client developers.
8 contributors

Users who have contributed to this file

@cpu @jsha @sophie-h @rolandshoemaker @jvanasco @tdelmas @dennis-benzinger-hybris @aarongable
48 lines (27 sloc) 2.62 KB

Boulder divergences from ACME

While Boulder attempts to implement the ACME specification (RFC 8555) as strictly as possible there are places at which we will diverge from the letter of the specification for various reasons. This document describes the difference between RFC 8555 and Boulder's implementation of ACME, informally called ACMEv2 and available at https://acme-v02.api.letsencrypt.org/directory. Boulder's implementation of ACMEv1 differs substantially from the final RFC. Documentation for Boulder's ACMEv1 support is available in acme-divergences-v1.md. A listing of RFC conformant design decisions that may differ from other ACME servers is listed in implementation_details.

Presently, Boulder diverges from the RFC 8555 ACME spec in the following ways:

Section 6.3

We support POST-as-GET but do not yet mandate it. We plan to mandate POST-as-GET for all ACMEv2 requests in November 2020.

Section 6.6

Boulder does not provide a Retry-After header when a user hits a rate-limit, nor does it provide Link headers to further documentation on rate-limiting.

Section 6.7

Boulder uses invalidEmail in place of the error invalidContact.

Boulder does not implement the unsupportedContact and dnssec errors.

Section 7.1.2

Boulder does not supply the orders field on account objects. We intend to support this non-essential feature in the future. Please follow Boulder Issue #3335.

Section 7.4

Boulder does not accept the optional notBefore and notAfter fields of a newOrder request paylod.

Section 7.4.1

Pre-authorization is an optional feature and we have no plans to implement it. V2 clients should use order based issuance without pre-authorization.

Section 7.4.2

Boulder does not process Accept headers for Content-Type negotiation when retrieving certificates.

Section 8.2

Boulder does not implement the ability to retry challenges or the Retry-After header.