6

I am developing a network management product. We ship our product to customers as a VM, which they install on a hypervisor in their network. These VMs are given static, private IP addresses in the customer network. They monitor the customer's devices, and run a (Apache/Django) webserver showing the state of the network. Customers access the site by the private IP and we access the VMs directly using TeamViewer (installed before we ship them), so there's no public IP or domain name involved. We'd very much like to provide SSL certs on our VMs so that clients stop seeing notifications that our site is insecure (and of course, so that our site stops being insecure). Preferably, customers should not have to add trust for a new CA or add security exceptions to their browsers.

What is the most efficient and cost effective way to do so? I have tried LetsEncrypt, but they only support certs for domain names, not for IPs.

BThompson
  • 191
  • 1
  • 1
  • 7
  • You can't get a cert for an internal IP from a public SSL vendor, because you could take that SSL and put it on someone *else's* network that has that same private IP being used for something. It'd be an attack vector. As such, you're going to need to head in the private CA direction. – ceejayoz Dec 20 '18 at 16:03
  • Ah, that makes sense. So, should we make our own root CA, and issue certs for each VM from that? – BThompson Dec 20 '18 at 16:13
  • HTTPS and IP based certificate will not mix well (while you can technically create certificates for IP addresses, the browsers will probably not use them). So even with a private CA you will need to find an hostname for your website. And a private CA means adding its trusted certificate into **every** client browser. – Patrick Mevzek Dec 20 '18 at 16:14
  • @PatrickMevzek Yeah, adding it to client browsers is part of what I'm trying to avoid – BThompson Dec 20 '18 at 16:15
  • Register a domain name, says `example.com`. Ask a CA to issue a wildcard for `*.example.com`. Deploy on your clients systems your application with hostnames such as `client1.example.com`, `client2.example.com`, etc. making sure the name resolves correctly (either you do it - like "Mogens TrasherDK" answer but beware the fact some resolvers filtering private addresses in DNS replies), or let your client configure their DNS so that the map is done), in each case returning the wildcard certificate. If the CA is known, nothing to change in clients browsers. – Patrick Mevzek Dec 20 '18 at 16:17
  • Getting client IT to add a DNS record will be much easier than getting each client user to add the cert manually. But are you saying that if the client doesn't have an internal DNS, we could add a public DNS record that returns a private IP? – BThompson Dec 20 '18 at 16:22
  • 1
    "we could add a public DNS record that returns a private IP" Yes, if that is not filtered later by the recursive, which is a measure existing against the DNS rebinding attack ( https://en.wikipedia.org/wiki/DNS_rebinding ) – Patrick Mevzek Dec 20 '18 at 17:36
  • See also RFC1918 (about private IP addresses) section 3: "Indirect references to such addresses should be contained within the enterprise. Prominent examples of such references are DNS Resource Records and other information referring to internal private addresses. In particular, Internet service providers should take measures to prevent such leakage." – Patrick Mevzek Dec 20 '18 at 20:01
  • Enterprise products ship with a generated self signed certificate and allow the end user to install their own certificate. Beyond providing the relevant functionality, you don't need to do anything. – Michael Hampton Dec 21 '18 at 18:07

4 Answers4

5

Just use a self-signed certificate as you already do, and don't try any dirty hacks to bypass the error. Provide your customers an option to replace that certificate with their own. The replacement certificate can be signed by a public CA using their own public (sub) domain name or by a locally trusted CA, e.g. using Active Directory Certificate Services. Either way, it'll always be compatible with their infrastructure and security policy.

Esa Jokinen
  • 43,252
  • 2
  • 75
  • 122
  • +1. Could you comment on my answer, and whether it seems to be a dirty hack? I don't have much networking experience, so I'm not sure if I'm missing anything – BThompson Dec 21 '18 at 17:55
3

You could set up a domain, with DNS servers, to return private ip addresses for dns requests. That's what I'm doing here.

$ resolveip node-1.example.com
IP address of node-1.example.com is 192.168.1.71

This way you can use name based tls certificates, and get valid dns

Mogens TrasherDK
  • 141
  • 7
  • So, would we need to get each client to add this on their own internal DNS? What if they don't have one? – BThompson Dec 20 '18 at 16:16
  • You can set up your own dns, for a domain you own, and setup dns records for the internal ip. – Mogens TrasherDK Dec 21 '18 at 00:25
  • I'm using public DNS to resolve to private IP addresses. Neither `8.8.8.8` or `one.one.one.one` is filtering name to ip requests. – Mogens TrasherDK Dec 21 '18 at 00:35
  • 1
    This would give the same URL for every instance of the device/VM. If someone else has the same system and a client travels between such networks, they might end up using someone else's system. This might be a security risk. – Esa Jokinen Dec 21 '18 at 04:24
  • @EsaJokinen You are assuming every instance has the same private IP address, where I'm assuming every server has a unique address. That's how I would set it up anyways. – Mogens TrasherDK Dec 22 '18 at 07:07
2

There is a few contradicting requirements in the question which I suggest you resolve by using a domain name rather than an IP address.

You ask for a certificate for an internal IP address from a CA which is already trusted by browsers. However if a CA were to issue such certificates browsers would probably stop trusting the CA, which would defeat the purpose of you choosing that CA in the first place.

However you can get a certificate for a real domain name and point that name to an internal IP address. At this point there is going to be a couple of decisions to make. One of the decisions depend on why you are using an internal IP address in the first place. Are you using an internal IP address due to shortage of IP addresses, or are you using an internal IP address as a method of access control?

For the rest of my answer I'll assume you are using it as a method of access control. If you are only doing it due to shortage of IP addresses there are other and possibly simpler solutions.

In order to issue a certificate LetsEncrypt need to send an HTTP request to the domain, for that reason the domain has to resolve to a real IP address which is reachable for LetsEncrypt. The server you direct LetsEncrypt to is the one where you generate the certificate, which does not have to be the same as the one where you will ultimately be using the certificate. And since you want strict access control on the VM using the certificate you'll probably want LetsEncrypt to be communicating with a different server.

You never want the server on which you generated the certificate to actually use it, instead you'll copy it to the VM on the customer site.

On the end user site you'll then override that domain name in their DNS configuration to point to the local IP of the VM.

All of this could be done using the same name for every VM at every customer site. But using the same name introduce a security risk as any of your customers would have access to a certificate that could potentially be used against other customers. Instead I recommend you register a domain name and create a subdomain for each VM (don't put these names under your regular domain name used for other purposes). If you have registered example.com, you can then user something like customername.example.com for each VM (or replace customername with a different value if the customer do not want their name in audit records of your chosen CA).

Customers should not be forced to use a subdomain of example.com. You can do that for them as a default setting. But you should also allow the customer to provide their own domain name, in which case they also have to provide their own certificate. For that purpose you can both have the VM export a CSR that can be signed a CA as well as implement integration with LetsEncrypt.

kasperd
  • 29,894
  • 16
  • 72
  • 122
0

We are planning to go with a mix of several options posted here.

1) For clients with their own CA infrastructure (ADCS or otherwise), we will use one of their certs.

2) For clients with no CA but with DNS, we will get a wildcard cert for *.productname.com and have client IT add a DNS record pointing to our VM within their network. As I understand it, we will then be able to use this wildcard cert for all clients of this type.

