1# Boulder implementation details
2
3The ACME specification ([RFC 8555]) clearly dictates what Clients and Servers
4must do to properly implement the protocol.
5
6The specification is intentionally silent, or vague, on certain points to give
7developers freedom in making certain decisions or to follow guidance from other
8RFCs. Due to this, two ACME Servers might fully conform to the RFC but behave
9slightly differently. ACME Clients should not "over-fit" on Boulder or the
10Let's Encrypt production service, and aim to be compatible with a wide range of
11ACME Servers, including the [Pebble](https://github.com/letsencrypt/pebble)
12test server.
13
14The following items are a partial listing of RFC-conformant design decisions
15Boulder and/or LetsEncrypt have made. This listing is not complete, and is
16based on known details which have caused issues for developers in the past. This
17listing may not reflect the current status of Boulder or the configuration of
18LetsEncrypt's production instance and is provided only as a reference for client
19developers.
20
21Please note: these design implementation decisions are fully conformant with the
22RFC specification and are not
23[divergences](https://github.com/letsencrypt/boulder/blob/main/docs/acme-divergences.md).
24
25
26## Object Reuse
27
28The ACME specification does not prohibit certain objects to be re-used.
29
30### Authorization
31
32Boulder may recycle previously "valid" or "pending" `Authorizations` for a given
33`Account` when creating a new `Order`.
34
35### Order
36
37Boulder may return a previously created `Order` when a given `Account` submits
38a new `Order` that is identical to a previously submitted `Order` that is in
39the "pending" or "ready" state.
40
41## Alternate Chains
42
43The production Boulder instance for LetsEncrypt in enabled with support for
44Alternate chains.
45
46
47## Certificate Request Domains
48
49The RFC states the following:
50
51 The CSR MUST indicate the exact same
52 set of requested identifiers as the initial newOrder request.
53 Identifiers of type "dns" MUST appear either in the commonName
54 portion of the requested subject name or in an extensionRequest
55 attribute [RFC2985] requesting a subjectAltName extension, or both.
56
57Boulder requires all domains to be specified in the `subjectAltName`
58extension, and will reject a CSR if a domain specified in the `commonName` is
59not present in the `subjectAltName`. Additionally, usage of the `commonName`
60was previously deprecated by the CA/B Forum and in earlier RFCs.
61
62For more information on this see [Pebble Issue #304](https://github.com/letsencrypt/pebble/issues/304)
63and [Pebble Issue #233](https://github.com/letsencrypt/pebble/issues/233).
64
65
66## RSA Key Size
67
68The ACME specification is silent as to minimum key size.
69The [CA/Browser Forum](https://cabforum.org/) sets the key size requirements
70which LetsEncrypt adheres to.
71
72Effective 2020-09-17, LetsEncrypt further requires all RSA keys for end-entity
73(leaf) certificates have a modulus of length 2048, 3072, or 4096. Other CAs may
74or may not have the same restricted set of supported RSA key sizes.
75For more information
76[read the Official Announcement](https://community.letsencrypt.org/t/issuing-for-common-rsa-key-sizes-only/133839).
View as plain text