0

I have sensor devices with a configuration web interface. Each device has a unique serial number. The devices are deployed in various environments with private IP addresses such as 192.168.x.y or 10.x.y.z. Between different environments, these IP addresses will often overlap: environment A with a sensor with IP 192.168.100.200 and environment B with a sensor with the same IP address. The devices will be accessed through a plain Windows laptop by technicians needing to access hundreds of these devices across different environments. The sensor devices and laptops operate without Internet access. There is a private CA that can be installed as trusted by every browser used to access the configuration web interface.

I would like users accessing the configuration web interface to have as much security as practically possible and as few security warnings as possible.

I can have the sensor devices generate a key pair and a CSR based on the device's unique serial number at the moment of manufacturing, and get it signed by the private CA. This would allow both the identification of the device (serial number) and validation (signed by trusted private CA). However, since the devices usually don't have a hostname and don't know the IP address they will end up with at the moment they generate the CSR, how can the CSR be created in such a way that a browser shows this as 'OK'?

The best I've been able to come up with is to create the CSR for "mysensordevice-serialnumber.private.something" and adapt the DNS host file of the laptops accessing the device, setting a DNS entry "mysensordevice-serialnumber.private.something" to point to the IP address the sensor device ends up with. However, this moves the problem from the CSR to the DNS host file: each device would need to be added to every technician's laptop after it's known which IP address it ends up with (which is usually only when the technician is accessing the device).

I have read a lot of questions and answers about this on this stack exchange and it seems the best reasonable solution is just to accept the device will not have a TLS connection the browser can fully mark as secure? Thoughts?

Tomas Creemers
  • 101
  • 1
  • Related: https://security.stackexchange.com/questions/121163/how-do-i-run-proper-https-on-an-internal-network – mti2935 Jun 16 '21 at 21:55
  • @mti2935: I had read that post (and linked posts) before posting. My scenario is a little different: there's no DNS, and no Internet access. I can have a private CA installed as trusted by every user, but not every single device's certificate. The device's certificates can be signed by the private CA, but won't pass browser inspection due to being on some random IP address. – Tomas Creemers Jun 16 '21 at 22:37
  • I think the crux of your problem is that this is running on a private LAN, and the devices will have unpredictable IP addresses on the private LAN. In that regard, it's the same as the linked question. The (non-ideal) solutions included in the question may apply in your case, as well as the (non-ideal) solutions in Steffen Ullrich's answer. In short, there is no good solution to this problem. This is why the management interface on most consumer-grade routers is almost always accessible by http only, and not https. – mti2935 Jun 16 '21 at 23:19
  • The difference is that my sensor devices don't have fixed host names either. The answer of Steffen Ullrich is based on fixed private host names. He summarized by "_either misuse a public CA for internal hosts with all the drawbacks or create your own CA with all the drawbacks_". I'm very willing to use my own CA, but even so browsers will always complain about the certificates since the subject alt name can't match. Device with serial number 12-34-56 could be sensor12-34-56.mydevices.something, but that won't resolve correctly, unless moving the problem to become a fixed DNS host file problem. – Tomas Creemers Jun 16 '21 at 23:34
  • 1
    Are the sensor device and the technician's laptop on the same subnet? If so, you might be able to give the device a certificate for mysensordevice-serialnumber.local and have the device answer mDNS queries to resolve it. – user2313067 Jun 17 '21 at 05:29

1 Answers1

0

You can use CMP (https://en.m.wikipedia.org/wiki/Certificate_Management_Protocol) i.e., certificate management protocol. It is a protocol for obtaining the x509 certificate in PKI (Public Key Infrastructure). It requires CA (Certificate authority), RA ( Registration Authority) and end clients (CMP clients)

So, your client i.e., sensor devices will act as a CMP client and after they are provisioned with IP address you can initiate a request to RA for certificate issuance with IP address as CN. RA will process the request and send to CA for issuing the certificate and provide the certificate to CMP clients (your devices).

But the only catch is that you need one RA (registration authority) which can connect to Private CA and act as a mediate between private CA and end clients i.e., sensor devices.

As you said there is no network connectivity for sensor devices you can setup RA locally on that environment with connectivity to CA. So, your end client will only connect with RA whereas RA will be the only server which will connect to Private CA. You can bring RA up and down as per requirements whenever you require the certificate re-issuance. RA is just acting like a person who will take CSR to CA and request signing. The only difference is it is managed automatically by RA.

saurabh
  • 723
  • 1
  • 4
  • 12
  • Thanks for the reply! CMP seems interesting. If I understand it well, CMP is a protocol for (among other things) the generating, sending, signing, and returning CSRs (or equivalent). (Correct?) That would save me from custom-building that web service. As you say, the catch would be that to have the certificate be accepted by browsers, the CMP usage needs to happen after the devices get their final IP address, at which time there's no connectivity to the private CA anymore, except when someone manually takes the CSR, switches networks, transmits it (CMP or otherwise), and vice versa... – Tomas Creemers Jun 16 '21 at 23:43
  • @TomasCreemers I've updated the answer. Also, CMP is not about providing the CSR only. It is a certificate management in PKI. AFAIK browser will not accept the certificate because CN is not matching the URL in browser which is actually ip address. With CMP you will get the certificate with IP address as CN. The only catch I've mentioned is RA which is the only client which need connectivity to CA. – saurabh Jun 17 '21 at 05:28