I ran this command:
certbot certonly --standalone --standalone-supported-challenges http-01 --http-01-port 54321 -d gitlab.typoworx.de
It produced this output:
Certbot throws “An unexpected error occurred:
There were too many requests of a given type :: Error creating new cert :: Too many certificates already issued for exact set of domains: gitlab.typoworx.de”
My operating system is (include version): Debian 8
My web server is (include version): HaProxy
I can login to a root shell on my machine: Yes
I’m using a control panel to manage my site (no, or provide the name and version of the control panel): No
Additional Notes:
I’ve installed Certbot by Debian package which has automatically has installed a cron.d for renewal. May this be the cuprit?
Manually running ‘certbot renew’ says the given domain has not reached expire yet - but the Browser says it is. HaProxy cert is linked to ‘/etc/letsencrypt/live/gitlab.typoworx.de/combined.pem’ correctly. A restart of HaProxy doesn’t change the situation.
OK. It looks like certificates are being issued for this name about once per day, probably when that cronjob fires (you can see this for yourself in a Log Monitor such as https://crt.sh/). The certbot renew feature should check the certificate age and skip renewals for certificates less than 60 days old. It seems to do this when you run it manually, but perhaps something goes wrong when it happens from cron? Can you find any logs relating to the daily renewal cronjob to see what happens?
You mentioned a combined.pem file, but last I looked Certbot didn’t make a file with this name, there’s cert.pem, chain.pem, fullchain.pem and privkey.pem. Could be a typo in your query here, or could be a mistake elsewhere. If a file with that name does exist, was it made by Certbot? If not, maybe it’s not being updated but other files are? I think some or all of the files are symlinks, but the files they link to should have timestamps. If those aren’t recent, it suggests the cron-triggered Certbot is somehow unable to save updated certificates, but that wouldn’t explain why a manual Certbot says things are fine.
Thanks for your help. I checked the combined.pem and you seem to be correct. Its not delivered by certbot, but HaProxy seems to need it combined. I must have manually created it and forgotten about it.
Regarding the daily-renewal problem: It really looks like the cron delivered by the DEB-Package is not working correctly. I run another machine on Ubuntu with a manual install of Certbot (not from DEB) that does not have these Problems.
I will try to investigate in the Cron problem and make it on my own hoping that will fix it. I’ll may report back later on for the Cron issue to inform you about that in case there are other users running into that problem with the Debian-Package.
The following certs are not due for renewal yet:
/etc/letsencrypt/live/gitlab.typoworx.de/fullchain.pem (skipped) No renewals were attempted. No renewals attempted, so not running post-hook
I think this is fine now and should not unneccesarily generate requests anymore.
OK good, by the way you probably don’t need cert.pem in that list you’re handing to “cat”, because the certificate from cert.pem is already at the start of the next file, fullchain.pem, but if it’s not hurting anything, why change it.
If you want to check you fixed the unwanted renewals problem, you could wait a few days and check https://crt.sh/?q=gitlab.typoworx.de to see if there are new certificates still being issued for that name.
Thanks for the hint about combined.pem. I will check later if skipping cert.pem works fine for HaProxy. With the refreshed combined.pem the given domain also runs like a charm now.
I’ve completly rewritten the cron.d/certbot delivered originally by the deb-package. Sine yesterday it seems to run fine without bugging the cert-server with daily renewals. I hope the automated renewal for combined.pem also works.
That is really crappy. What could went wrong here? I am running the cron every day, but isn’t it certbots task to check which of the already created cert needs a renewal using it as described above?
Yes, I think there is a flag named --force-renewal which overrides the default behaviour, but unless that’s used Certbot’s renew mode is supposed to check whether a certificate needs renewing (is 60+ days old) and if not, ignore it.
To understand what’s going wrong I recommend ensuring you will receive the output of the scheduled job (e.g. by email or in a text file) and perhaps also increasing the verbosity (-v on the command line) to give more details of what it’s doing and why. This might give you (or someone reviewing here on the community site) an insight.
A further things to consider, especially if the reviewed output shows nothing is being renewed, and yet a CT monitor like crt.sh shows certificates have been issued anyway, is whether there might be some other “rogue” cron job running as well as the intended one, e.g. in someone’s personal account or in a backup file mistakenly placed in the cron directory. Of course there must be some reason this job doesn’t succeed correctly and stop issuing more and more certificates, but if it’s a rogue job rather than the one you expect, it might have some permission problem or even a left over use of the “force-renewal” flag from some earlier experiment.
As @tialaramex said, seems you have another cron job out there renewing your cert every day. As you installed certbot using the debian package it is worth to check this post I wrote a few minutes ago because maybe you have an active systemd timer that is trying to renew your cert… but well, it should not renew it if it is not due to renewal yet…
Thank you Sahsanu,
that was the culprit at all! I didn’t know about the systemd-timer at all! I think this is a real problem with the debian-package …
I’ve recently tried to disable the systemd-timer for certbot like this and will keep an eye on it if this resolves the problem at all. I decided not to manually delete the systemd-files as this could cause a re-activation by an upgrade for the certbot-package.
$> systemctl list-timers --all
$> systemctl disable certbot.service
$> systemctl stop certbot.service
(last one already confirms that this service has been disabled yet!)
You should stop/disable the timer not the service. No matter that you have certbot.service stopped and disabled, certbot.timer is still able to execute it so you should stop, disable and even mask the certbot.timer.
Hello,
sorry for keeping you waiting. I was in vacation for the last days. I currently have no idea what else I could do. May be I am going better by replacing the debian-package based certbot with the one offered for manual installation.
I already did every of the mentioned steps to avoid automatic renewal when it's not ready for renewal yet. My cron-skript always gives me a positive looking feedback on that:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Cert not yet due for renewal
No renewals attempted, so not running post-hook
This is pretty strange because a renew command shouldn’t renew your certs if they are not close to expire, anyway, it doesn’t happen only with gitlab.typoworx.de but also with your other domains (pop3, imap, kunden, etc.) in a random way from 6:30 am to 7:05 am CET so something is launching a command to issue these certs waiting a random wait of minutes.
Please, show the output of the following commands:
If the above commands show files, please issue a cat to those files to view the content.
Show also the content of /etc/letsencrypt/renewal/gitlab.typoworx.de.conf and the output of:
ls -lart /etc/letsencrypt/live/gitlab.typoworx.de/
ls -lart /etc/letsencrypt/archive/gitlab.typoworx.de/
I forgot to say that usually, you don’t issue certs on monday, maybe because your server is down… who knows, I say it because it could be some kind of clue ;). Also, are you sure you only used certbot to issue certs?, I mean, is it possible you tested some other client like acme.sh, getssl, dehydrated, etc.?.
grep -Eril "(certbot|letsencrypt)" /var/spool/
(no result)
No other issuing client should be running. Machine #1 has been recently setup (Debian 8) and is using only Certbot (debian package "Certbot 0.9.3-1~bpo8+1").
