77 lines
3.1 KiB
Markdown
77 lines
3.1 KiB
Markdown
# 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 and/or LetsEncrypt have 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).
|
|
|
|
|
|
## RSA Key Size
|
|
|
|
The ACME specification is silent as to minimum key size.
|
|
The [CA/Browser Forum](https://cabforum.org/) sets the key size requirements
|
|
which LetsEncrypt adheres to.
|
|
|
|
Effective 2020-09-17, LetsEncrypt further requires all RSA keys for end-entity
|
|
(leaf) certificates have a modulus of length 2048, 3072, or 4096. Other CAs may
|
|
or may not have the same restricted set of supported RSA key sizes.
|
|
For more information
|
|
[read the Official Announcement](https://community.letsencrypt.org/t/issuing-for-common-rsa-key-sizes-only/133839).
|