Issue with certificate renewal

[devchris2303]

I've just noticed that the web certificate has expired to our dev instance. Tried a reboot and now we can't connect at all. Just getting

"This site can’t provide a secure connection"

This hasn't been an issue before. We did, however, upgrade to 3.3.5 recently.
I wanted to go in an see the cert myself but getting permission denied on the cert folder:

xxxxxxxxxxxxxxxxxxxxx:/opt/postal/config$ cd /opt/postal/caddy-data/caddy/certificates/acme-v02.api.letsencrypt.org-directory/
-bash: cd: /opt/postal/caddy-data/caddy/certificates/acme-v02.api.letsencrypt.org-directory/: Permission denied

Switching to root, I can get in and create a new certificate using:

openssl req -x509 -nodes -newkey rsa:2048
-keyout [domain].key
-out [domain].crt
-days 365
-subj "/CN= [domain]"
-addext "subjectAltName=DNS: [domain]"

However i imagine that because it's only accessible through root, caddy can't get to it.

Looking at our live system, the cert expires in 6 days:
Issued On Thursday, 22 January 2026 at 00:27:17
Expires On Wednesday, 22 April 2026 at 01:27:16
So i assume the same issue may be here too.

The system receives mail no problem and sends it to the end point, however the callback to the api is failing due to the cert issue.

Any advice would be greatly welcome, or if you need more logs - let me know

[devchris2303]

Figured it out, as our postal systems are now behind a firewall, I'm guessing Letsencrypt or the renewal process was trying to call the public IP of the system which was timing out.

I made it public briefly, rebooted caddy and it renewed the cert.

[willpower232]

Glad you figured it out, if you're using letsencrypt http validation then letsencrypt has to be able to publicly query the domain name.

You could work around this with dns validation.