Getting ready to issue IP address certificates

> So all the addressing bodies (e.g., ISPs and cloud providers) are on board then right? They sometimes cycle through IP's with great velocity. Faster than 6 days at least.

... or put multiple customers on the same IP address at the same time. But presumably they wouldn't be willing to complete the dance necessary to actually get certs for addresses they were using that way.

Just in case, though, it's probably a good idea to audit basically all software everywhere to make sure that it will not use IP-based SANs to validate connections, even if somebody does, say, embed a raw IP address in a URL.

This stuff is just insanity.

There was a prior concern in the history of Let's Encrypt about hosting providers that have multiple customers on the same server. In fact, phenomena related to that led to the deprecation of one challenge method and the modification of another one, because it's important that one customer not be able to pass CA challenges on behalf of another customer just because the two are hosted on the same server.

But there was no conclusion that customers on the same server can't get certificates just because they're on the same server, or that whoever legitimately controls the default server for an IP address can't get them.

This would be a problem if clients would somehow treat https://example.com/ and https://96.7.128.175/ as the same identifier or security context just because example.com resolves to 96.7.128.175, but I'm not aware of clients that ever do so. Are you?

If clients don't confuse these things in some automated security sense, I don't see how IP address certs are worse than (or different from) certs for different customers who are hosted on the same IP address.

Perhaps I didn't make myself clear. I don't think that IP certs will end up getting issued for shared servers, and definitely not in a way where tenants can impersonate one another. Not often enough to worry about, anyway.

The point was that it affects the utility of the idea.

... and don't get me started on those "challenge methods". Shudder. You'll have me ranting about how all of X.509 really just needs to be taken out and shot. See, I'm already doing it. Time for my medication...

So in the case of multiple users behind a NAT, the cert for 96.7.128.175 would identify whichever party has control over the 443 port on that address?

The way in which they are worse is that IP addresses are often unstable and shuffled around since generally the end user of the address is not its owner. It would be similar to getting a cert for myapp.github.io, technically perfectly valid but GitHub can add any moment steal the name from you since they are the owner, not you

also, HTTPS certs are for in transit - so I see no reason why one certificate can't be used for all the Websites on the same server.

It’s bizarre that the CA/Browser forum with their draconian policy pronouncements is ok with this.

Yes (if the TLS-ALPN-01 challenge method was used). The CA/B Forum Baseline Requirements currently permit proof of control using any of four specified ports

> Authorized Ports: One of the following ports: 80 (http), 443 (https), 25 (smtp), 22 (ssh).

Let's Encrypt uses only port 80 and 443.

This is the same for certificates for domain names and for IP addresses.

That's a significant distinction. In partial mitigation of this, Let's Encrypt will issue IP address certificates valid for only 6 days (not 90 days or 365 days or any other period).

> They'll only be available under the shortlived profile (which has a 6-day validity period)