My domain is sarasa.net
I have been using Letsencrypt certs for many years without too many problems. Instead of automatically renewing the certificate I had to manually order an new one because of changes to the multiple virtual domains on the server. I am getting erratic responses. Doing a dry run is successful. When I order the cert straight I get various failures - the most recent being "Secondary validation RPC failed" which suggests a problem with staging. Advice would be appreciated.
I took a quick look at our logs for the domain you mentioned, and it looks like we're seeing CAA DNS lookup timeouts doing "CAA rechecking".
It doesn't help you much, but it looks like we have a bug in our error-message handling here, as I can see the external error isn't helpful to you, and you're getting a generic one.
This doesn't seem to be a widespread problem based on our metrics, so it is probably something being slow between our DNS servers and yours. It's a long weekend, so this is unlikely to get attention until at least Tuesday.
While you wait for possible notes after the weekend you might look at your DNS config. Looks like a glue record has a faulty value. Might be causing longer query times and resulting timeout failures
Thanks for the tip. Will do that.
Sure. Looks like someone refreshed that DNSViz data and it no longer shows a glue record problem. But, there is a delegation issue and a timeout to one of your DNS servers so something to check out anyway.
You can click on "« Previous analysis" to show earlier runs.
I have fixed the problems with my dns configuration and the "glue" record to an older ipaddress which I discovered was still with the registrar for the nameserver. However, I still cannot successfully generate a new certificate because you are only allowing me to do a CSR for one a day. So if I generate a request and there is an error - then I fix the error and generate a new request - I get the warning that there are two many requests of a given type and have to retry the next day - which is extremely frustrating. These errors only appear on an actual CSR - not on a dry run. As I have changed the order of domains on the configuration - so that the cert is issued for the primary nameserver, sarasa.net and not sarasa.com - the last error was that it could not find a certain privkey in the sarasa.net archive folder. I have since copied the certs and privkeys etc from the sarasa.com folder to the sarasa.net folder - guessing that this will fix the issue. Please advise and also consider extending the amount of CSR requests one can make in a given period.
Can you show the exact error message shown by your ACME Client for this? Because Let's Encrypt does not have any limit that is that strict. Was that for the LE Staging system or production?
The docs for rate limits are here: Rate Limits - Let's Encrypt
When you posted in the Help section you should have been shown the form below. To better help you find and correct these problems we need to have more info. Please answer as much as you can. Thanks
Some of your latest post sounds like you are using Certbot. If so, modifying the files like you describe can easily cause problems. In any case, more info about your system will help us give you the best advice.
=========================
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. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
My domain is:
I ran this command:
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):
Mike,
Below is the message (including the bit that preceded it. ) Yes, I am using certbot from the commandline on the server terminal.
"What would you like to do?
1: Keep the existing certificate for now
2: Renew & replace the cert (limit ~5 per 7 days)
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2
Renewing an existing certificate
An unexpected error occurred:
There were too many requests of a given type :: too many certificates (5) already issued for this exact set of domains in the last 168h0m0s, retry after 2025-02-22 18:33:03 UTC: see Rate Limits - Let's Encrypt"
As is stated - the allowance is 5 requests per 7 days.
As mentioned - the server is sarasa.net. I am logged on to a root shell. Certbot version is certbot 0.39.0
The command issued is
sudo certbot certonly --webroot -w /home/sarasa/www/ -d sarasa.net -d www.sarasa.net -w /home/sarasacom/www -d sarasa.com -d www.sarasa.com -w
It was necessary to change the order of the domains in the request with sarasa.net preceding sarasa.com so that sarasa.net appears as the CNAME on the cert and not sarasa.com.
I also updated the configuration file to reflect this.
The initial problem I was having with timeouts was possibly due to a glue record failing with an old unused IPAdress that had originally been associated with the nameserver. That was resolved by amending the record at the registrar.
Additionally, I had successfully run a new cert request a few days ago and I am sure that when I checked the cert it had sarasa.net as the CN. The next morning this had reverted to sarasa.com because a cron job runs certbot at night. I then realized that I had not edited the configuration file with the new order of domains.
No, the allowance is 5 certificates actually issued. Not just requested but actually successfully issued. And, it allows one more every 34 hours. The date shown in the error message reflects that. See the Rate Limit page I linked earlier which says:
Up to 5 certificates can be issued per exact same set of hostnames every 7 days. This is a global limit, and all new order requests, regardless of which account submits them, count towards this limit. The ability to request new certificates for the same exact set of hostnames refills at a rate of 1 certificate every 34 hours.
I see you often use the Staging system so that's good. But, I see 7 production certs issued in the last 7 days which includes sarasa.net (and many other names). What is the problem with using one of those?
If you are experimenting you should be using the Staging system, not production.
That is an extremely old version of Certbot. You should be looking to upgrade. Current is 3.2. See https://certbot.eff.org
A recently issued cert I see has nearly 40 domain names in it: crt.sh | 16769570678. I don't see any issued in the past week with just those 4 domain names in it.
You mean CN for Common Name (not CNAME). Why do you care what the Common Name is? It has not been used to validate certs for a very long time.
Can you restate what your current problem is? Because you are getting plenty of certificates - too many even.
Michael, Thanks for your help and patience. There are actually 19 domains in the list - 38 if one includes the www prefix. Yes, I meant CN. The reason for changing the CN to sarasa.net, oracle.sarasa.net being the primary nameserver - is that if I point Sendmail to use the letsencrypt certificates - downloading mail produces an error that the name on the cert does not match the mail server mail.sarasa.net . Should I also include a request for mail.sarasa.net with an additional -d flag eg; -d mail.sarasa.net ? I had presumed the reason I was getting the error was that sarasa.com was listed as the CN on the cert and not sarasa.net
Yes - about to update the program. It has been working fine until I ran into this problem .
Yes, those are counted. A subdomain counts the same as an apex name for the cert. Each is validated independently and each appears in the cert.
Probably more likely that it did not have mail.sarasa.net in the cert. But, if your mail program is as old as your Certbot I cannot even guess 
Note that the CN has been deprecated for some time and Let's Encrypt will offer option to not have any CN per current recommendations (see tlsserver option here). If you have an old package that requires a CN perhaps your best option is to make a cert with only that domain name in it. Like: mail.sarasa.net This may make it easier to control that cert and that field.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.