Technical questions - config problems


#1

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:
certbot renewal

It produced this output:
An unexpected error occurred:
There were too many requests of a given type :: Error creating new order :: too many certificates already issued for exact set of domains:
ERROR:certbot.renewal:All renewal attempts failed. The following certs could not be renewed:

My web server is (include version):
Apache 2.4.18

The operating system my web server runs on is (include version):
Ubuntu 16.04 LTS

My hosting provider, if applicable, is:
me

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):
Virtualmin

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot):
0.23.0

The renewal of all domains worked fine for months. Recently I received messages that the renewal process was not successful due to “There were too many requests of a given type :: Error creating new order :: too many certificates already issued for exact set of domains: …”

When this occurred, I had a look into the /etc/letsencrypt folder and tried to understand, what is configured there. The first thing, that made me wonder, is, that in the renewal subfolder for each domain does not exist one config, but plenty of configs (domain.tld-nnnn.conf). Unfortunately all config files carry the same date and time - otherwise I would have had an idea which config files were created subsequently.
Is that the proposed behaviour? If not: is there a way to get rid of all the consequtively created configs? Could too many config files lead to the afore-mentioned error?

I also found two domains in the renewal, which still had config files in there and whose renewal failed, as the domains were no longer hosted on my server. Could the attempt to renew those domains lead to the “too many certificates already issued” error?

Is there a way to find out, when the seven-day-period will be over?

Is there a way to clean up my configuration, so that only one valid config file for each domain resides in the renewal folder? Is there some kind of “–purge” option, which could do the clean-up / reset?

I also had a look at https://crt.sh/?q=eec.de and I am wondering why so many entries are logged, starting on 2019-03-07. I am not aware of any major change in the week before that date. What should I do in order to track down the possible cause for the misbehaviour?

Thank you very much in advance!


#2

Hi @Vince42

that looks bad. Looks like you have a lot of certificates you don’t use.

You use that certificate ( https://check-your-website.server-daten.de/?q=eec.de ):

CN=eec.de
	15.02.2019
	16.05.2019
expires in 57 days	autoconfig.eec.de, 
autodiscover.eec.de, eec.de, www.eec.de, x3.eec.de - 5 entries

Looks like you use a server management system.

So there is no need to have an extra Certbot.

What says

certbot certificates

Perhaps you should delete some not used certificates (certbot delete certificate-name).


#3

certbot certificates lists lots of problems, expired certificates etc, which I do not dare to post in full length here. :wink:

My approach would be to delete everything but the latest working config for each domain - and I guess that this has to be done one by one. It seems that not the latest config file is necessarily the valid / working one, therefore I need to find out per domain, which config file is used.

  • Is there anything that I could to in order to make this cumbersome task easier?
  • Is it safe to move the working config to domain.tld.conf?
  • How can I avoid that this will happen in the future?

#4

Yes, that’s now your job.

Check the domain online to see, which certificate is used. Then check your vHost to find the certificate - path. Then make a list which certificates should be removed.

But if your vHost configuration is buggy (different vHosts with the same ServerNames), that may bi difficult.

There is an autodiscover - subdomain. So it looks you use cPanel / Plesk or something else. It’s always bad to mix such tools with an own Certbot.


closed #5

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.