Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Too many certificates already issued for dynamic dns provider sub domain #2186

Closed
sebasbaumh opened this Issue Jan 14, 2016 · 26 comments

Comments

Projects
None yet
@sebasbaumh
Copy link

sebasbaumh commented Jan 14, 2016

I get the following error trying to get a certificate for a subdomain of a dynamic dns provider:

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

The domain name is like abc.sytes.net, the provider is http://www.noip.com/. And I would expect a lot of requests for such providers.

After digging trough some of the existing issues, I found the public suffix list as a possible solution.
Unfortunately it is missing some of the entries of dynamic dns providers that I used.

Would it make sense to provide an additional list only targeted on such sub domains, to allow an easier usage of letsencrypt?
Then we could just not apply the limit to them? At least the sub domain is owned by myself and the certificate is only usable for it, not for the whole domain sytes.net.

This issue is related to #1721, #2091 and #1834.

@raulfg3

This comment has been minimized.

Copy link

raulfg3 commented Jan 22, 2016

Same here for zapto.org, ddns.net.

complete warninng is: There were too many requests of a given type :: Error creating new cert :: Too many certificates already issued for: zapto.org, ddns.net
Please see the logfiles in /var/log/letsencrypt for more details.

Is possible to add it too.

@h0jeZvgoxFepBQ2C

This comment has been minimized.

Copy link

h0jeZvgoxFepBQ2C commented Feb 2, 2016

We have this problem too... We have subdomain for each of our customers, f.e. customer1.mydomain.com, customer2.mydomain.com, customer3.mydomain.com, ...
And each of them has an own server and we need seperate subdomain certificates.

This service is really nice in general already, but not usable for us with this limitation!

@sebasbaumh

This comment has been minimized.

Copy link
Author

sebasbaumh commented Feb 8, 2016

Just to keep you on track: There is a pull request publicsuffix/list#64 on the public suffix list for this issue, which was created by official no-ip staff. But it seems to take some time, so I would appreciate a better/general solution in letsencrypt for dynamic address providers.

@kaefert

This comment has been minimized.

Copy link

kaefert commented Feb 10, 2016

That pull request has been created over 2 months ago, and from the comments of the publicsuffix staff it doesn't sound like they're planning to merge it soon.

Their list of pull requests caused by people wanting to be able to use letsencrypt is really long, and with their policy of manually checking every single domain to be added they simply won't be able to cope.

It would be very much appreciated if letsencrypt could find an alternative solution. Maybe even just make a fork of the publicsuffix list with all those pull requests merged without any of this rigorous manual checking - after all, there is no harm for the domain owner whoever he is, if letsencrypt consideres the domain a publicsuffix.

@blackm

This comment has been minimized.

Copy link

blackm commented Feb 10, 2016

@kaefert I share your opinion.

I run into the same problem my with my dDNS domain. The rate limit does make sense but free certificates are also highly interesting for home server using a dDNS.

I do offer resources for testing.

I guess now that the first certificates expire, there will be more people complaining about this.

@SeoFood

This comment has been minimized.

Copy link

SeoFood commented Feb 10, 2016

same problem for me and I ran copple internal tools on a subdomain on different Server. Even with that i reached the limit.

@fda77

This comment has been minimized.

Copy link

fda77 commented Mar 2, 2016

Any news? I have still problems with zapto.org (no-ip)

@sebasbaumh

This comment has been minimized.

Copy link
Author

sebasbaumh commented Mar 2, 2016

No, it seems like the publicsuffix list is still not moving forward and letsencrypt does not address this issue as well. So we are kind of caught in the middle.

@h0jeZvgoxFepBQ2C

This comment has been minimized.

Copy link

h0jeZvgoxFepBQ2C commented Mar 2, 2016

I stopped using letsencrypt and use normal certificates again.. unfortunately...

@leolivier

This comment has been minimized.

Copy link

leolivier commented Mar 4, 2016

