3 ms·

I mean having a process, that lives somewhere on the LAN (in your router, for a home network), that has its own CA cert (self signed) and uses it to sign certs

I mean having a process, that lives somewhere on the LAN (in your router, for a home network), that has its own CA cert (self signed) and uses it to sign certs for services that live on the LAN. Services can request the CA cert, and they can ask for a cert signed with it for their own use.

LinuxBender 6y ago
Ah ok, since you mentioned IoT I assumed the device would not be able to use a self signed CA cert. I've seen a few platforms made to automate self signed certs, and DogTag was one of them. I think that was deprecated. It looks like this person made a self hosted ACME server [1] and some discussion on LetsEncrypt [2] about it. [1] - https://smallstep.com/blog/private-acme-server/ https://smallstep.com/blog/private-acme-server/ [2] - https://community.letsencrypt.org/t/private-acme-server-in-organisation/130755 https://community.letsencrypt.org/t/private-acme-server-in-o...
- JulianMorrison 6y ago
  I think you're still missing the intent, so I'll go through it in small pieces. - Service starts up, makes itself a CA cert signed by itself. - IoT device starts up. - IoT device says to service, "please may I have a HTTPS certificate?" - Service makes a HTTPS certificate, and signs it using the CA that it made, above. - Service replies "yes you may have a HTTPS certificate and here it is" Later, in the browser: - user visits https://iotdevice.lan/ https://iotdevice.lan/ which is the public page for the IoT device - browser says, "oh hey, this is on a LAN IP" - browser says to service, "please may I have a copy of your CA cert?" - Service says "sure here is a copy of my CA cert" - Browser installs it as a trust root for the LAN only - Browser sets up a HTTPS connection to https://iotdevice.lan/ https://iotdevice.lan/ - The connection is successful because it presented a HTTPS certificate signed by one of the browser's trust roots
  - LinuxBender 6y ago
    What bootstraps all of the steps that talk to this service? DHCP + wpc_url in DHCP options? How would the IoT and the browser know about this service and make use of it? If it's manual steps, then the self hosted ACME service should suffice. If you need the IoT and browser to just figure this out, then all IoT's and browsers would need some form of service discovery. ssdp, dhcp+wpad_url, etc... or captive portal perhaps for wifi. Even then we are talking about amendments to RFC's and getting everyone to adopt this.
    - JulianMorrison 6y ago
      I'm presuming there's some standard way to discover this service, like it's on a standard broadcast address. Yes, it would need to be supported by browsers.
      - LinuxBender 6y ago
        some standard way Browsers and IoT today have no standard way to do this today aside from corporate managed workstations like active directory policies. The mechanisms could include broadcast packets like ssdp, or DHCP options with some mangled use of wpad_url, but the browsers and IoT today don't have such a mechanism for certs. So it will be on you or a team you build to write the RFC's for this, create standard client libraries that can be used in IoT and browsers, then get everyone to adopt them. Maybe a smaller baby-step would be to see if there is a way to write the client as a browser addon. Assuming this is even possible with the sandboxing of addons today, if it became popular enough, maybe browser vendors would uptake your code as a standard function in the browser. IoT manufacturers are all over the board on standards and seldom agree on one thing. Maybe you could start with high end enterprise IoT devices that live on corporate networks. Some generic IoT devices today work around this by just accepting any cert but you can't predict what devices will do this.

LinuxBender 6y ago

Ah ok, since you mentioned IoT I assumed the device would not be able to use a self signed CA cert. I've seen a few platforms made to automate self signed certs, and DogTag was one of them. I think that was deprecated. It looks like this person made a self hosted ACME server [1] and some discussion on LetsEncrypt [2] about it. [1] - https://smallstep.com/blog/private-acme-server/ https://smallstep.com/blog/private-acme-server/ [2] - https://community.letsencrypt.org/t/private-acme-server-in-organisation/130755 https://community.letsencrypt.org/t/private-acme-server-in-o...

JulianMorrison 6y ago
I think you're still missing the intent, so I'll go through it in small pieces. - Service starts up, makes itself a CA cert signed by itself. - IoT device starts up. - IoT device says to service, "please may I have a HTTPS certificate?" - Service makes a HTTPS certificate, and signs it using the CA that it made, above. - Service replies "yes you may have a HTTPS certificate and here it is" Later, in the browser: - user visits https://iotdevice.lan/ https://iotdevice.lan/ which is the public page for the IoT device - browser says, "oh hey, this is on a LAN IP" - browser says to service, "please may I have a copy of your CA cert?" - Service says "sure here is a copy of my CA cert" - Browser installs it as a trust root for the LAN only - Browser sets up a HTTPS connection to https://iotdevice.lan/ https://iotdevice.lan/ - The connection is successful because it presented a HTTPS certificate signed by one of the browser's trust roots
- LinuxBender 6y ago
  What bootstraps all of the steps that talk to this service? DHCP + wpc_url in DHCP options? How would the IoT and the browser know about this service and make use of it? If it's manual steps, then the self hosted ACME service should suffice. If you need the IoT and browser to just figure this out, then all IoT's and browsers would need some form of service discovery. ssdp, dhcp+wpad_url, etc... or captive portal perhaps for wifi. Even then we are talking about amendments to RFC's and getting everyone to adopt this.
  - JulianMorrison 6y ago
    I'm presuming there's some standard way to discover this service, like it's on a standard broadcast address. Yes, it would need to be supported by browsers.
    - LinuxBender 6y ago
      some standard way Browsers and IoT today have no standard way to do this today aside from corporate managed workstations like active directory policies. The mechanisms could include broadcast packets like ssdp, or DHCP options with some mangled use of wpad_url, but the browsers and IoT today don't have such a mechanism for certs. So it will be on you or a team you build to write the RFC's for this, create standard client libraries that can be used in IoT and browsers, then get everyone to adopt them. Maybe a smaller baby-step would be to see if there is a way to write the client as a browser addon. Assuming this is even possible with the sandboxing of addons today, if it became popular enough, maybe browser vendors would uptake your code as a standard function in the browser. IoT manufacturers are all over the board on standards and seldom agree on one thing. Maybe you could start with high end enterprise IoT devices that live on corporate networks. Some generic IoT devices today work around this by just accepting any cert but you can't predict what devices will do this.