Caddy certs and VM certs are they both managed?

1. The problem I’m having:

I have a ProxMox 7.3-4 cluster with a number of Ubuntu 22.04 LTS VM's that were originally set up with LetsEncrypt Certbot certificates. I added a Caddy 2.6.4 router as reverse proxy server to allow many of these VM's to be reliably hosted from a single IP address. This has worked fine for some time with Caddy managing the HTTPS connections, however,

2. Error messages and/or full log output:

I have been receiving expiry warning emails from LetsEncypt as follows

Your certificate (or certificates) for the names listed below will expire in 7 days (on 2023-05-12). Please make sure to renew your certificate before then, or visitors to your web site will encounter errors.

We recommend renewing certificates automatically when they have a third of their total lifetime left. For Let’s Encrypt’s current 90-day certificates, that means renewing 30 days before expiration. See Integration Guide - Let's Encrypt for details.

cloud.comxpertise.ca

This is just an example as there are ongoing complaints by email telling me that my certs are within a week of expiry.

How do I resolve this???

3. Caddy version:

I am using Caddy v2.6.4 h1:2hwYqiRwk1tf3VruhMpLcYTg+11fCdr8S3jhNAdnPy8=

4. How I installed and ran Caddy:

a. System environment:

Caddy is installed on a VM on the same ProxMox cluster as the 20 or so Ubuntu VM’s and it is at the internal IP that my fibre router delivers to and in turn reverse proxies all servers sharing the same local subnet and references in the caddyfile.

b. Command:

c. Service/unit/compose file:

d. My complete Caddy config:

cloud.comxpertise.ca {
redir /.well-known/carddav /remote.php/dav 301
redir /.well-known/caldav /remote.php/dav 301

reverse_proxy 192.168.0.109:80

}

#COMXPERTISE ERP DEMO SITE
erp.comxpertise.ca {
reverse_proxy 192.168.0.136:80
}

#COMXPERTISE WEBSITE SERVER 1
comxpertise.ca {
reverse_proxy 192.168.0.114:80
}

#COMXPERTISE WEBSITE SERVER 2
www.comxpertise.ca {
reverse_proxy 192.168.0.118:80
}

#KASLOVIA.NET Test Site
kaslovia.net {
reverse_proxy 192.168.0.128:80
}

#BOLT BATTERY Test Site
bolt.comxpertise.ca {
reverse_proxy 192.168.0.122:80
}

#help Whitehead test cloud NC-25.0.4
whitehead.kaslovia.ca {
redir /.well-known/carddav /remote.php/dav 301
redir /.well-known/caldav /remote.php/dav 301

reverse_proxy 192.168.0.135:80

}

Cloud.kaslovia.ca

cloud.kaslovia.ca {
redir /.well-known/carddav /remote.php/dav 301
redir /.well-known/caldav /remote.php/dav 301

reverse_proxy 192.168.0.133:80

}

5. Links to relevant resources:

All the sites in the Caddy file are operational now, but these expiry dates that LetsEncrypt is complaining about are rapidly approaching.

What is in Caddy’s logs? It seems that question was missed in the help template. Our guess is only as good as yours without the full logs.

Where do I find these logs?

The terminal (stderr).

Nice try there is no file call stderr anywhere on the Caddy Ubuntu VM

Pardon my ignorance, but should there not be an embedded logging process for Caddy as there is for many other functions. Am I wrong in assuming there is no default storage of logging information?

This is the best I can log

● caddy.service - Caddy
Loaded: loaded (/lib/systemd/system/caddy.service; enabled; vendor preset: enabled)
Active: active (running) since Sat 2023-05-06 19:43:34 UTC; 1min 16s ago
Docs: Welcome — Caddy Documentation
Process: 1036 ExecReload=/usr/bin/caddy reload --config /etc/caddy/Caddyfile --force (code=exited, status=0/SUCCESS)
Main PID: 640 (caddy)
Tasks: 9 (limit: 28712)
Memory: 46.0M
CPU: 620ms
CGroup: /system.slice/caddy.service
└─640 /usr/bin/caddy run --environ --config /etc/caddy/Caddyfile

