github.com/letsencrypt/boulder@v0.20251208.0/docs/acme-implementation_details.md (about)

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