http://hg.omfa.de/prosody-hg/ en-us core/certmanager.lua revision history http://hg.omfa.de/prosody-hg/log/565debd9c37a/core/certmanager.lua Matthew Wild <mwild1@gmail.com> Fri, 12 Jun 2026 13:05:10 +0100 http://hg.omfa.de/prosody-hg/log/7f4fcbb1bbe4/core/certmanager.lua
This adds a 'tls_profile_version' configuration option. If unspecified, it
will use the default profile version from util.tlsref. If specified, it must
be either a valid version (known to util.tlsref) or the value "latest".

This allows admins to pin to specific versions, go with the default (for the
best balance between security/stability) or always use the latest available
profiles.]]> Matthew Wild <mwild1@gmail.com> Fri, 12 Jun 2026 13:04:23 +0100 http://hg.omfa.de/prosody-hg/log/2ec517d8d43e/core/certmanager.lua
You know what they say about opt-in security.

Enabling DNSSEC in libunbound without a way to turn it off would likely
be a problem for those whose DNS resolvers do not support, or outright
block DNSSEC. The merge algorithm already in place here doesn't have a
way to unset something, so instead a simpler boolean setting is
introduced, similar to some existing ones like use_ipv6/4 and use_dane.]]> Kim Alvefur <zash@zash.se> Sun, 07 Jun 2026 20:32:55 +0200 http://hg.omfa.de/prosody-hg/log/4aed38a1c971/core/certmanager.lua
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).]]> Matthew Wild <mwild1@gmail.com> Thu, 03 Apr 2025 19:47:16 +0100 http://hg.omfa.de/prosody-hg/log/8a7dbb291b02/core/certmanager.lua Matthew Wild <mwild1@gmail.com> Thu, 03 Apr 2025 16:53:48 +0100 http://hg.omfa.de/prosody-hg/log/49bbdc22846d/core/certmanager.lua
Currently it's not obvious which directories have been indexed (especially
when the resulting index is empty), or why certain files have been skipped.]]> Matthew Wild <mwild1@gmail.com> Mon, 24 Feb 2025 17:48:58 +0000 http://hg.omfa.de/prosody-hg/log/99d2100d2918/core/certmanager.lua
These two settings are only really needed for XMPP server-to-server
connections.]]> Kim Alvefur <zash@zash.se> Sat, 15 Feb 2025 00:19:01 +0100 http://hg.omfa.de/prosody-hg/log/8b68e8faab52/core/certmanager.lua
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.]]> Kim Alvefur <zash@zash.se> Fri, 12 Jul 2024 15:06:42 +0200 http://hg.omfa.de/prosody-hg/log/05c0ac580552/core/certmanager.lua Kim Alvefur <zash@zash.se> Sat, 04 Nov 2023 15:59:51 +0100 http://hg.omfa.de/prosody-hg/log/4a05fbda927f/core/certmanager.lua
Everything supports SNI today, so this is not useful information.]]> Kim Alvefur <zash@zash.se> Sun, 29 Oct 2023 21:31:07 +0100 http://hg.omfa.de/prosody-hg/log/8fbdd878fcf6/core/certmanager.lua Kim Alvefur <zash@zash.se> Fri, 27 Oct 2023 22:38:00 +0200 http://hg.omfa.de/prosody-hg/log/24070d47a6e7/core/certmanager.lua
A typo should not result in ending up with "legacy"]]> Kim Alvefur <zash@zash.se> Fri, 27 Oct 2023 19:03:59 +0200 http://hg.omfa.de/prosody-hg/log/1b1ed555f307/core/certmanager.lua Kim Alvefur <zash@zash.se> Mon, 10 Jul 2023 00:34:37 +0200 http://hg.omfa.de/prosody-hg/log/e689d4c45681/core/certmanager.lua
Ref https://github.com/mozilla/server-side-tls/issues/285]]> Kim Alvefur <zash@zash.se> Sun, 09 Jul 2023 21:18:47 +0200 http://hg.omfa.de/prosody-hg/log/58e793288d9c/core/certmanager.lua
Further isolates LuaSec from Prosody core, with the ultimate goal of
allowing LuaSec to be replaced more easily.]]> Kim Alvefur <zash@zash.se> Sat, 27 May 2023 15:40:49 +0200 http://hg.omfa.de/prosody-hg/log/749376d75b40/core/certmanager.lua
Further isolates LuaSec from Prosody core, with the ultimate goal of
allowing LuaSec to be replaced more easily.]]> Kim Alvefur <zash@zash.se> Sat, 27 May 2023 15:39:26 +0200 http://hg.omfa.de/prosody-hg/log/ead41e25ebc0/core/certmanager.lua Kim Alvefur <zash@zash.se> Fri, 17 Mar 2023 16:23:07 +0100 http://hg.omfa.de/prosody-hg/log/e6cfd0a6f0da/core/certmanager.lua Kim Alvefur <zash@zash.se> Mon, 16 May 2022 11:42:31 +0200 http://hg.omfa.de/prosody-hg/log/e242a6e74424/core/certmanager.lua
Answers my recurring question of
> Using cert "certs/example.com.crt" from index
... for what?]]> Kim Alvefur <zash@zash.se> Mon, 16 May 2022 11:39:17 +0200 http://hg.omfa.de/prosody-hg/log/2ee27587fec7/core/certmanager.lua
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.]]> Jonas Schäfer <jonas@wielicki.name> Sat, 02 Apr 2022 11:15:33 +0200 http://hg.omfa.de/prosody-hg/log/7e9ebdc75ce4/core/certmanager.lua
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.]]> Jonas Schäfer <jonas@wielicki.name> Wed, 27 Apr 2022 17:44:14 +0200 http://hg.omfa.de/prosody-hg/log/0fd58f54d653/core/certmanager.lua Matthew Wild <mwild1@gmail.com> Fri, 04 Mar 2022 16:33:41 +0000 http://hg.omfa.de/prosody-hg/log/49739369dcad/core/certmanager.lua
The default network backend server_epoll already requires LuaSec so
Prosody won't even start without it, so we can get rid of these lines
here too.]]> Kim Alvefur <zash@zash.se> Thu, 10 Feb 2022 17:15:55 +0100 http://hg.omfa.de/prosody-hg/log/f8b8061461e3/core/certmanager.lua
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.]]> Kim Alvefur <zash@zash.se> Mon, 21 Feb 2022 08:54:39 +0100 http://hg.omfa.de/prosody-hg/log/5cd075ed4fd3/core/certmanager.lua
After a survey of ACME clients it seems *.crt and *fullchain* should
work for the majority. The rest get to manually copy their files.]]> Kim Alvefur <zash@zash.se> Mon, 14 Feb 2022 18:29:31 +0100 http://hg.omfa.de/prosody-hg/log/95d25e620dc2/core/certmanager.lua
Confusion!

