Virtualmin GPL /
One of my virtual servers attempted to automatically renew its Let’s Encrypt SSL certificate. The error email notifications I received were:
An error occurred requesting a new certificate for example.com, www.example.com from Let’s Encrypt : Expected certificate file /etc/letsencrypt/keys/cert.pem was not found
(I’ve checked and it’s not there)
I received 6 of these emails every 5 minutes followed by a number (until I stopped the auto-renew) of the Let’s Encrypt app emails with:
There were too many requests of a given type :: Error creating new cert :: Too many certificates already issued for exact set of domains:
These latter emails indicate to me that the maximum number of certs had been requested (in a 7 day period). I checked the LE error logs in /var/log/letsencrypt and at the end of these first 6 emails was:
2016-10-07 11:18:10,016:DEBUG:certbot.storage:Archive directory /etc/letsencrypt/archive/example.com-0009 and live directory /etc/letsencrypt/live/example.com-0009 created.
2016-10-07 11:18:10,016:DEBUG:certbot.storage:Writing certificate to /etc/letsencrypt/live/example.com-0009/cert.pem.
2016-10-07 11:18:10,016:DEBUG:certbot.storage:Writing private key to /etc/letsencrypt/live/example.com-0009/privkey.pem.
2016-10-07 11:18:10,016:DEBUG:certbot.storage:Writing chain to /etc/letsencrypt/live/example.com-0009/chain.pem.
2016-10-07 11:18:10,017:DEBUG:certbot.storage:Writing full chain to /etc/letsencrypt/live/example.com-0009/fullchain.pem.
2016-10-07 11:18:11,305:DEBUG:certbot.storage:Writing new config /etc/letsencrypt/renewal/example.com-0009.conf.
2016-10-07 11:18:11,306:DEBUG:certbot.reporter:Reporting to user: Congratulations! Your certificate and chain have been saved at /etc/letsencrypt/live/example.com-0009/fullchain.pem. Your cert will expire on 2017-01-05. To obtain a new or tweaked version of this certificate in the future, simply run letsencrypt-auto again. To non-interactively renew all of your certificates, run “letsencrypt-auto renew”
So it looks to me that 6 LE certs were requested and created but Virtualmin was not able to utilise them due to the ‘…/cert.pem’ error
Can’t see anything in your Issues Tracker, so it might be me. Any ideas what might be happening and what can I do to update my cert.
(I have tried manually requesting a cert for another virtual server and get the same ‘…/cert.pem’ error. Strange as I’ve not had this problem before)
I’ve got the same problem. Requesting a certificate results in " … request failed : Expected certificate file /etc/letsencrypt/keys/cert.pem was not found". Any ideas?
Been hunting this down, looks like it’s a bug with Webmin, the regex used is picking up the output incorrectly for the updated certbot, will be doing some testing tonight and put up a patch for it
You can see the issue being discussed here https://github.com/webmin/webmin/issues/436 - if you’re comfortable with modifying code in webmin, have a look at the diff on pull request with a fix in it https://github.com/webmin/webmin/pull/437
So is this bug related to where the certs are located when you create one for a virtual site via Virtualmin as when I did this for a site it creates .ca, .cert and .key files in /home/user/ it does not create a letsencrypt folder in etc nor does it create any .pem files.
I’m asking this as I need to know if the location and file extensions of the files are different depending on the method of creation and renewal i.e. via Virtualmin or certbot-auto ?
P.S. This is on Centos 6
I had this issue but since it also keeps retrying now I have another issue: “There were too many requests of a given type :: Error creating new cert :: Too many certificates already issued for exact set of domains”
So it seems like for some reason there were multiple new certificates issued rather than renewing existing ones. In this case it seems like they probably have to be revoked before new ones can be created but I’m not sure how to revoke certs with Virtualmin. Virtualmin maybe should revoke any previously created ones when it “renews” a cert since setting it to renew every 3 months seems to possibly cause a 1 day overlap where there’s an expired certificate. Maybe you can set it to 2.93 months or something? I haven’t tested that.
Update: So it seems revoking is not the way to go. You can only request about 5 certs every 7 days so this site is pretty much screwed since I revoked the certs and then realized I was rate limited and couln’t request new ones still. There is a --keep parameter to allow you to reinstall non-expired certs, revoked or not ( https://certbot.eff.org/docs/using.html#command-line ). I was having issues trying to get the cert to install properly like that using the webroot method and ended up using --apache but had to split the config file into separate files for each port rather than having the vhosts all in the same file, each one had to be in a separate file.
Update2: As a workaround for my issue I added another subdomain to the list of domains the cert is issued for and it worked. This is apparently because there is a higher limit for this sort of thing: https://community.letsencrypt.org/t/solved-cant-generate-cert-too-many-requests-old-certs-gone-due-to-server-update/18471/2
I am also getting following error when creating a cert with letsencrypt:
Requesting a certificate for mydomain.com, www.mydomain.com from Let’s Encrypt …
… request failed : Expected certificate file /etc/letsencrypt/keys/cert.pem was not found
I am not able to understand how did @rrhode manage to get this working. Can you please explain? I will be really thankful.
I’m not sure if it’s because I used the actual letsencrypt/certbot client but the certs were in /etc/letsencrypt/archive/example.com/cert1.pem (and cert2.pem in some cases) in numerous folders which were numbered such as /etc/letsencrypt/archive/example.com-0001 /etc/letsencrypt/archive/example.com-0002 and so forth.
First what I did was take the edits form the pull requests to the letsencrypt-lib.pl file:
And this one for good measure:
Then what I did to bypass the limit was add another subdomain to the server which I did through the DNS records:
www1.example.com. IN A 192.168.1.1
As well as the Apache config:
This was explained in one of the links I previously linked, there is a 5 certs per 7 day limit and a 20 certs per 7 day limit for new subdomains or something like that.
Then I went into Virtualmin and edited the virtual server and went to Server Configuration > Manage SSL Certificate > Let’s Encrypt tab and selected the “Domain names listed here” option and entered the domain including www and www1:
I also set “Months between automatic renewal” to 2.
Another thing is if the site is blocked behind protection of http auth you can put a .htaccess file into the /home/domainuser/public_html/.well-known folder and add this content:
Allow from all
I cannot understand the problem, however - the most important - is there any temp. fix for it?
Thx rrhode, however I would like to have the Virtualmin fix. I don’t want do some subdomains etc. because I have a new domain with new IP and I couldn’t create the certificate on the very first go.
That problem what we have is because the Virtualmin has a bug or people are making to many certificates on own servers?
UPDATE: anyway, I found a solution: https://patch-diff.githubusercontent.com/raw/webmin/webmin/pull/437.patch
Exactly, that is a fix provided by Virtualmin which we have already linked to in this thread. If you had read more carefully you may have saved yourself some time. I’m sure it will be in the next release.
However if you were already limited that fix won’t be the solution to your issue unless you wait until your limit resets. I offered a temporary fix/workaround to this by creating a new subdomain and issuing the cert for that along with the regular domain. This allows you to bypass the limit in order to issue the cert. The reason I was limited was due to the certificate automatically renewing which it tried every 5 minutes since it was still expired due to the renew failing due to the error which is fixed in the patch you also linked to.