| Commit message (Collapse) | Author | Age | Files |
|
|
|
| |
Due to unknown user/group name.
|
|
|
|
| |
And doesn't retain root privileges.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
“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).
|
| |
|
| |
|
|
|
|
|
| |
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.
|
|
|
|
| |
Prefixed with a timestamp.
|
|
|
|
| |
Before printing them to the standard error.
|
|
|
|
|
| |
It's an internal flag, but can be useful for authorized_keys(5)
restrictions.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
lacme(8): for --config=, --socket=, --config-certs= (and ‘socket’/
‘config-certs’/‘challenge-directory’ configuration options *before*
privilege drop; and for the [accountd] section ‘command’/‘config’
configuration options *after* privilege drop).
lacme-accountd(1): for --config=, --socket= and --privkey= (and
‘socket’/‘privkey’ configuration options).
This also changes the default configuration file location. lacme(8) and
lacme-accountd(1) now respectively use /etc/lacme/lacme.conf resp.
/etc/lacme/lacme-accountd.conf when running as root, and
$XDG_CONFIG_HOME/lacme/lacme.conf resp. $XDG_CONFIG_HOME/lacme/lacme-accountd.conf
when running as a normal user. There is no fallback to /etc anymore.
|
| |
|
|
|
|
|
|
|
| |
configuration file.
One need to use the lacme-accountd(1) configuration file for that
instead.
|
|
|
|
|
|
|
|
| |
default value.
The previous default, namely /etc/lacme/lacme-accountd.conf, is still
honored when there is the user running lacme doesn't have a
~/.config/lacme/lacme-account.conf configuration file.
|
|
|
|
| |
https://letsencrypt.org/docs/staging-environment/
|
|
|
|
|
|
| |
To correctly extract the parent directory of the socket path. The
previous returned an empty string when the socket path didn't contain
‘/’.
|
|
|
|
|
| |
Using stdin/stdout makes it possible to tunnel the accountd connection
through ssh.
|
|
|
|
| |
This doesn't change the default behavior.
|
| |
|
|
|
|
| |
directory.
|
|
|
|
|
| |
Having both lacme(8) and its webserver component reading from the same
standard input could yield starvation.
|
|
|
|
|
|
| |
That way users prefering that over reverse-proxying can just
source/enable the relevant files without having to uncomment
anything.
|
|
|
|
|
| |
Set $HOME, $USER, $SHELL, $PATH, $LOGNAME to appropriate values (and
perserve $TERM), which matches the login(1) behavior.
|
| |
|
|
|
|
| |
When the accountd socket can't be reached.
|
| |
|
|
|
|
|
|
|
| |
This is a breaking change: lacme(8) resp. lacme-accountd(1) no longer
consider ./lacme.conf resp. ./lacme-accountd.conf as default location
for the configuration file. Doing so has security implications when
running these program from insecure directories.
|
| |
|
|
|
|
| |
This is mostly useful for OCSP Must-Staple.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows us to fully validate provided X.509 chains using that
self-contained bundle, regardless of which CAs is marqued as trusted
under /etc/ssl/certs.
Also, remove cross-signed intermediate CAs from the bundle as they're
useless in a self-contained bundle.
Also, remove decomissioned intermediate CAs Authority X3 and X4 from the
bundle.
This change bumps the minimum OpenSSL version to 1.1.0 (for
verify(1ssl)'s ‘-trusted’ and ‘-show_chain’ options).
|
|
|
|
| |
With the new 'challenge-directory' logic symlinks can be disabled.
|
|
|
|
|
|
|
| |
Since lacme(8) spawns a builtin webserver by default the change doesn't
affect default configurations.
See https://bugs.debian.org/970800 for the rationale.
|
| |
|
|
|
|
| |
This removes the dependency on Types::Serialiser.
|
| |
|
|
|
|
|
| |
Which aliases to `--min-days=-1`, i.e., forces renewal regardless of the
expiration date of existing certificates.
|
|
|
|
| |
configurable.
|
|
|
|
|
| |
Also, move the most common options ('hash', 'keyUsage', 'CAfile',
'min-days') to the default section.
|
|
|
|
| |
symmetrically-encrypted private key.
|
|
|
|
|
| |
* Also suggest a command to generate an ECDSA key not just RSA.
* Hint at which key algorithms are supported.
|
|
|
|
|
|
|
|
|
|
|
| |
To after the process has terminated. This solves a race condition
spewing
accept: Invalid argument at /usr/libexec/lacme/webserver line 80.
(harmless) errors.
Closes: deb#970458
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
|
| |
This allows remotely-controlled lacme processes being controlled without
modifying an config files. See https://bugs.debian.org/955767 .
|
| |
|