May 06 19:44:33 rerouter caddy[640]: {“level”:“warn”,“ts”:1683402273.565618,“logger”:“http”,“msg”:“server is listening only on the HTTP port, so no automatic HTTPS will be applied to this server”,“server_name”:“srv1”,“http_port”:80}
May 06 19:44:33 rerouter caddy[640]: {“level”:“info”,“ts”:1683402273.5728216,“logger”:“http”,“msg”:“enabling HTTP/3 listener”,“addr”:“:443”}
May 06 19:44:33 rerouter caddy[640]: {“level”:“info”,“ts”:1683402273.5729828,“logger”:“http.log”,“msg”:“server running”,“name”:“srv0”,“protocols”:[“h1”,“h2”,“h3”]}
May 06 19:44:33 rerouter caddy[640]: {“level”:“info”,“ts”:1683402273.5730906,“logger”:“http.log”,“msg”:“server running”,“name”:“srv1”,“protocols”:[“h1”,“h2”,“h3”]}
May 06 19:44:33 rerouter caddy[640]: {“level”:“info”,“ts”:1683402273.573126,“logger”:“http”,“msg”:“enabling automatic TLS certificate management”,“domains”:[“bolt.comxpertise.ca”,“whitehead.kaslovia.ca”,“kaslovia.net”,“cloud.comxpertise.ca”,“erp.comxpertise.ca”,“www.comxpertise.ca”,“cloud.kaslovia.ca”,“mail.kaslovia.ca”,“comxpertise.ca”]}
May 06 19:44:33 rerouter caddy[640]: {“level”:“info”,“ts”:1683402273.5871584,“logger”:“tls.cache.maintenance”,“msg”:“stopped background certificate maintenance”,“cache”:“0xc00041b570”}
May 06 19:44:33 rerouter caddy[640]: {“level”:“info”,“ts”:1683402273.5876303,“msg”:“autosaved config (load with --resume flag)”,“file”:“/var/lib/caddy/.config/caddy/autosave.json”}
May 06 19:44:33 rerouter caddy[640]: {“level”:“info”,“ts”:1683402273.5878243,“logger”:“admin.api”,“msg”:“load complete”}
May 06 19:44:33 rerouter systemd[1]: Reloaded Caddy.
May 06 19:44:33 rerouter caddy[640]: {“level”:“info”,“ts”:1683402273.5990973,“logger”:“admin”,“msg”:“stopped previous server”,“address”:“localhost:2019”}

stderr is a standard stream: https://linux.die.net/man/3/stderr

It’s the normal place for programs to write their logs to stderr unless configured otherwise. If you’re running Caddy as a system service (I assume not since that part of the help template is also blank) then its journaler is probably capturing the logs.

We’ll need the full logs from the past in order to be able to help you solve the problem…

Check expiry on the certificates that Caddy is serving (use a browser, click the lock icon to the left of the domain in the address bar to inspect it). If it’s further than a month away, then there’s no problem.

You’re likely getting emails because Caddy chose to use ZeroSSL instead of Let’s Encrypt for some of those certificates. Let’s Encrypt doesn’t know that Caddy switched, so they do what they know and that’s to warn about expiry because they weren’t used to renew in time.

This can happen for a variety of reasons, but Caddy uses two different issuers by default for greater robustness. See Automatic HTTPS — Caddy Documentation which explains some of this.

You can ignore those emails if you can confirm that Caddy does indeed serve certs that aren’t close to expiry.

It would appear that there is no correlation between the now expiring certs that were provided by Certbot installed on these VM’s when they were originally built out prior to may deployment of Caddy and the Lets Encrypt certs employed by Caddy since then,

I’m not sure I understand what you’re implying with that last one. I don’t have enough context for when things were set up. But clearly your current cert is less than a month old, so that seems fine.

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