> Unless you plan to assign your Ethernet expander a domain name, how do you expect it to participate in WebPKI?
Well, it does support DDNS, [1] so presumably some people do assign it a domain name. But I don't expect it to participate in WebPKI necessarily. That's not the only way to secure communication from the config program to the device, e.g.:
* The routers I worked on in 2006 had baked-in keys/certs signed by our own CA with cn based on serial number rather than reachable customer-chosen FQDN. That's not WebPKI but it actually works. Elk's configuration software knows the expected serial number and could use a similar approach. The configuration is not http-based (much less browser-based) anyway.
* It'd be better to just punt and say the communication should be secured by proxy or VPN or something than to offer TLS in a misleading way and suggest it should be directly exposed to the Internet.
As for the Ethernet expander to the central station, that totally could use TLS and WebPKI.
Well, it does support DDNS, [1] so presumably some people do assign it a domain name. But I don't expect it to participate in WebPKI necessarily. That's not the only way to secure communication from the config program to the device, e.g.:
* The routers I worked on in 2006 had baked-in keys/certs signed by our own CA with cn based on serial number rather than reachable customer-chosen FQDN. That's not WebPKI but it actually works. Elk's configuration software knows the expected serial number and could use a similar approach. The configuration is not http-based (much less browser-based) anyway.
* It'd be better to just punt and say the communication should be secured by proxy or VPN or something than to offer TLS in a misleading way and suggest it should be directly exposed to the Internet.
As for the Ethernet expander to the central station, that totally could use TLS and WebPKI.
[1] https://elk-manuals.s3.amazonaws.com/M1XEP_v2_Installation_M... page 14