| Commit message (Collapse) | Author | Age | Files | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
newOrder.
Instead of just "ready" → "valid", which may be what we observe when the
server is fast enough, but according to RFC 8555 sec. 7.1.6 the state
actually transitions via "processing" state and we need to account for
that.
It appears Let's Encrypt staging environment now has different timing
conditions and lacme is unable to request certificates due to this
issue.
Thanks to Alexander Borkowski for the report!
 | 
| |  | 
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
|  | 
internal client.
So it doesn't have to parse the INI file again.  Also, while lacme.conf
is world-readable by default, one might restrict permissions and add
private information in there, not realizing that everything, including
comments, will be readable by the client.
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
restrictions.
Also, always spawn the client with umask 0022 so a starting lacme(8)
with a restrictive umask doesn't impede serving challenge response
files.
 | 
| |  | 
 | 
| |  | 
 | 
| |  | 
 | 
| | 
| 
| 
| 
|  | 
This saves a round trip and provides a safeguard against malicious
clients.
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Passing the JWA to the ACME client is required if we want to support
account keys other than RSA.  As of 0.7 both lacme-accountd(1) and
lacme(8) hardcode “RS256” (SHA256withRSA per RFC 7518 sec. A.1).
Passing the JWK thumbprint is handy as it gives more flexibility if RFC
8555 sec. 8.1 were to be updated with another digest algorithm (it's
currently hardcoded to SHA-256).  A single lacme-account(1) instance
might be used to sign requests from many clients, and it's easier to
upgrade a single ‘lacme-accountd’ than many ‘lacme’.  Moreover, in some
restricted environments lacme-accountd might hide the JWK from the
client to prevent ‘newAccount’ requests (such as contact updates);
passing its thumbprint is enough for ‘newOrder’ requests.
 | 
| |  | 
 | 
| |  | 
 | 
| | 
| 
| 
|  | 
When the accountd socket can't be reached.
 | 
| |  | 
 | 
| |  | 
 | 
| |  | 
 | 
| |  | 
 | 
| | 
| 
| 
|  | 
This removes the dependency on Types::Serialiser.
 | 
| |  | 
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
This is a breaking change.  The certificate indicated by 'CAfile' is no
longer used as is in 'certificate-chain' (along with the leaf cert).
The chain returned by the ACME v2 endpoint is used instead.  This allows
for more flexbility with respect to key/CA rotation, cf.
https://letsencrypt.org/2020/11/06/own-two-feet.html and
https://community.letsencrypt.org/t/beginning-issuance-from-r3/139018
Moreover 'CAfile' now defaults to @@datadir@@/lacme/ca-certificates.crt
which is a concatenation of all known active CA certificates (which
includes the previous default).
 | 
| |  | 
 | 
| | 
| 
| 
|  | 
For client-initiated account deactivation.  See RFC 8555 sec. 7.3.6.
 | 
| | 
| 
| 
| 
|  | 
For the  authorizations, order and certificate URLs.
See RFC 8555 sec. 7.1.
 | 
| |  | 
 | 
| |  | 
 | 
| | 
| 
| 
|  | 
We were blocking on https://github.com/letsencrypt/boulder/issues/3530 .
 | 
| | 
| 
| 
|  | 
https://tools.ietf.org/html/draft-ietf-acme-acme-12
 | 
| |  | 
 | 
| |  | 
 | 
| |  | 
 | 
| |  | 
 | 
| |  | 
 | 
| |  | 
 | 
| | 
| 
| 
| 
|  | 
Format the problem document if the JSON has an “error” key.  Cf. section
7 “Identifier Validation Challenges”.
 | 
| |  | 
 | 
| |  | 
 | 
| |  | 
 | 
| |  | 
 | 
|    | 
 |