1. Caddy version (caddy version):
v2.2.1 h1:Q62GWHMtztnvyRU+KPOpw6fNfeCD3SkwH7SfT1Tgt2c=
2. How I run Caddy:
a. System environment:
Ubuntu 18.04.5 LTS
b. Command:
caddy run --environ --config /etc/caddy/Caddyfile
c. Service/unit/compose file:
# caddy.service
#
# For using Caddy with a config file.
#
# Make sure the ExecStart and ExecReload commands are correct
# for your installation.
#
# See https://caddyserver.com/docs/install for instructions.
#
# WARNING: This service does not use the --resume flag, so if you
# use the API to make changes, they will be overwritten by the
# Caddyfile next time the service is restarted. If you intend to
# use Caddy's API to configure it, add the --resume flag to the
# `caddy run` command or use the caddy-api.service file instead.
[Unit]
Description=Caddy
Documentation=https://caddyserver.com/docs/
After=network.target network-online.target
Requires=network-online.target
[Service]
User=caddy
Group=caddy
ExecStart=/usr/local/bin/caddy run --environ --config /etc/caddy/Caddyfile
ExecReload=/usr/local/bin/caddy reload --config /etc/caddy/Caddyfile
TimeoutStopSec=5s
LimitNOFILE=1048576
LimitNPROC=512
PrivateTmp=true
ProtectSystem=full
AmbientCapabilities=CAP_NET_BIND_SERVICE
[Install]
WantedBy=multi-user.target
d. My complete Caddyfile or JSON config:
{
on_demand_tls {
ask https://www.example.com/verify
}
admin "0.0.0.0:2019"
storage redis {
host "10.0.1.1"
port 6379
db 2
key_prefix "caddytls"
value_prefix "caddy-storage-redis"
timeout 5
tls_enabled "false"
tls_insecure "true"
}
}
*.example.com, www.example.com, example.com {
tls /etc/ssl/private/example.cert.pem /etc/ssl/private/example.key.pem
log {
output file /var/log/caddy/access.log
}
reverse_proxy 10.0.0.1:80 10.0.0.2:80 10.0.0.3:80 {
lb_policy least_conn
health_path /status
health_interval 10s
health_timeout 10s
}
}
:80 {
log {
output file /var/log/caddy/access.log
}
reverse_proxy 10.0.0.1:80 10.0.0.2:80 10.0.0.3:80 {
lb_policy least_conn
health_path /status
health_interval 10s
health_timeout 10s
}
}
:443 {
tls support@example.com {
on_demand
}
log {
output file /var/log/caddy/access.log
}
reverse_proxy 10.0.0.1:80 10.0.0.2:80 10.0.7.3:80 {
lb_policy least_conn
health_path /status
health_interval 10s
health_timeout 10s
}
}
3. The problem I’m having:
My main site certificate works as expected. However, on demand TLS certificates are never requested and no log messages printed. The configuration works in our staging environment with the exact same configuration except that instead of *.example.com, www.example.com, example.com we have *.example.com, staging.example.com.
This appears to be a repeat of this issue and this issue, but I don’t see the TLS handshake error messages in the logs.
4. Error messages and/or full log output:
When I make a request to a custom domain pointing to our IP I receive this error:
curl https://www.somecustomdomain.com
curl: (35) error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error
Requests made using HTTP work however.
5. What I already tried:
I have tried simplifying my configuration as much as possible. In the config posted above I removed handle_errors blocks that I used to serve custom error pages and a couple other matchers to block bots. On demand TLS fails with or without these blocks in the config. I also tried combining the :80 and :443 blocks.
Based on the error from curl I can tell that Caddy isn’t serving my example.com certificate. Instead it recognizes that the custom domain doesn’t match this certificate and fails during the handshake.
6. Links to relevant resources:
These Github issues appear to be related to the same issue, but I am still having this problem with v2.2.1.
