Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add documentation for RFC-conformant design implementation decisions. (…
…#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.
- Loading branch information
Showing
4 changed files
with
83 additions
and
1 deletion.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,69 @@ | ||
# Boulder implementation details | ||
|
||
The ACME specification ([RFC 8555]) clearly dictates what Clients and Servers | ||
must do to properly implement the protocol. | ||
|
||
The specification is intentionally silent, or vague, on certain points to give | ||
developers freedom in making certain decisions or to follow guidance from other | ||
RFCs. Due to this, two ACME Servers might fully conform to the RFC but behave | ||
slightly differently. ACME Clients should not "over-fit" on Boulder or the | ||
Let's Encrypt production service, and aim to be compatible with a wide range of | ||
ACME Servers, including the [Pebble](https://github.com/letsencrypt/pebble) | ||
test server. | ||
|
||
The following items are a partial listing of RFC-conformant design decisions | ||
Boulder has made. This listing is not complete, and is based on known details | ||
which have caused issues for developers in the past. This listing may not | ||
reflect the current status of Boulder or the configuration of LetsEncrypt's | ||
production instance and is provided only as a reference for client developers. | ||
|
||
Please note: these design implementation decisions are fully conformant with the | ||
RFC specification and are not | ||
[divergences](https://github.com/letsencrypt/boulder/blob/main/docs/acme-divergences.md). | ||
|
||
|
||
## Object Reuse | ||
|
||
The ACME specification does not prohibit certain objects to be re-used. | ||
|
||
### Authorization | ||
|
||
Boulder may recycle previously "valid" or "pending" `Authorizations` for a given | ||
`Account` when creating a new `Order`. | ||
|
||
### Order | ||
|
||
Boulder may return a previously created `Order` when a given `Account` submits | ||
a new `Order` that is identical to a previously submitted `Order` that is in | ||
the "pending" or "ready" state. | ||
|
||
## Alternate Chains | ||
|
||
The production Boulder instance for LetsEncrypt in enabled with support for | ||
Alternate chains. | ||
|
||
|
||
## Certificate Request Domains | ||
|
||
The RFC states the following: | ||
|
||
The CSR MUST indicate the exact same | ||
set of requested identifiers as the initial newOrder request. | ||
Identifiers of type "dns" MUST appear either in the commonName | ||
portion of the requested subject name or in an extensionRequest | ||
attribute [RFC2985] requesting a subjectAltName extension, or both. | ||
|
||
Boulder requires all domains to be specified in the `subjectAltName` | ||
extension, and will reject a CSR if a domain specified in the `commonName` is | ||
not present in the `subjectAltName`. Additionally, usage of the `commonName` | ||
was previously deprecated by the CA/B Forum and in earlier RFCs. | ||
|
||
For more information on this see [Pebble Issue #304](https://github.com/letsencrypt/pebble/issues/304) and | ||
[Pebble Issue #233] https://github.com/letsencrypt/pebble/issues/233 | ||
|
||
|
||
|
||
|
||
|
||
|
||
|