Too many certificates already issued - rate limit?


#23

oh you’re the provider not end user of the service

unfortunately that probably means you have to wait until LE folks loosen those rate limits :frowning:


#24

I also hope they’re loosening those rate limits soon, since we’re having several subdomains on our main domain that we don’t wanna expose with one “master certificate” for all subdomains on that host and I guess there will be more people with that concern.


#25

I have the same problem “There were too many requests of a given type :: Error creating new cert :: Too many certificates already issued for: spdns.org” with a German Dynamic DNS provider “spdns.de”, with this you can get subdomains per account with maximum of 5.

The following domains are available:
firewall-gateway.com
firewall-gateway.de
firewall-gateway.net
my-firewall.org
my-gateway.de
my-router.de
myfirewall.org
spdns.de
spdns.eu
spdns.org

can you increase the Iinit for these domains? Or is it just a beta limit?

greeting


#26

Let’s Encrypt basis its rate limit on the “registered domain” portion part of the FQDN, based on the Public Suffix List. For www.example.com, that would be example.com. For www.example.appspot.com, that would be example.appspot.com (because appspot.com is a public suffix).

Most dynamic DNS services should probably be in the Public Suffix List, because that’s what browsers use to prevent sites from setting cookies on each other. Otherwise, example.appspot.com could set and delete cookies from widgets.appspot.com. So, my first recommendation is to ask your dynamic DNS provider to add themselves to the Public Suffix List, which will have add-on security benefits.


Allow dynamic DNS services to register more certificates
#27

Thanks for your answer, i have contacted the support from spdns.de and wait for response.


#28

@jsha, that wont work for freifunk.net, as it could break the website at https://freifunk.net/ when browsers refuse to accept cookies for freifunk.net. It would probably have other side effects as well. Will there be other ways to increase the limit, or is that the only chance?


#29

I don’t think they will stop accepting cookies for https://freifunk.net, they will stop accepting cookies from foo.freifunk.net for freifunk.net or bar.freifunk.net.


#30

Hey VaTo,

I use also an account with spdns.de. Did you hear something positive?


#31

I had issues with my installation, and tried to use the new documentation. Cleared out my /etc/letsencrypt directory because I couldn’t make heads or tails of which cert was correct.

And now I can’t get replacement certs. This is one of the 6 domains I have which I can’t get a cert for anymore.

There were too many requests of a given type :: Error creating new cert :: Too many certificates already issued for: heroesofthestorm.co.za
Please see the logfiles in /var/log/letsencrypt for more details.

Is there anything I can do?


#32

[quote=“DrPain, post:31, topic:4184”]
Is there anything I can do?
[/quote]Wait a week: Public beta rate limits


#33

I ran into issues with my LE client install as well as implementation and now I keep getting the following:

An unexpected error occurred:
There were too many requests of a given type :: Error creating new cert :: Too many certificates already issued for: rosekp.org

I need all old certs revoked/erased, so I can generate new certs now that my renewal script works.

Before you say, “wait a week” please note I already have and still getting these errors…


#34

Revocation/ereasing doesn’t help you at all if you’ve hit the rate limit of 5 certificates per domain per sliding window of 7 days. You’ll just have to wait.

You should have experimented with the --test-cert switch in stead of the live server.


#35

I waited 7 days already…still get the error…


#36

Yes, your first certificate was issued at 16:09 GMT. You’ll just have to wait one hour and aprox. 40 minutes.


#37

thought I’d wait long enough to issue more LE ssl certificates but seems my auto renewal cronjobs ran on Jan 1, 2016 so took up nearly all my free slots so I hit the rate limit again https://community.centminmod.com/posts/23476/

obtaining Letsencrypt SSL certificate via webroot authentication...

/root/.local/share/letsencrypt/bin/letsencrypt -c /etc/letsencrypt/webroot.ini --user-agent centminmod-centos6-webroot --webroot-path /home/nginx/domains/le15.http2ssl.xyz/public -d le15.http2ssl.xyz certonly
An unexpected error occurred:
There were too many requests of a given type :: Error creating new cert :: Too many certificates already issued for: http2ssl.xyz
Please see the logfiles in /var/log/letsencrypt for more details.

@jsha definitely need to raise that rate limit soon as auto renewals with <60day frequency is going to interfere with the ability to get more ssl certificates and the problem will get worse over time as more LE ssl certs get auto renewed !

./expirydate.sh 

/etc/letsencrypt/live/le10.http2ssl.xyz/cert.pem
certificate expires in 86 days on 31 Mar 2016

/etc/letsencrypt/live/le11.http2ssl.xyz/cert.pem
certificate expires in 86 days on 31 Mar 2016

/etc/letsencrypt/live/le12.http2ssl.xyz/cert.pem
certificate expires in 86 days on 31 Mar 2016

/etc/letsencrypt/live/le14.http2ssl.xyz/cert.pem
certificate expires in 89 days on 3 Apr 2016

/etc/letsencrypt/live/le13.http2ssl.xyz/cert.pem
certificate expires in 89 days on 3 Apr 2016

#38

Excellent. I see that duckdns.org is already on there. We’re in business.

Thanks


#39

Why not just put 100 of those subdomains as SANs on a single certificate, then install that same cert on each of the 100 subdomains? That takes up only 1 rate-limit slot per cert. Using this method you can generate certificates covering 500 subdomains every 7 days.

For example, if you currently have less than 100 subdomains secured, when your slot opens up again you can group them all up (regardless of expiry date) and generate just 1 cert covering the existing ones plus any new subdomains you wish to secure. That would use up only 1 slot, and all your subdomains would be covered for another 3 months.


#40

It’s not entirely just my requirements I need to meet but also that of my users as I develop Centmin Mod LEMP stack which integrates Letsncrypt into the Nginx vhost creator routines see http://centminmod.com/letsencrypt-freessl.html. So Centmin Mod users when they create a new nginx vhost site via the routine they input their domain name they want to setup nginx for + get a Letsencrypt SSL certificate issues and appropriate nginx HTTP/2 vhost configuration auto generated. So each nginx vhost auto created by my users will be tied to their own separate Letsencrypt SSL certificate.


#41

I would like to come back to your suggestion. As many of the Freifunk Communities are running into this issue of practically unrenewable LE-Certs, I would like to reconfirm that adding freifunk.net to the Public Suffix List is the perfect and sustainable solution for Freifunk to use LE.

A little more background: freifunk.net as a domain is giving out A-Records and subdomain-delegation to potentially hundrets of communities in Germany. These communities help to decentralize free and open networks by meshing roughly 30.000 wifi hotspots in Germany. This has roughly doubled last year. Currently we have about 300 communities that maintain their servers, “community marketing” and maps. It becoming more and more good practise to use SSL (thanks to you) but every local admin does this his way. So there is some good knowledge sharing and good practise, but no central mandate for www.gotham.freifunk.net or map.smallville.freifunk.net.I have not seen a third level of subdomain delegation, but I think that’s also possible at some point.

Long explanation, but would an entry of freifunk.net in the Public Suffix List be the right approach to get around the current LE limits? Any other implications? Would this be a sustainable long term solution?

Thanks


#42

Maybe this is too late to be useful, but let me relay the conclusion drawn on the “other side” (the German Freifunk Forum): freifunk.net being in the public suffix list does not seem like a good option. There’s a website hosted under freifunk.net, that website could no longer use cookies. It also seems that “freifunk.net” (when entered in the URL bar) could be considered a search term instead of opening the website. So people fear there will be too many bad side-effects when having freifunk.net on the public suffix list.