Why is Caddy trying to use TLS for a deleted domain name?

1. The problem I’m having:

I removed all traces of a domain name, veberen.cloud, from all Caddy configs and from my entire system. However, Caddy is still showing an error related to veberen.cloud

How can I clear out Caddy’s cache or whatever is causing it to “remember” that domain name?

What I’ve tried so far:

I deleted all TLS cert files I found for veberen.cloud from my entire system including in /var/lib/caddy/.local/share/caddy. I am baffled as to where Caddy could still be finding anything related to that domain name. I have restarted Caddy with sudo systemctl restart caddy after making any changes.

If I do curl -vL localhost from the same host that Caddy is running on, I get the following:

curl -vL localhost
*   Trying
* Connected to localhost ( port 80 (#0)
> GET / HTTP/1.1
> Host: localhost
> User-Agent: curl/7.81.0
> Accept: */*
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Content-Length: 25
< Content-Type: text/html; charset=utf-8
< Date: Fri, 24 Nov 2023 20:52:43 GMT
< Etag: W/"19-mXretNwUgc+gxKIigXjW9JKQgh4"
< Server: Caddy
< X-Powered-By: Express
* Connection #0 to host localhost left intact
Hello from my NodeJS app

This is the expected response, since I have an app running on port 3030 and per my Caddyfile it is running a reverse proxy to port 3030.

2. Error messages and/or full log output:

Nov 24 15:24:46 sovserv caddy[1763]: {"level":"debug","ts":1700857486.0065157,"logger":"events","msg":"event","name":"tls_get_certificate","id":"c301006e-baf2-42c5-a27f-ac8fab55aa29","origin":"tls","data":{"client_hello":{"CipherSuites":[4866,4867,4865,49196,49200,159,52393,52392,52394,49195,49199,158,49188,49192,107,49187,49191,103,49162,49172,57,49161,49171,51,173,171,52398,52397,52396,157,169,52395,172,170,156,168,61,60,49208,49206,183,179,149,145,53,175,141,49207,49205,182,178,148,144,47,174,140,255],"ServerName":"veberen.cloud","SupportedCurves":[29,23,30,25,24,256,257,258,259,260],"SupportedPoints":"AAEC","SignatureSchemes":[1027,1283,1539,2055,2056,2057,2058,2059,2052,2053,2054,1025,1281,1537,771,769,770,1026,1282,1538],"SupportedProtos":null,"SupportedVersions":[772,771,770,769],"Conn":{}}}}
Nov 24 15:24:46 sovserv caddy[1763]: {"level":"debug","ts":1700857486.0065773,"logger":"tls.handshake","msg":"no matching certificates and no custom selection logic","identifier":"veberen.cloud"}
Nov 24 15:24:46 sovserv caddy[1763]: {"level":"debug","ts":1700857486.0065985,"logger":"tls.handshake","msg":"no matching certificates and no custom selection logic","identifier":"*.cloud"}
Nov 24 15:24:46 sovserv caddy[1763]: {"level":"debug","ts":1700857486.0066025,"logger":"tls.handshake","msg":"no matching certificates and no custom selection logic","identifier":"*.*"}
Nov 24 15:24:46 sovserv caddy[1763]: {"level":"debug","ts":1700857486.00661,"logger":"tls.handshake","msg":"no certificate matching TLS ClientHello","remote_ip":"","remote_port":"34624","server_name":"veberen.cloud","remote":"","identifier":"veberen.cloud","cipher_suites":[4866,4867,4865,49196,49200,159,52393,52392,52394,49195,49199,158,49188,49192,107,49187,49191,103,49162,49172,57,49161,49171,51,173,171,52398,52397,52396,157,169,52395,172,170,156,168,61,60,49208,49206,183,179,149,145,53,175,141,49207,49205,182,178,148,144,47,174,140,255],"cert_cache_fill":0.0001,"load_or_obtain_if_necessary":true,"on_demand":false}
Nov 24 15:24:46 sovserv caddy[1763]: {"level":"debug","ts":1700857486.0066435,"logger":"http.stdlib","msg":"http: TLS handshake error from no certificate available for 'veberen.cloud'"}

3. Caddy version:


4. How I installed and ran Caddy:

a. System environment:

Ubuntu 22.04 x86_64
Installed with distro package (sudo apt install caddy)
Running as systemd service.

b. Command:

sudo systemctl start caddy

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.

After=network.target network-online.target

ExecStart=/usr/bin/caddy run --environ --config /etc/caddy/Caddyfile
ExecReload=/usr/bin/caddy reload --config /etc/caddy/Caddyfile --force


d. My complete Caddy config:



:80, :443 {
        reverse_proxy localhost:3030

5. Links to relevant resources:

This means someone (or some software) is making requests to your server with that domain in SNI. If you have your server exposed publicly on port 443, then it could be anyone. including bots just poking around against domains listed in Certificate Transparency logs.

TLS handshake errors are harmless, they only show up when you enable debug.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.