| Commit message (Collapse) | Author | Age | Files |
|
|
|
| |
Only the root certificates are now used as trust anchor.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rather than adding intermediates in the certificate bundle we now
validate the leaf certificate with intermediates as untrusted (used for
chain building only). Only the root certificates are used as trust
anchor.
Not pining intermediate certificates anymore is in line with Let's
Encrypt's latest recommendations:
Rotating the set of intermediates we issue from helps keep the
Internet agile and more secure. It encourages automation and
efficiency, and discourages outdated practices like key pinning.
“Key Pinning” is a practice in which clients — either ACME clients
getting certificates for their site, or apps connecting to their own
backend servers — decide to trust only a single issuing intermediate
certificate rather than delegating trust to the system trust store.
Updating pinned keys is a manual process, which leads to an
increased risk of errors and potential business continuity failures.
— https://letsencrypt.org/2024/03/19/new-intermediate-certificates:
|
|
|
|
|
|
|
|
|
|
| |
versions.
OpenSSL 3.2 from Debian sid spews
Warning: Reading certificate from stdin since no -in or -new option is given
without an explicit `-in /dev/stdin`.
|
| |
|
|
|
|
|
|
|
|
|
| |
Domain names are case insensitive so it shouldn't matter, but Let's
Encrypt (staging) ACME server fails with
400 Bad Request (Invalid identifiers requested :: Cannot issue for "YXJCTT7S6K2RQLVO.lacme-test.guilhem.org": Domain name contains an invalid character)
if the sub-domain part of the subjectName is left all-caps.
|
| |
|
| |
|
| |
|
|
|
|
| |
See https://lists.debian.org/msgid-search/87tty79lwo.fsf@43-1.org .
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
| |
oct("foobar") is 0, definitely not what we want.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
Otherwise we end up with files with mode 0644 owned by root:root, and
subsequent lacme(8) invocations will likely not renew them for a while.
This change also saves a chown(2) call. And the new logic (chown resp.
chmod from root:root resp. 0600) is safe if we ever include private key
material in there too.
|
|
|
|
|
|
|
| |
message.
errno is not set on umask failure, see
https://perldoc.perl.org/functions/umask.
|
| |
|
|
|
|
| |
Due to unknown user/group name.
|
| |
|
| |
|
|
|
|
| |
And doesn't retain root privileges.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
It might croak and we want to log that error also.
|
| |
|
|
|
|
| |
It's handy to be able to run `./test tests/accountd*` or similar.
|
|
|
|
|
|
|
|
|
|
|
| |
“The JWS Protected Header is a JSON object” — RFC 7515 sec. 2.
“The JWS Protected Header MUST include the following fields:
- "alg"
- "nonce"
- "url"
- either "jwk" or "kid"”
— RFC 8555 sec. 6.2.
|
|
|
|
| |
Again…
|
| |
|
|
|
|
|
|
|
|
| |
for 'config'.
This matches the arguably expected behavior that ‘config = %h/foo’ is
passed as ‘--config=%h/foo’ and resolved by lacme-accountd(1) (possibly
remote and with another passwd database).
|
| |
|
| |
|
|
|
|
| |
The staging environment wasn't set properly for the Debian packages.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
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.
|
| |
|
| |
|