←back to thread

.INTERNAL is now reserved for private-use applications

(www.icann.org)
563 points joncfoo | 5 comments | 09 Aug 24 16:36 UTC | HN request time: 0.419s | source
Show context
8organicbits ◴[09 Aug 24 22:03 UTC] No.41205729[source]▶
My biggest frustration with .internal is that it requires a private certificate authority. Lots of organizations struggle to fully set up trust for the private CA on all internal systems. When you add BYOD or contractor systems, it's a mess.

Using a publicly valid domain offers a number of benefits, like being able to use a free public CA like Lets Encrypt. Every machine will trust your internal certificates out of the box, so there is minimal toil.

Last year I built getlocalcert [1] as a free way to automate this approach. It allows you to register a subdomain, publish TXT records for ACME DNS certificate validation, and use your own internal DNS server for all private use.

[1] https://www.getlocalcert.net/

replies(12): >>41206030 #>>41206106 #>>41206231 #>>41206513 #>>41206719 #>>41206776 #>>41206828 #>>41207112 #>>41208240 #>>41208353 #>>41208964 #>>41210736 #
layer8 ◴[10 Aug 24 12:19 UTC] No.41208964[source]▶
I don’t understand the frustration. The use of .internal is explicitly for when you don’t want a publicly valid domain. Nobody is forcing anyone to use .internal otherwise.
replies(2): >>41209199 #>>41210387 #
thayne ◴[10 Aug 24 16:02 UTC] No.41210387[source]▶
My frustration is because using a private CA is more difficult than it should be.

You can't just add the CA to system trust stores on each device, because some applications, notably browsers and java, use their own trust stores, you have to add it to.

You also can't scope the CA to just .internal, which means in a BYOD environment, you have to require your employees to trust you not to sign certs for other domains.

And then there is running the CA itself. Which is more difficult than using let's encrypt.

replies(1): >>41210658 #
fleminra ◴[10 Aug 24 16:44 UTC] No.41210658[source]▶
The Name Constraints extension can limit the applicability of a CA cert to certain subdomains or IP addresses.
replies(1): >>41210934 #
1. thayne ◴[10 Aug 24 17:29 UTC] No.41210934[source]▶
How well supported is that?
replies(2): >>41212204 #>>41215579 #
2. 8organicbits ◴[10 Aug 24 21:05 UTC] No.41212204[source]▶
It's hard to say, but I'm super interested if anyone has statistics. Netflix built https://bettertls.com/ to answer these sorts of questions, but somehow forgot to validate constraints set at the root: https://github.com/Netflix/bettertls/issues/19

Anecdotally, I've seen name constraints kick in for both Firefox and Chrome on a Linux distro, but I can't comment more broadly.

3. layer8 ◴[11 Aug 24 11:58 UTC] No.41215579[source]▶
It's required by RFC 5280 (and predecessor), so it’s fairly well supported.
replies(2): >>41216496 #>>41219473 #
4. 8organicbits ◴[11 Aug 24 14:39 UTC] No.41216496[source]▶
Do you have any references for that? There are lots of RFCs that are weakly adopted or even ignored. When I tested Chrome they didn't support name constraints, but have since added support. I suspect other software is still lagging.
5. thayne ◴[11 Aug 24 21:34 UTC] No.41219473[source]▶
From the issue for support on chrome, it sounds like RFC 5280 requires it for intermediate CAs, but is ambiguous on whether it is required for root CAs (which in this case, is where you want it). So chrome didn't support it on root CAs until recently, at least on Linux.

Although, ideally, it would be possible to limit the scope of a CA when adding it to the trust store, and not have to rely on the creator of the CA setting the right parameters.