Request: Please update Public Suffix List - Multiple .cc subdomains (ec.cc, eu.cc, gu.cc, uk.cc, us.cc) not recognized as public suffixes

Help
1

Hello Let's Encrypt Team,

I am experiencing rate limit issues because several .cc second-level domains are not being recognized as public suffixes in Let's Encrypt's current PSL version.

Problem Description

When requesting SSL certificates for subdomains under the following suffixes:

  • ec.cc
  • eu.cc
  • gu.cc
  • uk.cc
  • `us
2

Let's Encrypt does not manage the Public Suffix List. Consult them for this request:

For more on submitting changes to the list, see specifically:

2 Likes
3

The requested entries are in the PSL since December, OP is requestion LE to update their copy to the latest version.

6 Likes
4

Let's Encrypt is indeed a bit behind on the PSL version currently: They're running v0.50.1 from November 2025, although a newer release (v0.50.2) from January is available. boulder/go.mod at 5567ab7f8662a61233058bca434062bff2e764ab Β· letsencrypt/boulder Β· GitHub

4 Likes
5

I’d expect this to be deployed next Thursday

5 Likes
6

Would be nice if that dependency update could somehow be (semi-)automated. If allowed by policy of course. It's easy enough to doublecheck by a human, but maybe a dependabot-like automatically opened PR would streamline regular updates for better user experience. It's quite common to receive these requests here on the Community.

4 Likes
7

Fully agree. Your post reminded me of one last month. Looks like they gave up waiting and proxied their domain at Cloudflare (presumably with an Origin CA cert).

2 Likes
8

boulder repo has Dependabot

But for some reasons, the last PR that dependabot updating github.com/weppos/publicsuffix-go is from 2023, it is mostly manually updated, but I can't find the problems from the dependabot.yml

(I don't know the dependencies complexity of boulder, but I recommend to give Renovatebot a try for dependencies managements)

4 Likes
9

In theory, dependabot would update the PSL for us.

In practice, the AWS repos update so frequently that dependabot is constantly trying to update those dependencies, and never has a chance to update any of our other deps. Dependabot has no options, as far as we can tell, to fix this behavior. It doesn't round-robin deps, it doesn't choose deps randomly, it doesn't have cooldown periods after updating a dep, it doesn't let you specify a maximum frequency for a given dep, etc.

This has been a frustration of ours for several years, but has never quite risen to the level where the cost of fixing outweighs the cost of just dealing with it.

Another solution would be to stop relying on the publicsuffix-go repo, and instead consume the upstream PSL directly (perhaps via //go:embed), with our own homegrown update mechanism. That is also nontrivial, and doesn't solve the dependabot problem for our other deps, so we haven't gone that route either.

5 Likes
10

So…. AWS dependencies cause Dependabot didn't push other dependencies for somehow?

Anyways, Renovatebot fixed almost of the problems you described

Joplin is one of the project that use Renovate to its fullest potential

You could guess what the config means without reading the docs

Renovate has a feature called Dependency Dashboard you could set the schedule for the updates just like Dependabot, but you could get them whenever you want by click the button like this, or completely disable PR creation for specific deps(but will still listed at dashboard, and just click it if you want it now.)

Screenshot_2026-02-08-08-53-47-360_org.mozilla.firefox-edit
Screenshot_2026-02-08-08-53-47-360_org.mozilla.firefox-edit1280Γ—1466 199 KB

11

Don't want to use Renovate SAAS?

You could self-hosted your own like this