1

This question(s) might sound naive to many of you, but I'm more of a developer than a sysadmin, so it'd be extremely useful to have some advice before digging in.

Let's say I own the foobar.com domain for my public sites and need to generate a Let's Encrypt certificate for my internal servers too:

  1. Can I use the foobar.com domain (eg. myInternalServer1.foobar.com)?

  2. Otherwise, does it need to be a real second level domain, like baz.com, or can I use a subdomain of my actual domain, like intranet.foobar.com (eg. myInternalServer1.intranet.foobar.com)?

  3. If I'm not mistaken, I should somehow instruct my main DNS server to handle foobar.com, and set up another DNS server to handle intranet.foobar.com, is it correct?

  4. While I'm the owner of foobar.com, that's currently used only for the public sites; the whole "intranet" runs under foobar.local. I've read that since a couple of years that way is deprecated. Should I change foobar.local with intranet.foobar.com in the main DNS server to make the Let's Encrypt thing work, or it's only a suggestion? Everything is based on that (Active Directory, etc) so I guess it's not an easy migration, right?

Thank you in advance

Andrea Ligios
  • 133
  • 7
  • 1
    Why are you not using [AD CS](https://social.technet.microsoft.com/wiki/contents/articles/1137.active-directory-certificate-services-ad-cs-introduction.aspx) for your internal domain's certificates? – Michael Hampton Mar 07 '19 at 14:33
  • Thank you @MichaelHampton, that sounds like a valuable suggestion to explore ASAP. I'm not the one in charge of AD, I've just helped with some servers in a small company, and ended up doing things I'm not used to. Like Ops... – Andrea Ligios Mar 07 '19 at 17:33
  • 3
    Stop what you're doing and go talk to whoever does run AD. They might even already have it set up and going and could issue certificates immediately. – Michael Hampton Mar 07 '19 at 18:09
  • How is it different from a custom CA root? Certificates within the network get recognized automatically, without installing the CA root certificate? – Andrea Ligios Mar 08 '19 at 09:11
  • All the machines joined to the domain would already have the internal CA root certificate. – Michael Hampton Mar 08 '19 at 13:55

2 Answers2

4

Let's Encrypt pretty much requires that the name you're certifying is accessible through a public IP address. Until IPv6 is more common, this will most likely not be the case for the vast majority of your servers. Even if it was, you probably wouldn't want to make web services Internet accessible without scrutiny on most of them.

Generally speaking, to solve your problem, you would instead create a private Certificate Authority (CA) for your internal network. As long as your clients trust that authority (by having relevant CA certificates installed through policies or management profiles), you're good to go.

For your other question:
Migrating from a .local AD domain to, for example, a subdomain of your Internet namespace is an undertaking that will require careful planning. Most likely you would create an entirely new AD domain with a trust relationship with the old one, and gradually migrate functions to it.

Mikael H
  • 4,868
  • 2
  • 8
  • 15
  • 3
    The first paragraph seems to focus on the HTTP-01 challenge specifically. It is not applicable to the DNS-01 challenge. – Håkan Lindqvist Mar 07 '19 at 14:50
  • Thank you Mikael, I've already explored that way. I've created a custom CA root, installed the certificate on every client, scripted some automation and put our server on HTTPS. Then [Docker came](https://stackoverflow.com/q/53159258/1654265). I've used workarounds, but I **need** a real certificate now, I've had enough of the custom CA root. I'm just trying to understand *how* the heck it should be achieved, since I know it *can* be achieved with the DNS challenge – Andrea Ligios Mar 07 '19 at 17:38
  • 1
    If your DNS provider has a compatible API (or if you have the capacity to manage your own DNS), you could probably solve your Docker issue by requesting Let's Encrypt wildcard certificates for, for example, *.webservices.yourdomain.com. As long as your docker images presented services in that namespace, you'd only need to manage distribution of a single certificate to your containers, and it wouldn't affect security for your main domain. The same method could be used with a regular commercial x509 certificate from any other CA if you're prepared to pay for it. – Mikael H Mar 08 '19 at 07:29
  • Thank you Mikael, I was thinking about a wildcard certificate since a while. How can In our DNS server `foobar.local` (sigh) is the intranet and `foobar.com` is the site. What should I do on the DNS server to create an internal address `webservices.foobar.com`, in order to generate a wildcard certificate as suggested? It's the missing piece – Andrea Ligios Mar 08 '19 at 09:02
  • There are two parts of your problem. Most likely you've got external DNS managed by a provider, and internal DNS for your AD. Only the external DNS matters to Let's Encrypt, since that's what they query to confirm your ownership of your domain. However, unless your DNS provider presents an API so you can automate updates of TXT records, the Let's Encrypt way will not work, since a record needs to be updated at the very least every three months, and you won't keep remembering to do that manually forever. The answer is to either switch to a supported DNS provider, or present DNS services -> – Mikael H Mar 08 '19 at 11:48
  • -> ...or purchase a wildcard certificate with a longer lifetime. Next question: Will your docker containers be Internet available, or will they only be used within your internal network? – Mikael H Mar 08 '19 at 11:52
  • Only in internal network – Andrea Ligios Mar 08 '19 at 16:26
  • 1
    OK, that simplifies things a lot for you: It means you can set up an external DNS record only for the purpose of the ACME DNS challenge, and keep an internal "forward lookup zone" for your docker machine subdomain in your AD DNS. But keep in mind that Let's Encrypt only issue wildcard certificates for DNS-challenge based queries, and that you'll have to automate the creation of TXT DNS records for the process, and not all DNS providers facilitate that. Read up on Let's Encrypt's own documentation for the process. – Mikael H Mar 09 '19 at 10:02
4

First of all, maybe you don't need certs from a public CA at all? If you control the clients it may make more sense to have an internal CA, in which case only your last question (4) remains (partially) relevant.

That said, from a purely technical "can this be done with Lets Encrypt" perspective:

  1. Yes, this would be possible. However, this naming convention mixes internal and public hosts in a way that will likely be problematic to handle (just in general, nothing to do with certificates). Anyway, if you use the DNS-01 challenge you can (but maybe you shouldn't) get certificates signed for any hostnames under domains you control, with or without hostnames in public DNS or publicly reachable hosts.
  2. These options are essentially the same as 1 from a technical LE-focused perspective.
    All of the options in 1 and 2 are technically possible but the two variations in 2 seem much more sensible to me as the internal names don't clash with your public DNS names.
  3. This nameserver for handling your internal DNS zones may not be necessary from a LE perspective. However, if you actually want to be able to resolve these names in your internal networks it's likely necessary for that.
  4. The local TLD is not actually supposed to be used in normal DNS at all; that name is specifically reserved for use with mDNS (multicast DNS, as in ZeroConf/Bonjour/...).
    If you want a public CA (LE or any other CA) to sign certificates for your internal names (not obviously a thing you would want, but that seems to be the premise of this question), then that's just another reason you would have to migrate to using your own namespace. I expect that fixing this after the fact is decidedly non-trivial, though.
Håkan Lindqvist
  • 33,741
  • 5
  • 65
  • 90
  • Thank you Håkan. Regarding point n.4, why should it be *"not obviously a thing I would want"*? To avoid disclosing the internal names and IP? I'd be fine with a wildcard, trusted certificate if that's matter. I've already set up an internal CA root, but it's not enough for Docker (Docker-in-Docker) to trust the certificate. – Andrea Ligios Mar 08 '19 at 09:06
  • @AndreaLigios That could be one reason, or maybe you don't want the internal hosts to have internet connectivity, or don't want an external party to be able to decide which certificates should be accepted. I didn't have any specific reason in mind. – Håkan Lindqvist Mar 11 '19 at 08:26