| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Everything supports SNI today, so this is not useful information.
|
|\ |
|
| |
| |
| |
| | |
A typo should not result in ending up with "legacy"
|
|\| |
|
| |
| |
| |
| | |
Ref https://github.com/mozilla/server-side-tls/issues/285
|
| |
| |
| |
| |
| | |
Further isolates LuaSec from Prosody core, with the ultimate goal of
allowing LuaSec to be replaced more easily.
|
| |
| |
| |
| |
| | |
Further isolates LuaSec from Prosody core, with the ultimate goal of
allowing LuaSec to be replaced more easily.
|
| | |
|
|\| |
|
| |
| |
| |
| |
| |
| | |
Answers my recurring question of
> Using cert "certs/example.com.crt" from index
... for what?
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|\ |
|
| |
| |
| |
| |
| |
| | |
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.
|
|/
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
After a survey of ACME clients it seems *.crt and *fullchain* should
work for the majority. The rest get to manually copy their files.
|
|
|
|
|
|
|
|
| |
documentation
Confusion!
Thanks Martin
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
TLS good, SSL bad.
|
|
|
|
| |
If anyone wants that.
|
| |
|
|
|
|
| |
ssl_preset = "modern"
|
|
|
|
|
|
| |
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.
|
|\ |
|
| |
| |
| |
| | |
This requires LuaSec 0.7+ and OpenSSL 1.1.1+
|
| | |
|
| |
| |
| |
| |
| | |
Due to a bug this field was not properly exported before
See https://github.com/brunoos/luasec/issues/149
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
(fixes #1513)
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
|
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| | |
Cuts down on a ton of debug logs
|
| |
| |
| |
| | |
Right thing to do, rather than hardcoding '/'
|
| | |
|
| |
| |
| |
| | |
Prevents a false positive match on files with fullchain.pem as suffix
|
| |
| |
| |
| |
| |
| |
| | |
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 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.
|
| |
| |
| |
| | |
support)
|
| |
| |
| |
| |
| |
| |
| | |
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 changes in the temporary fork were merged into mainline luasec ca
2013 and included in the 0.5 release in 2014.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
|/
|
|
|
|
| |
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.
|
|\ |
|