8 ms·

Why not use Let’s Encrypt, e.g. with DNS validation so they do not need to hit your HTTP server?

denkmoon 6y ago
They won't validate my internal domains (obviously). I have all my infra on .lan and using this they all get ACME certs and I never have to see another "insecure connection" page. Also had my old workplace on .dev until those bastards at Google stole it and added the entire tld to the hsts preload list!!
- tazard 6y ago
  With DNS validation it's fairly straight forward to get a wildcard cert for all your internal domains (*.my.domain)
  - notpiika 6y ago
    How would one set this up? Why is DNS validation needed?
    - jrockway 6y ago
      Those are simply the rules. You can do ACME with an HTTP challenge or a DNS challenge. The HTTP challenge is adequate for proving that you control x.example.com, but serving a website on x.example.com doesn't prove that you own y.example.com. But, being able to create example.com DNS records does, so that is what's required to get a wildcard certificate. I imagine you are confused because the proposal above sounds like "just get *.example.com, then copy that cert to everything that will ever serve traffic for example.com", which doesn't sound like a great idea to me.
  - vxNsr 6y ago
    I was looking into something like for my homelab but for a cert noob I got lost somewhere between trying to use intra.mydomain.com and not screwing up my public address Can you recommend a good book or blog series that covers this topic in depth?
  - treesknees 6y ago
    You still need a public-facing domain to do this, though. You can't use Let's Encrypt on a my.lan domain name, because there's no way to create the public records required to validate it.
    - Hamuko 6y ago
      My go-to way is having a public-facing domain with Let's Encrypt certs and the public-facing domain just CNAMEs to my internal domains. Public-facing domains are not luckily not that expensive and I didn't even go for the cheapest option (mine's about 10€/year).
- tialaramex 6y ago
  > Also had my old workplace on .dev until those bastards at Google stole it and added the entire tld to the hsts preload list!! They didn't steal it. You'd hijacked it, and your hijacking failed. Go big or go home. The IETF hijacked the OID arc 1.3.6.1 and they succeeded because everybody accepted their control of that arc and it's now used everywhere, but if you hijack some namespace and then only use it on a few dozen machines nobody has heard of, that's not going to stick. More seriously, what you've done is probably a bad idea. https://myprinter.lan/ https://myprinter.lan/ seems unique to you, and then your new partner moves in, why doesn't the printer work? Oh right, his printer is also named myprinter.lan because you don't have globally unique namespaces. This happens on a bigger scale at a business or other organisations of course, but it's annoying even in one household. Here's a metaphorical nickel kid, get yourself a domain in the public DNS hierarchy.
  - cookiengineer 6y ago
    Maybe it's time to ditch the printer you won't need for ecological reasons then? Jokes aside, isn't this what .local and .localdomain are specified for? Why not use nickname.local as your namespace?... it's probably unique enough at least on this planet. Of course another way would be to register one gTLD for each person on the planet, which seems to be the trend as of late /s
    - denkmoon 6y ago
      Using .local conflicts with mdns
      - jlgaddis 6y ago
        > Using .local conflicts with mdns It's completely acceptable to use .local. in such a manner, however. The "conflict resolution" process is outlined in the RFC [0] and is, well, pretty simple: > ... the computer (or its human user) MUST cease using the name, and SHOULD attempt to allocate a new unique name for use on that link. You can even set up your own DNS servers to be authoritative for the ".local." domain (zone), if you really want to. RFC6762 states that "any DNS query for a name ending with '.local.' MUST be sent to" 224.0.0.251 (or ff02::fb) -- but it also explicitly allows sending them to your regular ol' (unicast) DNS servers, too. It's up to you to figure out how to manage that, of course. Now, that said... to avoid any potential issues, I'd only ever use .local for its intended purpose. There's just too much potential for "weirdness" to occur. Personally, however, I completely avoid any use of either (.local and Multicast DNS) regardless. -- On a side note, ".localdomain" mentioned in the grandparent comment should actually be "localhost." -- [0]: https://tools.ietf.org/html/rfc6762 https://tools.ietf.org/html/rfc6762
- icedchai 6y ago
  I use int.company.com for my internal domains. company.com is a real domain that I registered. If you did similar, as opposed to making up your own domain, you wouldn't have a problem.

They won't validate my internal domains (obviously). I have all my infra on .lan and using this they all get ACME certs and I never have to see another "insecure connection" page. Also had my old workplace on .dev until those bastards at Google stole it and added the entire tld to the hsts preload list!!

tazard 6y ago
With DNS validation it's fairly straight forward to get a wildcard cert for all your internal domains (*.my.domain)
- notpiika 6y ago
  How would one set this up? Why is DNS validation needed?
  - jrockway 6y ago
    Those are simply the rules. You can do ACME with an HTTP challenge or a DNS challenge. The HTTP challenge is adequate for proving that you control x.example.com, but serving a website on x.example.com doesn't prove that you own y.example.com. But, being able to create example.com DNS records does, so that is what's required to get a wildcard certificate. I imagine you are confused because the proposal above sounds like "just get *.example.com, then copy that cert to everything that will ever serve traffic for example.com", which doesn't sound like a great idea to me.
- vxNsr 6y ago
  I was looking into something like for my homelab but for a cert noob I got lost somewhere between trying to use intra.mydomain.com and not screwing up my public address Can you recommend a good book or blog series that covers this topic in depth?
- treesknees 6y ago
  You still need a public-facing domain to do this, though. You can't use Let's Encrypt on a my.lan domain name, because there's no way to create the public records required to validate it.
  - Hamuko 6y ago
    My go-to way is having a public-facing domain with Let's Encrypt certs and the public-facing domain just CNAMEs to my internal domains. Public-facing domains are not luckily not that expensive and I didn't even go for the cheapest option (mine's about 10€/year).
tialaramex 6y ago
> Also had my old workplace on .dev until those bastards at Google stole it and added the entire tld to the hsts preload list!! They didn't steal it. You'd hijacked it, and your hijacking failed. Go big or go home. The IETF hijacked the OID arc 1.3.6.1 and they succeeded because everybody accepted their control of that arc and it's now used everywhere, but if you hijack some namespace and then only use it on a few dozen machines nobody has heard of, that's not going to stick. More seriously, what you've done is probably a bad idea. https://myprinter.lan/ https://myprinter.lan/ seems unique to you, and then your new partner moves in, why doesn't the printer work? Oh right, his printer is also named myprinter.lan because you don't have globally unique namespaces. This happens on a bigger scale at a business or other organisations of course, but it's annoying even in one household. Here's a metaphorical nickel kid, get yourself a domain in the public DNS hierarchy.
- cookiengineer 6y ago
  Maybe it's time to ditch the printer you won't need for ecological reasons then? Jokes aside, isn't this what .local and .localdomain are specified for? Why not use nickname.local as your namespace?... it's probably unique enough at least on this planet. Of course another way would be to register one gTLD for each person on the planet, which seems to be the trend as of late /s
  - denkmoon 6y ago
    Using .local conflicts with mdns
    - jlgaddis 6y ago
      > Using .local conflicts with mdns It's completely acceptable to use .local. in such a manner, however. The "conflict resolution" process is outlined in the RFC [0] and is, well, pretty simple: > ... the computer (or its human user) MUST cease using the name, and SHOULD attempt to allocate a new unique name for use on that link. You can even set up your own DNS servers to be authoritative for the ".local." domain (zone), if you really want to. RFC6762 states that "any DNS query for a name ending with '.local.' MUST be sent to" 224.0.0.251 (or ff02::fb) -- but it also explicitly allows sending them to your regular ol' (unicast) DNS servers, too. It's up to you to figure out how to manage that, of course. Now, that said... to avoid any potential issues, I'd only ever use .local for its intended purpose. There's just too much potential for "weirdness" to occur. Personally, however, I completely avoid any use of either (.local and Multicast DNS) regardless. -- On a side note, ".localdomain" mentioned in the grandparent comment should actually be "localhost." -- [0]: https://tools.ietf.org/html/rfc6762 https://tools.ietf.org/html/rfc6762
icedchai 6y ago
I use int.company.com for my internal domains. company.com is a real domain that I registered. If you did similar, as opposed to making up your own domain, you wouldn't have a problem.