Since 5cd075ed4fd3 any file matching "fullchain" would be considered for
use.
Dehydrated stores fullchain certs in e.g, fullchain-1641171024.pem and a
symlink fullchain.pem pointing at the latest one. However the current
rule for finding a corresponding private key would try
privkey-1641171024.pem in the same directory, which may not exist.
Allows overriding settings via the global 'ssl' settings as before.
This order was probably accidental. That said, 'ssl' is a giant footgun
we will want to discourage use of.
These provide (a) a way to deal with random assortments of certs
and (b) avoid unnecessary error messages and warnings, according
to #1669 anyway, which this fixes.
Removes the need to enable DANE with two separate settings.
Previously you had to also set `ssl = { dane = true }` to activate DANE
support in LuaSec and OpenSSL.
Quick Fix\u{2122} to stop prevent certmanager from automatically adding
a client certificate for net.http.request, since this normally does not
require such.
lfs.dir() throws a hard error if there's a problem, e.g. no such
directory or permission issues. This also gets called early enough that
the main loop error protection hasn't been brought up yet, causing a
proper crash.
Otherwise the default "certs" would be relative to $PWD, which works
when testing from a source checkout, but not on installed systems where
it usually points to the data directory.
Also, the LuaFileSystem dir() iterator throws a hard error, which may
cause a crash or other problems.
Thanks to debacle for reminding me, in the context of mod_auth_ccert
I wonder if we still need lsec_ignore_purpose, Let's Encrypt seems to
include both client and server purposes in certs.
Backport of 94e341dee51c
The original intent of having kEDH before kEECDH was that if a `dhparam`
file was specified, this would be interpreted as a preference by the
admin for old and well-tested Diffie-Hellman key agreement over newer
elliptic curve ones. Otherwise the faster elliptic curve ciphersuites
would be preferred. This didn't really work as intended since this
affects the ClientHello on outgoing s2s connections, leading to some
servers using poorly configured kEDH.
With Debian shipping OpenSSL settings that enforce a higher security
level, this caused interoperability problems with servers that use DH
params smaller than 2048 bits. E.g. jabber.org at the time of this
writing has 1024 bit DH params.
MattJ says
> Curves have won, and OpenSSL is less weird about them now
This makes
`prosodyctl cert import example.com /path/to/example.com/fullchain.pem`
work. This was never intended to, yet users commonly tried this and got
problems.
This is needed for SNI where certificates are in separate
per-hostname contexts, not the main one.
If there is a cert, it will still require a corresponding key.
The original intent of having kEDH before kEECDH was that if a `dhparam`
file was specified, this would be interpreted as a preference by the
admin for old and well-tested Diffie-Hellman key agreement over newer
elliptic curve ones. Otherwise the faster elliptic curve ciphersuites
would be preferred. This didn't really work as intended since this
affects the ClientHello on outgoing s2s connections, leading to some
servers using poorly configured kEDH.
With Debian shipping OpenSSL settings that enforce a higher security
level, this caused interoperability problems with servers that use DH
params smaller than 2048 bits. E.g. jabber.org at the time of this
writing has 1024 bit DH params.
MattJ says
> Curves have won, and OpenSSL is less weird about them now
