This information can now be retrieved on-demand using the debug:cert_index()
command, so we don't need to log it after every scan (it is rather verbose).
This removes one manual (yet undocumented) step that was supposed to be
done to get a complete 'intermediate' configuration.
This file can be found on the Internet by searching for "ffdhe2048" and
can be verified by comparing the hexadecimal representation of p from
the RFC with the output of `openssl asn1parse`.
Given the preference and prevalence of ECDHE, it seems likely that few
would have noticed this.
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.
This now requires that the network backend exposes a tls_builder
function, which essentially wraps the former util.sslconfig.new()
function, passing a factory to create the eventual SSL context.
That allows a net.server backend to pick whatever it likes as SSL
context factory, as long as it understands the config table passed by
the SSL config builder. Heck, a backend could even mock and replace the
entire SSL config builder API.
For this, various accessor functions are now provided directly on the
sockets, which reach down into the LuaSec implementation to obtain the
information.
While this may seem of little gain at first, it hides the implementation
detail of the LuaSec+LuaSocket combination that the actual socket and
the TLS layer are separate objects.
The net gain here is that an alternative implementation does not have to
emulate that specific implementation detail and "only" has to expose
LuaSec-compatible data structures on the new functions.
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.
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.
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
Matthew Wild