• caglararli@hotmail.com
  • 05386281520

Sensor device web interface certificate

Çağlar Arlı      -    8 Views

Sensor device web interface certificate

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?