←back to thread

.INTERNAL is now reserved for private-use applications

(www.icann.org)
563 points joncfoo | 3 comments | 09 Aug 24 16:36 UTC | HN request time: 0s | 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 #
wkat4242 ◴[10 Aug 24 01:37 UTC] No.41206719[source]▶
The problem with internal CAs is also that it's really hard to add them on some OSes now. Especially on android since version 7 IIRC, you can no longer get certs into the system store, and every app is free to ignore the user store (I think it was even the default to ignore it). So a lot of apps will not work with it.
replies(2): >>41207082 #>>41208303 #
thaumasiotes ◴[10 Aug 24 09:19 UTC] No.41208303[source]▶
> The problem with internal CAs is also that it's really hard to add them on some OSes now. Especially on android since version 7 IIRC

That's because the purpose of certificate pinning is to protect software from the user. Letting you supply your own certificates would defeat the purpose of having them.

replies(3): >>41208737 #>>41208743 #>>41210474 #
1. Arch-TK ◴[10 Aug 24 11:22 UTC] No.41208743[source]▶
Certificate pinning and restricting adding custom certificates to your OS except if you're using MDM are two completely unrelated things. Overriding system trust doesn't affect certificate pinning and certificate pinning is no longer recommended anyway.
replies(1): >>41209950 #
2. freedomben ◴[10 Aug 24 14:54 UTC] No.41209950[source]▶
They are certainly different things, but they're not unrelated. The inability of the user to change the system trust store is part of why certificate pinning is no longer (broadly) recommended.
replies(1): >>41213279 #
3. Arch-TK ◴[11 Aug 24 00:59 UTC] No.41213279[source]▶
Certificate pinning is mainly an obstacle to using an intercepting proxy to inspect and modify the traffic of an application. If you're doing that kind of stuff you already know how to bypass the annoying OS level certificate store restrictions or how to modify an application to disable certificate pinning. The reason certificate pinning is no longer broadly recommended is because of how it makes it more difficult to rotate certificates in the case of necessity, and has nothing to do with the restrictions certain operating systems place on easy installation of your own certificates.