This fixes a regression in 2.8 where IP addresses
would be considered qualifying for public certs
by auto-HTTPS. The default issuers do not issue
IP certs at this time, so if no APs are explicitly
configured, we assign them to the internal
issuer. We have to add a couple lines of code because
CertMagic can no longer consider IPs as not
qualifying for public certs, since there are public CAs
that issue IP certs. This edge case is specific to Caddy's
auto-HTTPS.
Without this patch, Caddy will try using Let's Encrypt
or ZeroSSL's ACME endpoint to get IP certs, neither
of which support that.
* Add per host config
* Pass host label when option is enabled
* Test per host enabled
* metrics: scope metrics per loaded config
* doc and linter
Signed-off-by: Mohammed Al Sahaf <msaa1990@gmail.com>
* inject the custom registry into the admin handler
Co-Authored-By: Dave Henderson <dhenderson@gmail.com>
* remove `TODO` comment
* fixes
Signed-off-by: Mohammed Al Sahaf <msaa1990@gmail.com>
* refactor to delay metrics admin handler provision
Signed-off-by: Mohammed Al Sahaf <msaa1990@gmail.com>
---------
Signed-off-by: Mohammed Al Sahaf <msaa1990@gmail.com>
Co-authored-by: Hussam Almarzooq <me@hussam.io>
Co-authored-by: Dave Henderson <dhenderson@gmail.com>
* caddyhttp: Escaping placeholders in CEL
* Simplify some of the test cases
* Implement vars and vars_regexp in CEL
* dupl lint is dumb
* Better consts for the placeholder CEL shortcut
* Bump CEL version, register a few extensions
* Refactor s390x test script for readability
* Add retries for s390x to smooth over flakiness
* Switch to `ph` for the CEL shortcut (match it in templates cause why not)
* caddytls: Support new tls.context module
This allows modules to manipulate the context passed into CertMagic's GetCertificate function, which can be useful for tracing/metrics, or other
custom logic.
This is experimental and may resolve the request of a sponsor, so we'll see how it goes!
* Derpy derp
* caddy adapt for listen_protocols
* adapt listen_socket
* allow multiple listen sockets for port ranges and readd socket fd listen logic
* readd logic to start servers according to listener protocols
* gofmt
* adapt caddytest
* gosec
* fmt and rename listen to listenWithSocket
* fmt and rename listen to listenWithSocket
* more consistent error msg
* non unix listenReusableWithSocketFile
* remove unused func
* doc comment typo
* nonosec
* commit
* doc comments
* more doc comments
* comment was misleading, cardinality did not change
* addressesWithProtocols
* update test
* fd/ and fdgram/
* rm addr
* actually write...
* i guess we doin' "skip": now
* wrong var in placeholder
* wrong var in placeholder II
* update param name in comment
* dont save nil file pointers
* windows
* key -> parsedKey
* osx
* multiple default_bind with protocols
* check for h1 and h2 listener netw
* ci: update the linter action version
Signed-off-by: Mohammed Al Sahaf <msaa1990@gmail.com>
* exclude rule `G115`; disable deprecated linter
Signed-off-by: Mohammed Al Sahaf <msaa1990@gmail.com>
---------
Signed-off-by: Mohammed Al Sahaf <msaa1990@gmail.com>
* prepare syso files for windows embedding
* don't specify main so version info will be embedded correctly
---------
Co-authored-by: Mohammed Al Sahaf <msaa1990@gmail.com>
By default Go 1.23 enables X25519Kyber768, a post-quantum key agreement
method that is enabled by default on Chrome. Go 1.23 does not expose
the CurveID, so we cannot add it by specifying it in CurvePreferences.
The reason is that X25519Kyber768 is a preliminary key agreement that
will be supplanted by X25519MLKEM768. For the moment there is value
in enabling it.
A consequence of this is that by default Caddy will enable support
for P-384 and P-521.
This PR also removes the special code to add support for X25519Kyber768
via the Cloudflare Go branch.
Cf #6540
* reverseproxy: allow user to define source address
Closes#6503
Signed-off-by: Mohammed Al Sahaf <msaa1990@gmail.com>
* reverse_proxy: caddyfile support for local_address
Signed-off-by: Mohammed Al Sahaf <msaa1990@gmail.com>
---------
Signed-off-by: Mohammed Al Sahaf <msaa1990@gmail.com>
* error: run `error` (msg) through replacer
Signed-off-by: Mohammed Al Sahaf <msaa1990@gmail.com>
* fix integration test
Signed-off-by: Mohammed Al Sahaf <msaa1990@gmail.com>
---------
Signed-off-by: Mohammed Al Sahaf <msaa1990@gmail.com>
Most of the errors that can be seen here are write errors due to clients
aborting the request from their side. Often seen ones include:
* writing: ... write: broken pipe
* writing: ... connection timed out
* writing: http2: stream closed
* writing: timeout...
* writing: h3 error...
Most of these errors are beyond of the control of caddy on the client side,
probably nothing can be done on the server side. It still warrants
researching when these errors occur very often, so a change in level from
error to warn is better here to not polute the logs with errors in the
normal case.
