I ran this command: Synology DSM, Control Panel > Security > Cerificate > Add > Lets Encrypt
It produced this output: DSM: Maximal certificate Requests reached for this domain. /var/log/messages: … too many certificates already issued for exact set of domains: dexlab.no-ip.org …
the first time this happened I had requested <5 certificates (pressed a few wrong buttons). I retried once per day after that for 3 days. Still no success.
My web server is (include version): Nginx (v?)
The operating system my web server runs on is (include version): Synology DSM 6.2.2
My hosting provider, if applicable, is: n/a, self
I can login to a root shell on my machine (yes or no, or I don’t know): yes
I’m using a control panel to manage my site (no, or provide the name and version of the control panel): DSM see above
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot): n/a
Hi Juergen, interesting!
However something went wrong and it was not accepted by the clients (not sure any more) - so I deleted the certificate on the UI! I do not have the private key any more.
Sure, I can find the cert with the public key at [https://check-your-website.server-daten.de/], but would I not need also the private key for encryption (or am I mistaken)?
Any ideas how I can create it again (since I suppose the private key would only be stored on the local machine that generated the key pair.)
Private keys can’t be “recreated”.
If you can’t find it, you will need to start over: New cert with new private key.
[you may have to wait until the exceeded limit has passed - which should be the 5/week]
EDIT: if you can’t wait that long, consider changing the FQDN to something else.
How frequently do you expect that you should be able to use somebody else's resources to do the same thing, over and over again? You created (and deleted) five identical certs within a single day--there's simply no good reason for you to have done that. If you were testing things out, you should have used the testing environment--that's what it's for. So wait four days, at which time you'll be able to create a new cert. In between now and then, look at using the staging environment to make sure the rest of your process is working as expected, so you don't run into this again.
The overall rate at which Let’s Encrypt can issue certificates is limited by its HSM equipment
This equipment costs money and has its own signing rate limits (depending on the individual module). Duplicative certificates within a short period of time are considered a waste of this capacity and are limited in order to make sure that Let’s Encrypt will continue to have enough signing capacity to serve everyone who wants to use its services for free. The HSM is used not only for signing the original certificate, but also for automatically signing OCSP status updates for each certificate throughout that certificate’s entire lifetime, whether or not the certificate is used in the wild at all.
(The OCSP signatures dwarf the initial issuance of the certificate in terms of the load they place on the signing infrastructure.)
If it weren’t for the rate limits, it’s clear that some people’s automated processes would literally request hundreds of identical certificates per day. (Many people who tried to do that, often using ephemeral containers, have popped up here to ask about why they were stopped.) While five might seem like a low limit, remember that these certificates use a (tiny) amount of resources that are limited over the short term, that Let’s Encrypt needs a way to force people to use the testing environment rather than the production environment when engaged in extended debugging or testing, and that Let’s Encrypt also needs a way to quickly put a stop to automated software performing duplicative certificate issuance over and over again.
While many people coming to the service for the first time might not be aware that there are any limits at all, the limits are clearly described on the Let’s Encrypt web site, and were thoughtfully designed to strike a balance that lets people use the service appropriately and discourages the most wasteful uses.
In this case, there is a straightforward workaround, regularly mentioned on this forum, which is to add a distinct subdomain to the request. One useful things about this is that it helps distinguish “a person who is aware of the limit and trying to use the service” from “an automated process that is going to keep doing the same thing over and over again as long as it’s not stopped”. And it still even provides a way that anyone stopped by this rate limit can immediately get a free certificate with coverage for the names of their choice, just with a tiny bit more effort.