Can you give the domain name for one of these? Are they on this same server?
Can you show the crontab for "73-days"
1 Like
The domain database.sheltermusicboston.org is one. It's on its own digitalocean server. Interesting that this is a subdomain, as are the others that are working properly, while mine is a top level domain.
Then there is likely something different about the Certbot install / autorenew setup on that one
That has no bearing on the cert issuance.
As for that music domain, it's cert issuance history is erratic. See below
1 Like
Can you show that crontab entry? Have you checked your logs to ensure it runs on those days?
Because I saw the --dry-run (staging) cert issued (*1) so that command works when run manually. But, we have not yet explained why it does not result in a newly issued cert.
What seems to be happening on that server is the standard Certbot auto-renew is renewing that cert every 60 days. But, the 73-day thing is not working to get a new cert and only ends up touching your "jks" repository. This looks like it got a fresh cert but did not.
(*1) For other volunteers, I saw this on Censys.
1 Like
The 73 day crontab cycle is simply five specific month and date entries that execute a command script to request a certificate. Not rocket science.
So the certbot program on my server is apparently causing the certificate to be renewed automatically every 60 days? How is that auto renewal option managed/configured?
Covered that here:
As for this:
What about
And after it runs on those days have you checked that the result of certbot certificates shows a newly issued cert? Not your jks date, the actual cert that Certbot got from that run.
I ask whether you know it ran because sometimes the cron runs under a different shell context and things like path and what-not can be different than command line. This can result in poor results.
1 Like
What you're telling me is that the validity dates for a certificate only change in response to certbot activity which must be explicitly invoked. Certbot auto renewal just means scheduling certbot execution on some periodic basis. The dates the certificates changed do not match dates in my crontab. The only other thing I can think of is that there might be something being invoked by digitalocean. I'll check that out.
I looked at the log files left on my server by let'sencrypt. There's activity every day, but it's not being scheduled by me. This certainly explains the dates issue I'm seeing. What's to stop an outside actor from generating certbot activity against somebody else's domain? It seems like it would be fairly trivial to configure a certified command to do that.
Yes. Usually the certbot renew command specifically.
Technically, validity dates of a cert never change. Once a cert is issued that's it. You get a new cert to replace one that is soon to expire. The Certbot renew command does this when the latest it has in its folders is within 30 days of expiration (by default). And, the Certbot renew command is usually setup on your system to auto-run (systemd or cronjob) when Certbot is installed (is part of that process).
You can see the info for the latest cert known by Certbot from the certbot certificates command. Or for one: certbot certificates --cert-name (name)
A cert is only issued by the Let's Encrypt ACME Server upon request by an ACME Client. Certbot is only one of such clients but is very popular.
That is probably the crontab or systemd timer that was likely setup during Certbot installation. I am pretty sure Ubuntu 18 uses a systemd timer. The method to check for one is at the auto renew link for Certbot I previously posted.
As for your 73-day cronjob. That is almost certainly not operating correctly. If it was we would see other certs in the public Certificate Transparency logs. We only ever see ones issued on a 60-day schedule so this is likely the auto-renew from Certbot.
2 Likes
Yes, anyone could run Certbot (or another ACME Client) to request a cert for your domain. But the request will fail since they cannot update your system to satisfy the HTTP or DNS Challenge (or TLS-ALPN). Failing the challenge means that Let's Encrypt will not issue a cert. That makes it a useless exercise.
Perhaps the below topic will be helpful to understand the roles of the ACME Client (like Certbot) and the ACME Server (like the Let's Encrypt CA).
3 Likes
Mike -
I appreciate your expertise and your patience. I think you've identified the underlying source of my problem - systemd. You've also pointed me to some other things to look into. Thanks for your help.
- John Kearney
2 Likes
You are welcome. I think your best path forward is to rely on the already working Certbot renew scheduled command.
Get rid of the 73-day schedule for anything cert related
Add a --deploy-hook to your Certbot renew (we can help) to copy any new cert to your jks store. Or, just run a process daily to copy the latest cert from Certbot folder to your jks store. Yes, usually that would just copy the same cert into jks but that should be harmless.
The above is pretty much the standard practice for your kind of case.
4 Likes
It seems to be a combination of 73/74 day renewals plus some random renewals [highlighted in yellow]:
2 Likes
I think the "random" were actually done by a standard Certbot auto-renew on 60 day schedule. I think they are mixing two different mechanisms.
2 Likes
Yes; I do see that 60 day renewal pattern in there now.
Although the 60 day renewal doesn't seem to be triggered at all the expected times.
2 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.