Every time I try to request a new certificate I get a 500 error. I originally had a bunch of different domains on one cert but started separating them to prevent failed renewals when we lose a customer and transfer ownership. I revoked the main cert, but haven’t been able to get the new separate ones. It appears verification is successful but fails at the end. Logs indicate a 500 error.
It produced this output:
Please enter in your domain name(s) (comma and/or space separated) (Enter 'c’
to cancel): oterodentalcenters.comwww.oterodentalcenters.com
Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for oterodentalcenters.com
tls-sni-01 challenge for www.oterodentalcenters.com
Waiting for verification…
Cleaning up challenges
An unexpected error occurred:
The server experienced an internal error :: Error creating new cert
Please see the logfiles in /var/log/letsencrypt for more details.
My web server is (include version): Ubuntu apache 2.4.7
The operating system my web server runs on is (include version): Ubuntu 14.04
My hosting provider, if applicable, is: Digital Ocean
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): no
@cpu can you look into this Internal Server Error? Please and thank you.
@Wireland did you try it again? It could have been a transient thing. Your domain validations are completing successfully so I don’t think you’re doing anything wrong… EDIT: I see now you said “every time I try” so I guess you did.
You ran into this bug because you have 2,500 valid authorizations for one of your domains, which suggests that you are attempting issuance much too frequently. One common source of this problem with Certbot is the --renew-by-default or --force-renewal flag. I’d recommend you check your cron jobs for root, or your systemd units, to ensure you’re running Certbot no more than twice a day, and you don’t have those flags enabled. Thanks!
That’s a lot of authorizations! I’ll set cron to run less frequently. Is there a way to reset those authorizations or do I need to disable cron and wait before trying again?
To clarify, Certbot normally won’t attempt issuance unless a certificate is close to expiration. I’d be curious to hear more about your configuration so we can improve documentation and so on. Could you share the exact command that runs in your crontab?
It’s possible to deactivate authorizations, and that would improve your situation, but (a) it’s not currently supported by Certbot, and (b) you probably don’t have a list of all authorizations in your logs. My recommendation is to try again a week from Friday; we should have the fix deployed by then.
I’m running certbot-auto renew --quiet --no-self-upgrade in cron. Could the large amount of authorizations be caused by cron trying to renew a cert with multiple domains where one domain fails but the others succeed?
Ah, yes, I suspect that's part of it! We have logic in Boulder that should just reuse an existing valid authorization for the domain that's succeeding, but it may not be triggering for some reason. I'll look into it.
It might be a good idea to put something in the docs about best practices. Like suggest that each TLD have its own cert. In my case I’m acting as a shared host for multiple clients. I mistakenly put everyone on one cert (not understanding that each time you run certbot it issues one cert) but then transfered ownership of one domain, which caused the renewal to fail.
I’m experiencing the same issue right now for client.smartbank.pro and some other subdomains…
{
“type”: “urn:acme:error:serverInternal”,
“detail”: “Error creating new cert”,
“status”: 500
}
We also have some reports on GitHub (yours and one other GitHub user’s posted in Cerbot issue #2597).
However I don’t really recommend using a closed issue in the Certbot repository for this. (1) It’s not really a Certbot issue (so this forum is more appropriate). (2) The reason for this failure is most likely not the same as the reason for the failure in March 2016—over two years ago.
Thanks for reporting it here. @jsha, are you aware of this problem?