| Commit message (Collapse) | Author | Age | Files |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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`.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
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).
|
| |
|
| |
|
|
|
|
| |
Prefixed with a timestamp.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
| |
Not that it make a difference since we don't run suid.
|
|
|
|
| |
This is needed for gpg-encrypted privkeys.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Set $HOME, $USER, $SHELL, $PATH, $LOGNAME to appropriate values (and
perserve $TERM), which matches the login(1) behavior.
|
| |
|
|
|
|
|
|
|
| |
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).
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
Which aliases to `--min-days=-1`, i.e., forces renewal regardless of the
expiration date of existing certificates.
|
|
|
|
| |
configurable.
|
|
|
|
|
|
|
|
|
|
|
| |
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 .
|
| |
|
| |
|
| |
|
|
|
|
| |
For client-initiated account deactivation. See RFC 8555 sec. 7.3.6.
|