We're almost ready to issue certificates for IP address SANs from Let's Encrypt's production environment. They'll only be available under the shortlived profile (which has a 6-day validity period), and that profile will remain allowlist-only for a while.
Please note: We have more work to do before we're ready to launch this feature for the public. We don't yet have a timeline, and aren't ready to accept allowlist requests.
Here's a sample staging certificate, and a site using it:
Lol, also a bug in Discourse I guess? The URL is blue, but it's just a <a>...</a> without the href= part et cetera.. So an anchor, yes, but hyperlink? No..
Anyway, gotta get myself on that shortlived profile somehow
How can I make my browser NOT follow the 302 redirect? Whilst being funny, the whole Starbucks thing, I cannot check the certificate in the browser due to the redirect
Also: is it allowed to have IP addresses as a dnsName in the SAN? That's kinda weird, right? But in this case it's just a valid FQDN.. Interesting And confusing! Valid hex only character domain names should be forbidden
Good point, thanks! I've just replaced the redirect with a static page.
That's the interesting and weird part I hoped people would notice. This certificate has DNS SANs as well as an IP SAN. They are similar, but look closely: one is definitely a DNS name and one is definitely an IPv6 address.
When I was writing test cases, it occurred to me that someone could potentially do this, so I went looking for TLDs that match [0-9a-f]{,4}, found .cafe, and registered abad.cafe in order to cause this confusion.
Is the underlying SAN specifically coded as IP type? I haven't dug around in it. I noticed my guarding code in my overhaul of CertSage recently, which is why this came to mind.
Dang, just saw the dots vs. colons after looking at it for 5 extra minutes Even though I already figured it was a valid FQDN, I didn't notice thát difference.
We will enable it in staging pretty soon. Probably in the next few weeks, once we are confident our implementation is at least close to correct and complete.
There’s a bunch of details around things like rate limits, scale, etc which we need to resolve before going to production, but that’s not as relevant to staging, which sees a lot less traffic.
It's been probably ~15 years since the last time I was messing with (private) IP SAN certs on the regular. But at that time, it seemed like you needed the IP as both an IP and DNS SAN value in the cert for maximum browser compatiblity. Which is to say, some browsers needed one and other browsers needed the other.
Not sure if there's a compat matrix around anywhere, but it's probably worth testing a bunch of desktop and mobile browsers with different combinations to see if there are any buggy implementations.