Since upgrading/migrating MIAB/Ubuntu, I now regularly get messages telling me that provisioning has failed. This relates to domains for which I previously used a different CA, but now wish to use letsencrypt:
Provisioning TLS certificates for box.cronin.tech, pragineer.com, box.pragineer.com.
error: box.cronin.tech, pragineer.com, box.pragineer.com:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
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: box.cronin.tech,box.pragineer.com,pragineer.com: see https://letsencrypt.org/docs/rate-limits/
Please see the logfiles in /var/log/letsencrypt for more details.
The thing is, that sometimes instead of this, I sometimes get this (presumably when letsencrypt thinks I’ve waited long enough.
Provisioning TLS certificates for box.cronin.tech, pragineer.com, box.pragineer.com.
installed: box.cronin.tech, pragineer.com, box.pragineer.com:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Server issued certificate; certificate written to /tmp/tmp6pe4b9sw/cert
Cert chain written to 10
Cert chain written to 11
IMPORTANT NOTES:
Congratulations! Your certificate and chain have been saved at:
/tmp/tmp6pe4b9sw/cert_and_chain.pem
Your cert will expire on 2020-02-01. To obtain a new or tweaked
version of this certificate in the future, simply run certbot
again. To non-interactively renew all of your certificates, run
“certbot renew”
If you like Certbot, please consider supporting our work by:
My conclusion is that the successful provisioning is somehow not having effect, and therefore further repeats are causing letsencrypt to get snarky about it.
I’ve tried emptying the ssl folder and running mailinabox again, but that doesn’t seem to help.
The temp directory referenced in the successful provisioning doesn’t exist (any more) but I don’t know whether I should expect this.
I’ve noticed that I often get email saying “Error Provisioning TLS Certificate”, yet looking at the transactions included in the email, the certificate provisioned correctly, and the certificate page on MIAB shows everything is fine as well, however, the certificated for box.domain.com and auto*.box.domain.com (autoconfig, autodiscover, etc.) are not in sync, and one of the certs is not due to expire, and so doesn’t renew, and therefore triggers the provisioning error, because the non-expiring certificate didn’t renew, even though everything else was successful. This is a minor inconvenience, but meh, I get the certs and they stay valid so I don’t worry about it.
Your situation sounds different though…How often are you seeing that the certificate is failing to provision? If you look at the TLS certificates page on the server do you have any certs that are in danger of expiring within 14 days? That’s the normal period of autorenewal, and if you have a cert renewal consistently failing, you should get that resolved before expiration or you may run into more sever issues.
The three certificates that have problems show only “Certificate has a problem: There is a problem with the certificate.” The rest are due to expire in 66 days.
Let’s Encrypt rate limits certificate issuance … I do not know the specific limits offhand, but you are now going to have to wait 24 hours before you try again. But, I suspect that you do not need to try again … the cert is there. Just not deploying properly is my suspicion.
Indeed, the problematic domains have certificates issued by CAcert.org - I usually trust their CA on my own computers, but letsencrypt is in my chain of trust by default which seems tidier. I haven’t modified MIAB, but I had uploaded the certs through the user interface. This was before my recent upgrade, so the relevant certificates were presumably restored with the rest of the backup.
The message which says it’s succeeded comes in about once a week, which is consistent with their rate limits.
Listing the ssl folder doesn’t help much, apart from revealing that there’s a symbolic link from ssl_certificate.pem to another pem file in the folder. using
openssl x509 -noout -text -in ssl_certificate.pem
I was able to verify that this was indeed the cacert.org certificate. I’ve updated the symbolic link to point to the most recent pem for the “box.cronin.tech” domain and now running the same openssl command shows that it’s a letsencrypt certificate which also has a “Subject alternative name” record for the pragineer domains.
The MIAB user interface now shows the box.cronin.tech as having a good certificate, but the other two as having a problem, although my browser now tells me that I have a good letsencrypt certificate.
For now I’m willing to wait until the rate limit times out again to see if things improve.
It now looks as though the automatic provisioning has pointed the symbolic link back to the cacert certificate. I’m now working on the theory that it picks the file with the latest expiry date. I’ll report back once the rate limit times out again.
I am curious why you simply didn’t remove the cacert certificate? You’ve identified it as the problem … the box.cronin.tech cert has SAN’s for the pragineer domain. When that cert is renewed/expires I suspect that MiaB will reissue it’s own (for the pragineer domain) cert as long as you can ignore the status page error for a short bit.
Just being cautious. I’ve now learned that even renaming the files doesn’t help. Presumably it reads the actual certificate. I’ve now moved everything away to somewhere else, except the certificate I want to use. Let’s see if that works!
I’ve now learned that even renaming the files doesn’t help. Presumably it reads the actual certificate. I’ve now moved everything away to somewhere else, except the certificate I want to use. Let’s see if that works!