We would like to request an update to the Public Suffix List (PSL) used by Let's Encrypt to include our domain sol.site.
Background:
• sol.site is the domain for Solana Name Service (SNS), a blockchain-based domain name service on Solana
• We provide subdomains to users (e.g., username.sol.site)
• We submitted a PSL inclusion request which has been approved and merged
PSL Status:
sol.site is already listed in the official Public Suffix List:
• Already recognized by: GitHub Pages ✓, Vercel ✓ etc.
Request:
Please update the publicsuffix-go dependency in Boulder to the latest PSL version so that sol.site is recognized as a public suffix for rate limiting and certificate issuance purposes.
Impact:
This will allow us to properly issue SSL certificates for user subdomains under sol.site without hitting rate limits designed for single-domain issuance.
Based on this previous thread, it seems the PSL data in Boulder is updated via the publicsuffix-go dependency, and updates are typically done manually when someone asks.
sol.site was merged into the official PSL some time ago and the publicsuffix-go package should already include it. However, Boulder's pinned version of publicsuffix-go may not yet reflect this change.
The practical impact for us:
We operate SNS (Solana Name Service) and issue .sol.site subdomains to thousands of independent users. Without the PSL update in Boulder, each user's subdomain certificate request counts against the same sol.site rate limit — meaning our users quickly hit the 50 certificates per registered domain per week limit, blocking new SSL certificate issuance.
What we're requesting:
Could the team please update the publicsuffix-go dependency in Boulder to the latest version? Once updated, sol.site subdomains will each be treated as separate registered domains for rate limiting purposes.
We understand from the previous thread that after the dependency update, it takes about ~1 week for staging and production environments to be updated.
Thank you for your help! @cpu Happy to provide any additional details.
This request reads strongly to me as LLM-generated, which most likely explains why it is tagging folks who were previously very active but are no longer LE employees.
The sol.site name was added to the weppos/publicsuffix-go repo on Jan 30. The last release of that repo, v0.50.2, was tagged on Jan 3. Boulder is using that latest release. We will most likely include sol.site after the publicsuffix-go repo cuts its next release.
Just to clarify — is there a rough timeline for when publicsuffix-go typically cuts a new release? Trying to set expectations for our users on when SSL certs will work smoothly for their .sol.site subdomains. No rush, just helpful to have a ballpark. Thanks again!
Hi @aarongable, following up on this — we've now hit the 50 certificates-per-week rate limit for sol.site, which is blocking SSL issuance for our users' subdomains. We will submit a rate limit adjustment request as well, but wanted to check if there's any way to nudge the publicsuffix-go release along, or if there's an alternative path on the Boulder side. This is currently blocking our production launch. Thanks for any guidance!
We do not own or maintain the publicsuffix-go repository. As you can see from their release history, they tend to cut a release every few months. I would expect that one will be coming soon, but I do not control that process.
You may want to explore using multiple CAs, so that you can spread the load out across them. This may be a good plan for production resilience regardless of rate limits, since any CA at any point might experience some problem that prevents them from issuing certificates for some time. There are many CAs that support ACME, and many of them are also free. You may want to reference Posh-ACME's CA comparison list and the list from the author of Certify the Web.
