TLS provisioning succeeds but reports failure, then retries too much

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,,
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:,, see
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,,
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

  • Congratulations! Your certificate and chain have been saved at:
    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:

    Donating to ISRG / Let’s Encrypt:
    Donating to EFF:

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.

Any suggestions would be welcome.

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 and auto* (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.


The certificates for the 3 mentioned domains are NOT the self-signed cert that MiaB initially issues, nor are they issed by Let’s Encrypt. So …

Have you made any modifications to MiaB?

Who is your VPS provider?

I am sure that I will have more questions, but we will start with these for now.

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.


Ugh, so the rate limit in this case is a week before you can provision again. Thanks for the link btw @just4t

So @DominicCronin we need to look at what certs are available to us. Run this from the command line:

ls /home/user-data/ssl/

and paste the output please.

Indeed, the problematic domains have certificates issued by - 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 certificate. I’ve updated the symbolic link to point to the most recent pem for the “” 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 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.

Thanks for helping

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 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. :slight_smile: 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!

And the news is that it works. I had to click on Provision to get the autoconfig stuff back, but it’s all green!

Thanks for helping.

1 Like

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