Same problem here. My ddns certificate provided by letsencrypt expires in 15 days and I cannot renew it!
It's urgent to do something!

@blackm

This comment has been minimized.

Copy link

blackm commented Mar 4, 2016

I switched Ddns provider to one that is on the publicsuffix list. Set up forwarding from your old ddns domain to the new one - problem solved :-)

@lichtamberg what is a "normal certificate" for you? a paid one? startcom?

@kaefert

This comment has been minimized.

Copy link

kaefert commented Apr 12, 2016

I just tried again with my no-ip.org subdomain, and got the same response as half a year ago:
Too many certificates already issued for: no-ip.org

Are there any free dynamic DNS services that can be used with letsencrypt? Or are there any plans to replace or complement the publicsuffix with something else, since apparently the publicsuffix project has been abandoned by it's maintainers?

@TPXP

This comment has been minimized.

Copy link

TPXP commented Apr 15, 2016

According to the PSL folks, we're just selfish people not understanding the aim of their project, despite other DDNS domains already are already part of the list. After 4 months of waiting, it seems clear to me that the PSL is not as complete as Let's Encrypt needs it, and is not willing to fill the gap. That's why I think Let's Encrypt should fork this list to add the missing providers. It should not be that hard to maintain, and would make everyone happy, even our friends at the PSL who "need some more time" !

@blackm

This comment has been minimized.

Copy link

blackm commented Apr 19, 2016

There is actually some process. The PR is submitted to public suffix has some response. Did you worked on all points mentioned in their Guidline (Verification) ?

@sebasbaumh

This comment has been minimized.

Copy link
Author

sebasbaumh commented Apr 19, 2016

@blackm that is merely a question for @noipcom who created the PR. Unfortunately commenting on the PR is locked due to a lot of people complaining about it (which I understand if as it does not add to resolving the issue). Nevertheless I hope they still move forward with it.

But to be honest the handling of the issue by the letsencrypt and public suffix list projects greatly reduces my trust in both of them. At the moment this issue came up, they could have tried to set up a workflow on how to proceed with such requests and not just push it back and forth between the two projects. And I as well as others (1,2) offered to help @weppos and find a way to work it out, but most of the time there wasn't even an answer to that.
And for me that it, what Github is about: work together to build a good solution and help each other.

@weppos

This comment has been minimized.

Copy link

weppos commented Apr 19, 2016

@sebasbaumh as I said in my comment, and will repeat here, people have to understand that a project has priorities. When you (user) have issues, your priority is to get that specific issue fixed. And that's why that PR was full of comments from users who wanted their stuff fixed.

But none of those users, even the users who pretended to help, ever took any action on other tickets with higher priorities. If you (user) really want to help, you should demonstrate will to help where the project need help, not just to fix issues where you have a direct benefit.

Again, take a look at the timeline of commits from both projects, and you will (hopefully) understand that both projects have been very active. I've tried to explain this over and over, to the point where it was not even helpful anymore to comment as clearly most commenters were interested in having their particular problem fixed, rather really being cooperative.

The role of maintainers is to take decisions in the best interest of the project and all the users, sometimes decisions are in your favor, other times they are not. As an user you have the power of choice: if a decision doesn't make you happy, you have the freedom to move to a different project or product.

@kaefert

This comment has been minimized.

Copy link

kaefert commented Apr 19, 2016

@weppos I am sorry if I am just ignorant and this should be clear anyway, but could you please explain where the publicsuffix.org list has its priorities? And in what way users that are not yet involved in your project could help you?

About the noipcom pull request ( publicsuffix/list#64 ), the DNS TXT records that have been requested have already been added:

$ dig +short TXT _psl.no-ip.org
"https://github.com/publicsuffix/list/pull/64"
@weppos

This comment has been minimized.

Copy link

weppos commented Apr 19, 2016

The two primary priorities are 1) the maintenance of ICANN/IANA TLDs and 2) the general maintenance of the list.

