Last certificate months ago, still getting "too many certificates already issued"?

#1

Hi.

The last time I requested a certificate for dedyn.io was on Feb 3, as can be seen from https://www.google.com/transparencyreport/https/ct/#domain=dedyn.io&incl_exp=true&incl_sub=false

I just requested a new one (with an additional domain name), and now get “too many certificates already issued for: dedyn.io”. How can that be?

Thanks,
Peter

#2

You need to tick the “Include subdomains” box:

https://www.google.com/transparencyreport/https/ct/#domain=dedyn.io&incl_exp=true&incl_sub=true

A large number of certificates for subdomains of dedyn.io are issued on a daily basis.

#3

If it is a public dynamic DNS provider, the provider should try to list on the public suffix list (https://www.publicsuffix.org/). Other dynamic DNS providers have done so already.

#4

dedyn.io already is on the Public Suffix List, so subdomains don’t count. For dedyn.io itself, as I said, the last certificate was requested in February.

Any other ideas why I can’t request a new one? In my opinion, this should not happen.

#5

@cpu, is dedyn.io currently in the list of rate limit exemptions as a result of its PSL listing?

#6

@schoen, it is.

I suspect this may be a bug in the rate limiting code in Boulder, and how it interacts with public suffixes. If dedyn.io is on the public suffix list, that means each subdomain gets its own rate limiting bucket. For instance:

FQDN                  | Rate limit bucket
www.foo.dedyn.io      | foo.dedyn.io
foo.dedyn.io          | foo.dedyn.io
www.bar.dedyn.io      | bar.dedyn.io
dedyn.io              | dedyn.io

Unfortunately, the code that implements this makes an assumption that no rate limit bucket is a subdomain of another rate limited bucket. Specifically CountCertificatesByName “counts, for each input domain, the number of certificates issued in the given time range for that domain and its subdomains.” In this case, that gives the wrong answer for dedyn.io, since there are a large number of certificates issued for subdomains of dedyn.io.

I’ll file an issue and get it fixed. In the meantime, a partial workaround would be to issue a certificate with all of those FQDNs except the exact “dedyn.io” one. I realize that’s unsatisfactory, but it looks like https://dedyn.io isn’t currently serving a valid certificate, so it wouldn’t be much worse than the situation today.

Thanks for flagging this issue!

#7

@jsha Thanks for taking care of this! Would you mind posting a link to the issue here so that I can keep track? Thanks!

#8

Hi @peterthomassen

You can find the issue here https://github.com/letsencrypt/boulder/issues/2681.

Cheers,
sahsanu

#9

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

#10

Hi @peterthomassen,

Good news! The rate limiting bug you encountered here has been fixed in production. You shouldn’t encounter this problem for the dedyn.io domain going forward.

Apologies on the long turn around time for this! We had a few unrelated incidents occur that delayed this being activated in production. I appreciate your patience :slight_smile:

Have a great day,

PSL - too many certificates for registered domain