Checking for new version…
Requesting root privileges to run letsencrypt…
/root/.local/share/letsencrypt/bin/letsencrypt --no-self-upgrade --force-renew renew
Processing /etc/letsencrypt/renewal/wirtensohn.at.conf
2016-02-15 15:20:17,467:WARNING:letsencrypt.cli:Attempting to renew cert from /etc/letsencrypt/renewal/wirtensohn.at.conf produced an unexpected error: urn:acme:error:rateLimited :: There were too many requests of a given type :: Error creating new cert :: Too many certificates already issued for: wirtensohn.eu, wirtensohn.at. Skipping.
Processing /etc/letsencrypt/renewal/wirtensohn.eu.conf
2016-02-15 15:20:32,308:WARNING:letsencrypt.cli:Attempting to renew cert from /etc/letsencrypt/renewal/wirtensohn.eu.conf produced an unexpected error: urn:acme:error:rateLimited :: There were too many requests of a given type :: Error creating new cert :: Too many certificates already issued for: wirtensohn.eu, wirtensohn.at. Skipping.
Processing /etc/letsencrypt/renewal/mail.wirtensohn.at.conf
2016-02-15 15:20:42,480:WARNING:letsencrypt.cli:Attempting to renew cert from /etc/letsencrypt/renewal/mail.wirtensohn.at.conf produced an unexpected error: urn:acme:error:rateLimited :: There were too many requests of a given type :: Error creating new cert :: Too many certificates already issued for: wirtensohn.at, wirtensohn.eu. Skipping.
There are currently two rate limits in play: Registrations/IP address, and Certificates/Domain. Here you can find the most up-to-date informations about the rate limits:
We are exploring a way to exempt renewals from the rate limit because it's not really correct behavior to prevent someone with an expiring certificate from renewing that certificate due to rate limits. This is discussed at
If your domain is shared with a large population of other users (like a free DNS provider or an ISP), it is possible to get an exemption from the rate limit by having the domain owner get itself added to the Public Suffix List, although this isn't going to be the preferred long-term solution for this situation.
Sorry for the inconvenience and I hope your renewal is successful before your certificate expires.
As Seth said, apologies for the inconvenience. Looking at the logs, it appears you first issued a certificate for this domain on 2016-02-15 10:14:00, and the certificate will be valid for 90 days. The rate limit expires in 7, so you'll have plenty of time to issue a fresh certificate before the old one expires. If you would like to test the renewal process, you can use the --dry-run flag on the Python client.
It’s not closed, you linked a post from Jan 5. I posted several other responses after that, in various tickets. Just like the folks at Let’s Encrypt, we have a lot of things to care about and we are currently working on other priorities to make sure the verification and approval process will be easier (especially for private domains).
What we recommend is that if the only purpose of the submission is to bypass Let’s Encrypt rate-limits, then you should not request to be listed but instead wait the natural flow of the Let’s Encrypt beta phase. We’ll still approve each ticket manually after the preliminary verification, and we reserve the right to reject a request if it doesn’t fit with the goal of the PSL.
@weppos, I find your response very confusing. Your "recommendation" to "not request to be listed but instead wait" combined with the "reservation of the right to reject a request" seems to just be euphemism over the list being closed.
I realize that (as you also said in the post I linked) you are working on changing procedures etc., but that is talking about changes to be made in the future, not the status quo.
I posted several other responses after that, in various tickets
None that actually announce a change in the status quo, though, right? Correct me if I'm wrong. What I see is that your latest post in the thread I linked (from 6 days ago) has you saying "if the goal is to be able to use Let's Encrypt, my advice is to be patient and wait for the service to get out of beta and/or be able to accept more domains" and recommending to "buy a certificate today for 1 year at a price lower than 1 coffee per month."
It seems that this is somewhat underdocumented in terms of what will run up against the limits.
Is there a way to check for specific domains and ip addresses what the limits and expiry times are?
I’m trying to roll this out for a batch of development and staging vhosts and; it appears I should have just used Subject Alternate Names in the CSR. But didn’t realize that was necessary. Because I didn’t think I was hitting the rate limits.
Sooo. Am I locked out for 60 days or 3?
I’m using acme-tiny from a shell script that was going to become the auto-renew cronjob.
I think the rate-limit I’m hitting is registrations per-ip and I think that it was due to a bug in the script. But it’s hard to tell.
If I do build a set of certs with all the ${customer}.${company}-dev.com names stuffed in the Subject field and documented that where would be a good place to share that documentation?
You can check what certificates have been issued by searching for the domain name at https://crt.sh/?
This will tell you if you are hitting the 5 certs / domain / 7 days limit.
Registrations/IP address limits the number of registrations you can make in a given time period; currently 10 per 3 hours. So if you are hitting that limit, just stop for 3 hours and you should be clear.
In terms of documentation, I’d start by posting as a new thread here.