And for most of the information in the log the domains are shown, but there are some lines in the log with an error that do not show which domain the generated error is from, for example:
caddy[485]: {"level":"error","ts":1675172617.3153057,"logger":"tls.obtain","msg":"will retry","error":"[172.31.56.195] Obtain: subject does not qualify for a public certificate: 172.31.56.195","attempt":1,"retrying_in":60,"elapsed":0.000806518,"max_duration":2592000}
I suspect it is a wildcard (I have some issued and working well), but I think that only the wildcard is not renewing, I would like to be sure which it is, so how can I list the domains that are close to the renewal date, creating for example a ranking of the next 10 certificates that must be renewed and how to force their renewal?
Hi,
For a moment I thought it might not be necessary to share my Caddyfile to get some idea of how to list the certificates.
Anyway, follow my Caddyfile now
# The Caddyfile is an easy way to configure your Caddy web server.
#
# Unless the file starts with a global options block, the first
# uncommented line is always the address of your site.
#
# To use your own domain name (with automatic HTTPS), first make
# sure your domain's A/AAAA DNS records are properly pointed to
# this machine's public IP, then replace ":80" below with your
# domain name.
{
on_demand_tls {
interval 5m
burst 20
}
}
https:// {
tls {
on_demand
}
reverse_proxy {
to http://app.example.com
}
}
*.exampleA.com {
tls {
dns route53 {
access_key_id "AKIREPLACEME"
secret_access_key "a1NREPLACEME"
max_retries 20
}
}
reverse_proxy {
to http://app.example.com
}
}
*.exampleB.com {
tls {
dns route53 {
access_key_id "AKIREPLACEME"
secret_access_key "a1NREPLACEME"
max_retries 10
}
}
reverse_proxy {
to http://app.example.com
}
}
*.exampleC.com {
tls {
dns route53 {
access_key_id "AKIREPLACEME"
secret_access_key "a1NREPLACEME"
max_retries 10
}
}
reverse_proxy {
to http://app.example.com
}
}
This implies that some client made an HTTPS request to your server without specifying a hostname, so Caddy “tried” to issue a cert for an IP address, but that does not qualify for a public certificate, because ACME CAs don’t support IP certs.
The problem is that you’re not specifying an ask endpoint. This is necessary to avoid denial of service and resource exhaustion attacks against your server. An attacker could point a wildcard domain under their control to your server, then continually make requests with different subdomains, infinitely, until your server runs out of storage and/or hits rate limits.
I see that this IP address 172.31.56.195 is the server’s own internal IP address (localhost), so I don’t have certainty of expected behavior or how it could have happened. But I can understand your explanation and I will provide an endpoint ask.
Also, please any suggestions on how to list the certificates (and perhaps order them by those closest to renewal)?
I thought of something like:
sudo caddy list-certs
But I see that it is not an existing command in the documentation.
Easily get a list of certificates, preferably sorted by those close to renewal at the top of the list to keep them on your radar.
The pain currently felt is that for some reason the wildcards are issued, but they are not renewed, from what I understand a TXT record is created in Route53, but it is not removed, so at the time of renewal this gives an error because a record already exists TXT. If I manually remove the Route 53 TXT record, delete the folder, and reload the Caddy, the next access will generate the wildcard correctly, but again in the future it won’t be able to renew because of this perceived behavior.
I don’t think this is even a Caddy issue, maybe a Route 53 plugin tweak.
I recently ran the command:
sudo caddy upgrade
And that took me to the latest versions.
But if this is way beyond or out of scope I would like to know if it is possible to run some command to list or find details of a specific wildcard certificate that shows me:
Issue date
Expiration date
If you are trying to renew and if you have an error
I try to run
sudo systemctl status caddy
But I wanted to filter the command to exampleA.com certificate status for example.
In summary, my biggest concern here is wildcard certificates.
That’s a bug in the route53 plugin then. It should be removed after issuance.
AFAIK, that was reported, and possibly fixed, but I’m not sure. Make sure to take a look at the route53 plugin’s github repo to see the status on that. And make sure you’re in fact using the latest version of that plugin.
No, there’s no such command for that. Because in practice, it’s not relevant. Caddy will automatically manage the certificates, so you can be sure that they will get renewed in time. Renewal starts after 2/3 of the life of the certificate, so for a 90-day cert, renewal starts after 60 days. That means there’s a whole 30 days where renewal can be tried, continually, until it works. Caddy does all kinds of other careful steps to ensure rate limits aren’t hit, etc. See Automatic HTTPS — Caddy Documentation