3) For clients with no CA and no internal DNS, we will resort use self signed certs and have client users manually add them to their browsers. I was hoping to avoid this, but the only other option would be to use the wildcard cert with a public DNS record pointing to a private IP in their network. This would leak both information about our customers networks (at least the IP of our server), and about our client list, which makes it a no-go for us.

BThompson
  • 191
  • 1
  • 1
  • 7
  • Keep in mind that all your clients will not only have your certificate, but also the private key associated to the certificate, embedded in your product. What's your plan on securing the key? Clients may have all sort of curious people who would like to reverse engineer everything. I would. – Esa Jokinen Dec 21 '18 at 18:37
  • Options 1 and 3 are a good combination. It's also possible to deploy trusted certificates, e.g. with Group Policy. Not necessary to install on every client separately. – Esa Jokinen Dec 21 '18 at 18:40
  • @EsaJokinen "What's you plan on securing the key?" For option 3 you mean? Can we generate it on a computer we control, and transfer only the cert to the VM? Additionally, in all cases, the client will not have access to the OS of our VM. Their only interaction with our product (after installing it on their hypervisor) will be through the website – BThompson Dec 21 '18 at 19:24
  • If I only knew one I wouldn't think you should abandon that idea. Also, I can't see a case that isn't already covered with 1 or 3. – Esa Jokinen Dec 21 '18 at 20:02
  • If I'm not mistaken, the fact that clients have the key to a certificate that is not restricted to their domain (case 2) and could be used to attack other clients is considered a key compromise and when/if pointed to by anyone to the CA, would require the CA revoke that certificate within 24 hours. You would at the minimum have to ensure the key is not recoverable by the client, and even then I'm not sure it would not lead to revocation. – user2313067 Dec 22 '18 at 15:57