Linode Default RDNS Lets Encrypt Rate Limiting

Linode has recently changed the default rDNS for newly created servers, with this change the new domain is being rate limited by Lets Encrypt. They have already been added to the public suffix list via the PR below:

Does anyone know how long it will take in order for Lets Encrypt to update their public suffix?

Thanks in advance!

2 Likes

@hmorris3293 Welcome to the Let's Encrypt community! :slightly_smiling_face:

3 Likes

@hmorris3293
I don't work for LE, but I recall reading that they update that list within their systems like once a week.
So, if it's not already in there (when did you check last?), I'd say it should be within a week.

1 Like

@rg305 Pr to the Public Suffix list was merged 25 days ago, I checked today and it's getting rate limited :frowning:

I see that.
All the issued and active certs are only from cPanel or ZeroSSL.
Maybe there is a block in their system for that domain (from long ago) ? ? ?
Can you try ZeroSSL?

1 Like

PSL updates require a code update to Boulder, the Let's Encrypt CA. It was last updated in September and doesn't get automatically updated (as far as I know). I opened a PR for this change, but it will probably (?) take a couple of weeks to get into production after it is merged.

4 Likes

Thanks @_az! You and I raced: Update public suffix list by jsha · Pull Request #5770 · letsencrypt/boulder · GitHub. :slight_smile: I'll close out mine and review yours.

4 Likes

@_az/@jsha Why are there ZERO certs issued by LE for that domain?
See: crt.sh | ip.linodeusercontent.com

1 Like

If you get rid of deduplicate and exclude, some show up. Something to do with the monster number of certificates in the database I'd guess :man_shrugging: .

1 Like

@hmorris3293 I'm curious to know - are many people using certificates for these ip-based hostnames? If so, what for?

I generally discourage people from using ip-based hostnames for anything where security matters, because those IP addresses are usually quite ephemeral. So you could wind up with e.g. browsers sending authentication cookies or other data to 1-2-3-4.ip.example.com, which sometime later becomes owned by someone else. This is related to this class of attacks, which covers a similar problem with regards to DNS: Be careful where you point to: the dangers of stale DNS records | APNIC Blog

2 Likes

My link excludes duplicates and only shows active certs... none of which are from LE :frowning:

1 Like

This search shows a fair number of Let's Encrypt certificates: https://crt.sh/?q=%.linodeusercontent.com

1 Like

Check the active cert list link and judge for yourself if that is many or not:
https://crt.sh/?Identity=ip.linodeusercontent.com&exclude=expired&deduplicate=Y

I can only assume they do so for complete anonymity.

1 Like

I meant to say, maybe it has something to do with how the filtering is done in the database query. This query also seems efficient at filtering down to only R3-issued certificates: https://crt.sh/?Identity=ip.linodeusercontent.com&exclude=expired&deduplicate=Y&iCAID=183267

2 Likes

Therein lies the problem.
The PSL doesn't include that domain:

// Linode : https://linode.com
// Submitted by <security@linode.com>
members.linode.com
*.nodebalancer.linode.com
*.linodeobjects.com
ip.linodeusercontent.com

It specifically includes the "IP." subdomain.

OK so the number of issued certs is definitely throwing off the research.

1 Like

The effect of the wildcard is to make each subdomain a public suffix in itself, i.e. Linode probably use it to avoid having to list every region e.g. us-southeast-1.linodeobjects.com in the PSL.

Since user domains are direct subdomains of ip.linodeusercontent.com, this looks correct to me.

Actually, I may have misread your intent. crt.sh has had so many database improvements, I've lost track of how the wildcard queries work at this point lol.

2 Likes

I see Apples and Mangoes!

2 Likes

Eagle eye'd Rudy :smiley:

3 Likes

Sampling some of those sites, I see mostly default installs of Plesk. To clarify what I meant: are people using these hostnames intentionally and long term? Are they trusting the certificates on these hostnames to send credentials across?

For instance, imagine someone set up their Plesk instance out of the box by talking to one of these IP-based hostnames. A year later they go to log into "their" instance, but their box has been restarted and the IP address reassigned to someone else - so they wind up typing their password into a form that goes to someone's else's instance.

A better solution for hosting providers that want to assign default hostnames, and automatically get certificates for them, would probably be to assign a permanently unique, random identifier that has nothing to do with IP addresses. That way the user can be sure that no one else will come along and claim "their" domain name.

4 Likes

You are preaching to the choir here: I'm an extremely paranoid security guy - I would never get one of those certs. I'm just thinking (out loud) on why one ever would.

I'm the guy that puts a firewall in front of his firewall!
[true story]

2 Likes