Small ACME client written with process isolation and minimal privileges in mind http://git.guilhem.org/lacme/atom?h=debian%2F0.8.2-1 2023-04-25T18:06:22Z 2023-04-25T18:06:22Z Guilhem Moulin guilhem@fripost.org 2023-04-25T18:06:22Z urn:sha1:c80a2530eb014b34a314e078fec2589bc7969e33 2023-04-25T09:11:03Z Guilhem Moulin guilhem@fripost.org 2023-04-25T08:51:36Z urn:sha1:53238c70f7a12e233a6ca83cf2b50168e5b9592e 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! 2023-01-25T02:23:51Z Guilhem Moulin guilhem@fripost.org 2023-01-25T02:23:51Z urn:sha1:b3af3526b293f396da02a6276ea86ca17dcd2d03 2021-02-25T09:30:22Z Guilhem Moulin guilhem@fripost.org 2021-02-25T00:41:59Z urn:sha1:9a8f705eddd18ccc9a24fe0e7efe6b5a87b2be09 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. 2021-02-24T20:32:01Z Guilhem Moulin guilhem@fripost.org 2021-02-24T20:01:12Z urn:sha1:c612a7ff44995f4f9c39fa0fb68470d90c88decf Also, always spawn the client with umask 0022 so a starting lacme(8) with a restrictive umask doesn't impede serving challenge response files. 2021-02-22T23:20:32Z Guilhem Moulin guilhem@fripost.org 2021-02-22T23:20:32Z urn:sha1:af5e3d794fc2f83f6cc3b5ddff386dad5463707d 2021-02-22T02:19:57Z Guilhem Moulin guilhem@fripost.org 2021-02-22T02:19:57Z urn:sha1:3eba02ef820a393bd5781be9f8fcda1611ae7c3d 2021-02-22T00:05:06Z Guilhem Moulin guilhem@fripost.org 2021-02-22T00:04:58Z urn:sha1:ed85b6a6740028ce9ce821975a534f696eabd8ed 2021-02-21T23:14:51Z Guilhem Moulin guilhem@fripost.org 2021-02-21T17:49:14Z urn:sha1:9898b1877ce2973bbc336921969bd7f16d3698fa This saves a round trip and provides a safeguard against malicious clients. 2021-02-21T18:41:40Z Guilhem Moulin guilhem@fripost.org 2021-02-21T13:27:50Z urn:sha1:ba6addf54cef0b1536dc87c42a41b4dc207ac884 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.