Selfhosted @lemmy.world Karna @lemmy.ml 2w ago

Let’s Encrypt Begins Supporting IP Address Certificates

linuxiac.com Let’s Encrypt Begins Supporting IP Address Certificates

Let’s Encrypt begins issuing IP address certificates, expanding support beyond domain names to cater to specialized use cases, such as DoH and home devices.

Who benefits from this? Even though Let’s Encrypt stresses that most site operators will do fine sticking with ordinary domain certificates, there are still scenarios where a numeric identifier is the only practical choice:

Infrastructure services such as DNS-over-HTTPS (DoH) – where clients may pin a literal IP address for performance or censorship-evasion reasons.
IoT and home-lab devices – think network-attached storage boxes, for example, living behind static WAN addresses.
Ephemeral cloud workloads – short-lived back-end servers that spin up with public IPs faster than DNS records can propagate.

You're viewing a single thread.

62 comments

That's kind of awesome! I have a bunch of home lab stuff, but have been putting off buying a domain (I was a broke college student when I started my lab and half the point was avoiding recurring costs- plus I already run the DNS, as far as the WAN is concerned, I have whatever domain I want). My loose plan was to stand up a certificate authority and push the root public key out with active directory, but being able to certify things against Let's Encrypt might make things significantly easier.
- FYI you can get a numeric xyz domain for 1$ a year
  
  At least for the first year.
  
  Pretty sure it remains $1. But it's specifically only 6-9 digit numeric .xyz domains.
  
  nice
- Setting up a root and a immediate CA is significantly more fun though ;) It's also teaches you more about PKI which is a good skill to have.
  
  but for the love of god and your own benefit, put a name constraint directly on the root cert
- I use a domain, but for homelab I eventually switched to my own internal CA.
  
  Instead of having to do service.domain.tld it's nice to do service.lan.
  
  Any good instructions you would recommend for doing this?
  
  use the official home.arpa as specified in RFC 8375
  
  No thanks. I get some people agreed to this, but I'm going to continue to use .lan, like so many others. If they ever register .lan for public use, there will be a lot of people pissed off.
  
  IMO, the only reason not to assign a top-level domain in the RFC is so that some company can make money on it. The authors were from Cisco and Nominum, a DNS company purchased by Akamai, but that doesnt appear to be the reason why. .home and .homenet were proposed, but this is from the mailing list:
  
  we cannot be sure that using .home is consistent with the existing (ab)use
  
  ICANN is in receipt of about a dozen applications for ".home", and some of those applicants no doubt have deeper pockets than the IETF does should they decide to litigate
  
  https://mailarchive.ietf.org/arch/msg/homenet/PWl6CANKKAeeMs1kgBP5YPtiCWg/
  
  So, corporate fear.
  
  But home.arpa’s top-level domain is .arpa?
  
  I'm not sure I follow the question. All of the TLD *.arpa is not reserved for private use, only *.home.arpa. So all your internal services are required to be a sub domain.
  
  Sounds like you followed.
  
  Now that I’m moving goalposts, why not use .home.arpa subdomains?
  
  Instead of having to do service.domain.tld it's nice to do service.lan.
  
  Oops. :)
  
  I just use openssl"s built in management. I have scripts that set it up and generate a .lan domain, and instructions for adding it to clients. I could make a repo and writeup if you would like?
  
  As the other commenter pointed out, .lan is not officially sanctioned for local use, but it is not used publicly and is a common choice. However you could use whatever you want.

62 comments