Should resolve the failure in
https://github.com/coredns/coredns/pull/2541.
This change is breaking to clustering plugin developers (not Caddy
users), but logical, since only the caddytls package uses CertMagic
directly (the httpserver package also uses it, but only because it also
uses the caddytls plugin); and it is early enough that no clustering
plugins really exist yet.
This will also require a change of devportal
so that it looks for a different registration function, which has moved
to the caddytls package.
* caddytls: Fix empty SNI handling (new -default-sni flag)
vendor: update certmagic, needed to support this
Hopefully fixes#2451, fixes#2438, and fixes#2414
* caddytls: Don't overwrite certmagic Manager (fixes#2407)
Supersedes #2447
* vendor: Update certmagic to fix nil pointer deref and TLS-ALPN cleanup
* Improve -default-sni flag help text
All code relating to a caddytls.Config and setting it up from the
Caddyfile is still intact; only the certificate management-related
code was removed into a separate package.
I don't expect this to build in CI successfully; updating dependencies
and vendor is coming next.
I've also removed the ad-hoc, half-baked storage plugins that we need
to finish making first-class Caddy plugins (they were never documented
anyway). The new certmagic package has a much better storage interface,
and we can finally move toward making a new storage plugin type, but
it shouldn't be configurable in the Caddyfile, I think, since it doesn't
make sense for a Caddy instance to use more than one storage config...
We also have the option of eliminating DNS provider plugins and just
shipping all of lego's DNS providers by using a lego package (the
caddytls/setup.go file has a comment describing how) -- but it doubles
Caddy's binary size by 100% from about 19 MB to around 40 MB...!
* tls: Add support for the tls-alpn-01 challenge
Also updates lego/acme to latest on master.
TODO: This implementation of the tls-alpn challenge is not yet solvable
in a distributed Caddy cluster like the http challenge is.
* build: Allow building with the race detector
* tls: Support distributed solving of the TLS-ALPN-01 challenge
* Update vendor and add a todo in MITM checker
* caddytls: Raise TLS alert if no certificate matches SAN (closes#1303)
I don't love this half-baked solution to the issue raised in #1303 way
more than a year after the original issue was closed (the necro comments
are about an issue separate from the original issue that started it),
but I do like TLS alerts more than wrong certificates.
* Restore test to match
* Restore another previous test
* Adding TLS client cert placeholders
* Use function to get the peer certificate
* Changing SHA1 to SHA256
* Use UTC instead of GMT
* Adding tests
* Adding getters for Protocol and Cipher
- Introduce StrictHostMatching mode for sites that require clientauth
- Error if QUIC is enabled whilst TLS clientauth is configured
(Our QUIC implementation does not yet support TLS clientauth, but
maybe it will in the future - fixes#2095)
- Error if one but not all TLS configs for the same hostname have a
different ClientAuth CA pool
Also add SSL_PROTOCOL and SSL_CIPHER env vars for fastcgi.
* Implement placeholders for ssl_protocol and ssl_cipher
* gofmt
* goimports
* Housekeeping and implement as {tls_protocol} and {tls_cipher}
* tls: Fall back to certificate keyed by empty name (fixes#2035)
This should only happen for sites defined with an empty hostname (like
":8080") and which are using self-signed certificates or some other
funky self-managed certificate. But that certificate should arguably
be used for all incoming SNI names.
* tls: Revert to serving any certificate if no match, regardless of SNI
Also fix self-signed certs to include IP addresses in their name
if they are configured to serve an IP address
* Remove tests which are now irrelevant (behavior reverted)
It would be good to revisit this in the future.
Caddy can now obtain certificates when behind load balancers and/or in
fleet/cluster configurations, without needing any extra configuration.
The only requirement is sharing the same $CADDYPATH/acme folder.
This works with the HTTP challenge, whereas before the DNS challenge
was required. This commit allows one Caddy instance to initiate the
HTTP challenge and another to complete it.
When sharing that folder, certificate management is synchronized and
coordinated, without the Caddy instances needing to know about each
other. No load balancer reconfiguration should be required, either.
Currently, this is only supported when using FileStorage for TLS
storage (which is ~99.999% of users).
- Using xenolf/lego's likely-temporary acmev2 branch
- Cleaned up vendor folder a little bit (probably more to do)
- Temporarily set default CA URL to v2 staging endpoint
- Refactored user management a bit; updated tests (biggest change is
how we get the email address, which now requires being able to make
an ACME client with a User with a private key so that we can get the
current ToS URL)
- Automatic HTTPS now allows specific wildcard pattern hostnames
- Commented out (but kept) the TLS-SNI code, as the challenge type
may return in the future in a similar form
See discussion on #2015; the initial change had removed this check, and
I can't remember why I removed it or if it was accidental. Anyway, it's
back now.
Also introduce caddy.OnProcessExit which is a list of functions that
run before exiting the process cleanly; these do not count as shutdown
callbacks, so they do not return errors and must execute quickly.
Matthew Holt
Josh Soref
Wèi Cōngruì
Marten Seemann
16yuki0702
elcore
Jiri Tyr
Albert ten Napel
Guilherme Bernal
David Somers
Chris Werner Rau