1. Caddy version (caddy version):
v2.4.5 h1:P1mRs6V2cMcagSPn+NWpD+OEYUYLIf6ecOa48cFGeUg=
2. How I run Caddy:
Via systemd (having installed Caddy via OS package manager):
sudo systemctl start caddy
a. System environment:
Ubuntu 20.04 LTS
b. Command:
sudo systemctl start caddy
Here’s the service status:
sudo systemctl status caddy
● caddy.service - Caddy
Loaded: loaded (/lib/systemd/system/caddy.service; enabled; vendor preset: enabled)
Active: active (running) since Sat 2021-10-23 11:07:19 UTC; 1 day 21h ago
Docs: https://caddyserver.com/docs/
Process: 62237 ExecReload=/usr/bin/caddy reload --config /etc/caddy/Caddyfile (code=exited, status=0/SUCCESS)
Main PID: 43973 (caddy)
Tasks: 7 (limit: 2279)
Memory: 12.3M
CGroup: /system.slice/caddy.service
└─43973 /usr/bin/caddy run --environ --config /etc/caddy/Caddyfile
c. Service/unit/compose file:
I haven’t modified this file at all:
$ sudo cat /lib/systemd/system/caddy.service
# 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]
Type=notify
User=caddy
Group=caddy
ExecStart=/usr/bin/caddy run --environ --config /etc/caddy/Caddyfile
ExecReload=/usr/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:
$ sudo cat /etc/caddy/Caddyfile
www.colloqu.io {
redir https://colloqu.io{uri}
}
colloqu.io {
root * /var/www/colloqu.io/public
encode gzip
file_server
request_body {
max_size 10MB
}
try_files maintenance.html
@notStatic {
not file
}
reverse_proxy @notStatic unix//var/www/colloqu.io/tmp/sockets/puma.sock {
header_up X-Real-IP {remote_host}
}
log {
output file /var/log/caddy/access.log
}
}
3. The problem I’m having:
I have just moved a webapp from one VPS to another. Everything looked fine in a browser and the browser claims the TLS certificate is valid until 21 Jan 2022.
When I use curl instead of a browser, curl reports that the certificate has expired (see below).
However I noticed in Caddy’s logs that it is unable to complete the certificate process. Furthermore in the logs of the webapp to which Caddy reverse-proxies, I see that is trying to (but naturally unable to) handle a GET to /.well-known-acme-challenge/<long alphanumeric string>.
Presumably this means that Caddy isn’t handling the certificate challenge request but is instead passing the request to my webapp. What am I doing wrong?
4. Error messages and/or full log output:
$ curl -v https://colloqu.io
* Rebuilt URL to: https://colloqu.io/
* Trying 45.79.181.170...
* TCP_NODELAY set
* Connected to colloqu.io (45.79.181.170) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS alert, Server hello (2):
* SSL certificate problem: certificate has expired
* stopped the pause stream!
* Closing connection 0
curl: (60) SSL certificate problem: certificate has expired
More details here: https://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.
HTTPS-proxy has similar options --proxy-cacert and --proxy-insecure.
Line from my webapp’s log file:
No route matches [GET] "/.well-known/acme-challenge/gOK3vlIYdPXsw5w8bh9yP1_7JquAZsAZgV7U8jqtTYs"
Caddy log:
{
"level":"error",
"ts":1635142078.8743775,
"logger":"tls.issuance.acme",
"msg":"looking up info for HTTP challenge",
"host":"colloqu.io",
"error":"no information found to solve challenge for identifier: colloqu.io"
}
5. What I already tried:
Restarting Caddy.
Searching this forum.
Searching GitHub issues.
Searching the LetsEncrypt forum.
6. Links to relevant resources:
N/A
Huh, that’s good to know.