Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
I ran this command: I restarted caddy, updated the caddy to the latest version, and restarted fastapi. My cert is not updating and expires in 16 days. I can't have this down... can someone give me the command to update the cert? Usually a recycle of caddy works... but not this time.
It produced this output:
My web server is (include version):
The operating system my web server runs on is (include version):
My hosting provider, if applicable, is:
I can login to a root shell on my machine (yes or no, or I don't know):
I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
Port 80 seems to be blocked for api.benjune.com. I don't have any experience with Caddy, but that would block the http-01 challenge. Maybe try opening port 80? (I thought Caddy was also supposed to be able to do the tls-alpn-01 challenge on port 443, but apparently that doesn't work.. Maybe you configured Caddy to only use the http-01 challenge? )
If the initial challenge tried is http-01, and it fails, Caddy will fall back to LE's staging endpoint until it gets a successful issuance (to avoid rate limit concerns), while trying other enabled challenge types. The tls-alpn-01 challenge is also enabled by default. If that works, Caddy will switch back to LE prod and use that challenge to get a cert.
Not enough information here to figure out what happened. Caddy prints very verbose logs, especially in debug level, related to cert issuance, but no such logs appear here.
Weird, I got a perfectly fine reply on HTTPS with "Caddy" in the Server header. Not sure why tls-alpn-01 wouldn't work in that case, but I agree, we don't have the necessary info to debug this further and apparently it works again with the http-01 challenge