Those two points have higher priorities over any private TLD. These tasks include:

  • keeping the list in sync with all the new GTLDs approved almost weekly by IANA (publicsuffix#185)
  • keeping the list accurate with the various registry changes (e.g. publicsuffix#187)
  • deal with existing entries (e.g. publicsuffix#206)

All these tasks already take a huge amount of time, especially when it comes to research and investigate authoritative sources. In most cases, we have to contact directly the registries and go back-and-forth with them.

It's a time consuming effort. And to be clear, maintaining the list is none of the maintainers full-time job.

@sebasbaumh

This comment has been minimized.

Copy link
Author

sebasbaumh commented Apr 19, 2016

@weppos first of all thanks for your answer.

I even try to go beyond that: I would like to fix similar issues, which came up and might come up in the future in the public suffix list. And it would be pretty cool, if this reduces the load on your side as well.
After all both projects could benefit from that.

So might it make sense to discuss on how to automate the check of larger submissions?
Maybe even if it works just for a part of the requests, it could improve the situation.
I would think that placing something like a DNS TXT record should be possible for most of the requesters. And that might be used to deal with existing entries as well.
Or is this something you would not want to consider at all (automated checks)?

@weppos

This comment has been minimized.

Copy link

weppos commented Apr 19, 2016

@kaefert

This comment has been minimized.

Copy link

kaefert commented Apr 19, 2016

@sebasbaumh
they already included DNS TXT Records as the primary means to verify domain ownership, see
https://github.com/publicsuffix/list/wiki/Guidelines
But it seems what has not yet been done is to implement an automated check of these DNS TXT Records.

@weppos thanks for the quick reply. I understand that your workload is quite big.
But to be honest, the impact of the noipcom pullrequest seems to me to be much larger and more benificial than for example the removal of one russian website from the PSL. ( publicsuffix/list#206 )
UPDATE: ah okey, so there's a big bunch of domains involved. Still I guess both the number of noipcom domains and it's users will be bigger then this list, so more impact on the security of the web)

Also I am sorry, but from your answer, I am not really able to tell how to help your project offering my time.

@weppos

This comment has been minimized.

Copy link

weppos commented Apr 19, 2016

@weppos thanks for the quick reply. I understand that your workload is quite big.
But to be honest, the impact of the noipcom pullrequest seems to me to be much larger and more > benificial than for example the removal of one russian website from the PSL. ( publicsuffix/list#206 )

I politely disagree. You are underestimating the fact that Let's Encrypt is just one of the consumer of the list, and by far not the biggest. Virtually any major browser today uses the list: Google Chrome, Mozilla Firefox, Opera and IE. Users of these browsers doesn't care at all about NoIP.

@sebasbaumh

This comment has been minimized.

Copy link
Author

sebasbaumh commented Apr 19, 2016

@weppos and @kaefert I think my statement wasn't really clear, sorry.
I thought of a set of scripts/automated tools, that crawl these DNS entries and might also use other means to show whether all entries in a pull request already fulfill the guidelines/requirements.
The goal would be to reduce the load on the staff to verify everything.
I thought of something like a travis/whatever script, that tests the given domains regarding these?

@kaefert

This comment has been minimized.

Copy link

kaefert commented May 25, 2016

Hey there! Just wanted to inform everybody that publicsuffix/list#64 finally got merged today :) I hope letsencrypt will pull the PSL update into their code soon, then we should finally be able to get certificates for no-ip subdomains

@yookoala

This comment has been minimized.

Copy link

yookoala commented May 27, 2016

I have created letsencrypt/net#12 to address the issue.

Still waiting for the letsencrypt guys to pull it.

@bmw

This comment has been minimized.

Copy link
Contributor

bmw commented Jun 2, 2016

This is outside of the scope of the Certbot client as rate limits are controlled by ISRG and the Let's Encrypt CA so I'm closing this issue.

@bmw bmw closed this Jun 2, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.