Hacker News Reader

Comment by Jaruzel | Hacker News Reader

One of the wonderful aspects of this, that no-ones pointed out yet, is that these can used for INTERNAL domains, without you having to run your own internal CA.

i.e. lets say your internal network DNS domain is 'my-company-lan.com' - all you have to do is ensure that 'my-company-lan.com' is also registered in public DNS[1], and then you can secure ALL your internal services using a free LE wildcard cert, that's automatically trusted by all platforms and browsers[2]. For some companies that's going to be a BIG cost and resources saving.

[1] but not actually used for any public facing services.

[2] Mostly...

View on HN

Going to reply to my own comment here.

It's at this point that I swear profusely at Microsoft yet again, for pushing the concept of '.local' domain suffixes a decade ago. As it's not a legal TLD, I can't get certs for any of my internal services without rolling my own internal CA, which only works automatically for Windows domain machines, and not for anything else.

The ".local" suffix was a terrible idea, to be sure. Active Directory domain rename in small environments is relatively painless.

Unless of course, you are running Exchange. In which case it's not supported :(

Unfortunately, yes. I've been lucky enough to be able to get domain renames done in Exchange 2003 environments (which is supported) or in non-Exchange environments. Migrating to a new domain because of a poorly-chosen name is a real pain. (I have one Customer who has a "." in their NetBIOS domain name. That creates some interesting kinds of hell-- completely breaks the NPS RADIUS server in Windows 2012.)

I agree that it’s terrible, but the reason they used to recommend .local goes back to their Small Businness Server in the 1990s when it was very expensive and bureaucratic to register a domain - not something they could demand of their target market. MS’s error was their failure to update their recommendations after domain registration became cheap and easy.

IIRC Microsoft does now recommend using a real domain with a real TLD nowadays.

And also conflicts with mdns. :(

Can you create a CNAME on your internal DNS so server1.company.local = server1.company.com?

Found here: https://community.spiceworks.com/how_to/139715-letsencrypt-w...

Just remember that the cert will be logged (Certificate Transparency) so any names there will be disclosed to the public. Wildcards help a little here though.

You could do this before too, without wildcards.

Can you outline the approach how this would work? It was my understanding that in order to use Let's Encrypt you needed a public facing server to verify ownership.

You just need public facing DNS.

For the standard LE certs, you need a public facing web server for the domain name in question, and LE give you a keyfile to put into:

'/.well-known/pki-validation'

For the wildcard certs, you just need to add a TXT record to the public DNS entry, no public web server required.

Even if you have no intention of using your internal DNS domain name on the internet, it's good practice to register it anyway.

Is there a "standard" TLD for internal use that will also fit this requirement?

The problem here is that there's no such thing as domain ownership, only domain renting. You forget to pay your bill (read: someone loses an email) and a core part of your infrastructure is up in smoke, or worse, taken over by a squatter.

It makes no sense to have publicly trusted certificates for names that have no defined legitimate meaning - what is being certified? Nothing. Accordingly no public CA is permitted to issue such certs.

Of course not. If there was a domain reserved for internal use and everyone could get a cert for it, everyone would be able to impersonate your internal hosts.

I don't think there's a way around coming up with a reliable process for renewing your domain. You somehow manage to do it for lots of other things already.

Some years ago, at least one of the popular CAs used to issue certs for RFC1918 IP addresses. Fun times.

You can use a dns challenge for v1 "regular" certs - there's no requirement for a web server, in order to use let's encrypt.

See eg point 4: 0https://github.com/Neilpang/acme.sh/wiki/How-to-issue-a-cert

Instead of fetching the secret via a direct HTTP call, the secret is fetched from the DNS server (eg. _acme-challenge.example.com.) - where the DNS server is usually separate from the server getting the cert. This can be done with ACMEv1 for certs, and now is required for the new wildcard certs.

Most clients that support DNS-01 can use nsupdate or APIs of public DNS providers to make this an automated process.

You have multiple authorisation mechanism. The one you are referring too is http but you could also use DNS (you add a pre-agreed string as a TXT entry). Wildcard requires dns validation whereas domain specific certificates can use both.

You could, but the wildcard cert makes it much easier...

"One cert to rule them all, and in the darkness 'bind' them."

Reply on news.ycombinator.com