Thanks Martin]]> Kim Alvefur <zash@zash.se> Tue, 18 Jan 2022 11:52:35 +0100 http://hg.omfa.de/prosody-hg/log/b05e0b422ff7/core/certmanager.lua
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.]]> Kim Alvefur <zash@zash.se> Tue, 18 Jan 2022 08:04:16 +0100 http://hg.omfa.de/prosody-hg/log/653a48b5a25b/core/certmanager.lua
Pending https://github.com/brunoos/luasec/pull/179

Should not be done globally, but rather only for s2sout, but that would
have to be in mod_tls then.]]> Kim Alvefur <zash@zash.se> Thu, 16 Sep 2021 09:52:51 +0200 http://hg.omfa.de/prosody-hg/log/0fcd80a55f15/core/certmanager.lua
Unsure if this was overlooked before or a recent addition.

Reproduced the data from JSON file available. Would be nice to have a
tool that does that.]]> Kim Alvefur <zash@zash.se> Sun, 26 Dec 2021 00:05:16 +0100 http://hg.omfa.de/prosody-hg/log/47c9a76cce7d/core/certmanager.lua Kim Alvefur <zash@zash.se> Wed, 22 Dec 2021 15:13:49 +0100 http://hg.omfa.de/prosody-hg/log/29765ac7f72f/core/certmanager.lua
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.]]> Jonas Schäfer <jonas@wielicki.name> Tue, 21 Dec 2021 21:20:21 +0100 http://hg.omfa.de/prosody-hg/log/b344edad61d3/core/certmanager.lua
TLS good, SSL bad.]]> Kim Alvefur <zash@zash.se> Wed, 22 Dec 2021 14:24:26 +0100 http://hg.omfa.de/prosody-hg/log/9591b838e3b0/core/certmanager.lua
If anyone wants that.]]> Kim Alvefur <zash@zash.se> Wed, 22 Dec 2021 14:12:10 +0100 http://hg.omfa.de/prosody-hg/log/9c794d5f6f8d/core/certmanager.lua Kim Alvefur <zash@zash.se> Wed, 03 Nov 2021 12:23:29 +0100 http://hg.omfa.de/prosody-hg/log/dfb29b5b0a57/core/certmanager.lua
ssl_preset = "modern"]]> Kim Alvefur <zash@zash.se> Sun, 22 Dec 2019 02:25:37 +0100 http://hg.omfa.de/prosody-hg/log/5810166f35d5/core/certmanager.lua
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.]]> Kim Alvefur <zash@zash.se> Sun, 18 Jul 2021 22:46:57 +0200 http://hg.omfa.de/prosody-hg/log/e7a964572f6b/core/certmanager.lua
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.]]> Kim Alvefur <zash@zash.se> Thu, 27 May 2021 09:22:07 +0200 http://hg.omfa.de/prosody-hg/log/3bbb1af92514/core/certmanager.lua Matthew Wild <mwild1@gmail.com> Thu, 13 May 2021 11:17:13 +0100 http://hg.omfa.de/prosody-hg/log/aaf9c6b6d18d/core/certmanager.lua
This requires LuaSec 0.7+ and OpenSSL 1.1.1+]]> Matthew Wild <mwild1@gmail.com> Tue, 11 May 2021 14:14:15 +0100 http://hg.omfa.de/prosody-hg/log/5a484bd050a7/core/certmanager.lua Kim Alvefur <zash@zash.se> Mon, 26 Apr 2021 15:32:05 +0200 http://hg.omfa.de/prosody-hg/log/55ef50d6cf65/core/certmanager.lua
Due to a bug this field was not properly exported before
See https://github.com/brunoos/luasec/issues/149]]> Kim Alvefur <zash@zash.se> Mon, 26 Apr 2021 15:30:13 +0200 http://hg.omfa.de/prosody-hg/log/30feeb4d9d0b/core/certmanager.lua
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.]]> Kim Alvefur <zash@zash.se> Fri, 07 May 2021 16:47:58 +0200 http://hg.omfa.de/prosody-hg/log/a09685a7b330/core/certmanager.lua
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.]]> Kim Alvefur <zash@zash.se> Fri, 07 May 2021 16:35:37 +0200 http://hg.omfa.de/prosody-hg/log/1cef62ca3e03/core/certmanager.lua
Cuts down on a ton of debug logs]]> Kim Alvefur <zash@zash.se> Wed, 05 May 2021 15:56:39 +0200 http://hg.omfa.de/prosody-hg/log/f97592336399/core/certmanager.lua
Right thing to do, rather than hardcoding '/']]> Kim Alvefur <zash@zash.se> Wed, 05 May 2021 15:54:05 +0200 http://hg.omfa.de/prosody-hg/log/c0c859425c22/core/certmanager.lua Kim Alvefur <zash@zash.se> Sat, 10 Apr 2021 14:45:40 +0200 http://hg.omfa.de/prosody-hg/log/2bd91d4a0fcf/core/certmanager.lua
Prevents a false positive match on files with fullchain.pem as suffix]]> Kim Alvefur <zash@zash.se> Sat, 10 Apr 2021 14:45:03 +0200 http://hg.omfa.de/prosody-hg/log/0bc3acf37428/core/certmanager.lua
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.]]> Kim Alvefur <zash@zash.se> Sat, 06 Feb 2021 22:12:38 +0100 http://hg.omfa.de/prosody-hg/log/8cde06b38fdb/core/certmanager.lua Kim Alvefur <zash@zash.se> Sun, 07 Jun 2020 02:12:50 +0200 http://hg.omfa.de/prosody-hg/log/3ddc7c9f35dc/core/certmanager.lua Kim Alvefur <zash@zash.se> Mon, 13 Apr 2020 16:14:39 +0200 http://hg.omfa.de/prosody-hg/log/3a1b1d3084fb/core/certmanager.lua
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]]> Kim Alvefur <zash@zash.se> Sun, 25 Aug 2019 20:22:35 +0200 http://hg.omfa.de/prosody-hg/log/549e408bab14/core/certmanager.lua Kim Alvefur <zash@zash.se> Fri, 10 Apr 2020 19:03:36 +0200 http://hg.omfa.de/prosody-hg/log/fcf7f50ccdd0/core/certmanager.lua
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.]]> Kim Alvefur <zash@zash.se> Fri, 10 Apr 2020 16:11:09 +0200 http://hg.omfa.de/prosody-hg/log/fbeb7a3fc4eb/core/certmanager.lua Kim Alvefur <zash@zash.se> Fri, 29 Nov 2019 23:24:14 +0100 http://hg.omfa.de/prosody-hg/log/a36af4570b39/core/certmanager.lua
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.]]> Kim Alvefur <zash@zash.se> Sat, 07 Sep 2019 00:00:40 +0200 http://hg.omfa.de/prosody-hg/log/eeb711b92da5/core/certmanager.lua Kim Alvefur <zash@zash.se> Sun, 25 Aug 2019 23:25:42 +0200 http://hg.omfa.de/prosody-hg/log/77f900bbbf25/core/certmanager.lua
The changes in the temporary fork were merged into mainline luasec ca
2013 and included in the 0.5 release in 2014.]]> Kim Alvefur <zash@zash.se> Sun, 25 Aug 2019 23:12:55 +0200 http://hg.omfa.de/prosody-hg/log/94e341dee51c/core/certmanager.lua
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]]> Kim Alvefur <zash@zash.se> Sun, 25 Aug 2019 20:22:35 +0200 http://hg.omfa.de/prosody-hg/log/6ea3cafb6ac3/core/certmanager.lua
Since it's mostly only mod_s2s that needs to request client
certificates it makes some sense to have mod_s2s ask for this, instead
of having eg mod_http ask to disable it.]]> Kim Alvefur <zash@zash.se> Sun, 10 Mar 2019 19:58:28 +0100 http://hg.omfa.de/prosody-hg/log/2a0d7fa4c56a/core/certmanager.lua Kim Alvefur <zash@zash.se> Fri, 25 May 2018 03:33:13 +0200