My web server is (include version): AsyncServerCode https
The operating system my web server runs on is (include version): RISCV
I can login to a root shell on my machine (yes or no, or I don't know): Yes, and install certificates and private keys
Hi. I've read a lot of posts about captive portals and SSL but haven't been able to find an answer to a specific scenario that I have.
I have a development chip that has a small https server on it. This chip is used for controlling a device using a web interface. No internet is available while the chip/device is in use or serving the page that controls the device functionality. I'd like the users to be able to access this device using a secure page which they can access now, (but with warnings), through a WiFi direct connection. It will be a local address and can be used with a domain name if configured through the chips DNS.
At the moment, everything is working except the errors/warnings that come up from Chrome, FF and Safari in regards to an insecure connection.
If I was to install a certificate associated with a public domain that I would own, could I use that same certificate in the chip server if I associated the local IP site to that same public domain using the chips internal DNS? Or would the clients need to access the internet to verify the certificate?
e.g. mydevice8controller.com - buy this domain and get an ssl cert for this with wildcard
Configure the chip/device page to be (lcl.mydevice8controller.com) and install the wildcard ssl along with it.
Would I still get warning errors in web client browsers?
I'll use regular http if I have to but I'd really like to use https if possible.
It's up to you how you achieve this type of deployment, distributing a wildcard cert is technically a possibility but each device would need to get a copy of the certificate private key as well, so that's quite a risk for a wildcard as anyone with physical access could then use that cert for other things (e.g.
Do the controllers have internet access or not? If not, then there is no way for you to push updated certificates and no way for the device to acquire updated certificates, so you can only use a self signed certificate.
If your controllers have internet access you could do something like:
each unit as a unique client certificate you have assigned, this is used to authenticate to an API you control.
the unit regularly fetches it's latest https certificate from your service (authenticated using the client certificate you gave it) then automatically applies it to the https server configuration. You would also use this mechanism to refresh the client certificate before expiry. You would acquire the actual certificate from Let's Encrypt etc using DNS validation.
You would only issue each device a unique https certificate (each device would require a unique name under your domain, such as a3b4c6.lcl.mydevice8controller.com - that way there is no sharing of private keys between devices.
You could alternatively run an ACME client on the device and acquire certificates over http or DNS validation, but that can get complicated when you don't really control the device.
If you don't plan on providing the device with any means to update itself, you will have only one shot at HTTPS - assigning a "permanent" cert (that can outlast its' lifespan) included upon delivery [which is not likely possible using any globally trusted CA; as those are limited to 13 months]
That leaves you with providing the device with a very long-term cert from a private CA under your control. This, of course, will require you to provide the public cert of your private CA and clear instructions (to all your users) on how to download and install that cert into their trust store [so that they won't get the "errors/warnings"]
Which is a very risky proposition for your clients to accept [I know that I would not do that].
So that leaves the client accepting (permanently) the "self-signed" cert. Again, clear instructions on how to do that should be provided on your site (or with the "product"). But here, again, you run the risk of losing the "security conscient" users.
In short, I don't have an elegant answer short of giving the device access (at least once every 90 days) so that it can update its' globally signed cert.
Thanks for the information. The controllers are used in the field and there is no internet access. They could be plugged in using USB to update the firmware when required however and obtaining updated certs. The flash memory can also be encrypted by setting a few fuses as far as the private key goes, not 100% secure but not bad. I guess my main question is the challenge of the certificate by the client browsers, which will be 99% mobile based. Most will not have internet access to validate the cert because of the direct WiFi connection to the device which turns off mobile data in some/most cases. I was hoping that just a browser based algorithm type challenge/verification would be enough. A firmware update every 90 days or so doesn't seem too appealing. I might just stick with a non secure captive portal then. I was hoping to use a mobile app as well but without a TLS based web interface, most phone OS's won't allow it.
If your users can be instructed to accept the warning they'll get with a self signed certificate then I'd suggest just using self signed certificates. The device could perhaps generate one on each startup, or you could assign one when the device is commissioned. With self signed certs you are in charge of setting the expiry.
You can just use http only and skip certificates altogether, it sounds like the user connects directly to the devices own wifi (presumably that's secured to prevent random people connecting to that). Some privacy specific browser features will be disabled because you are access the web page over http (such as geolocation).
If it can't create a secure SSID, then a secure one can be brought by the client, and it can be preconfigured to join automatically. Then both systems could speak with each other "securely" (via the secured WAP). To overcome potential "isolation" issues, the WAP can bridge multiple SSIDs OR it can be part of a "smarter" device that can route/firewall the SSIDs from each other.
The limit is set only by what one can imagine. Well... that and the space-time continuum - LOL
Thanks to all for the replies and info on this. The WiFi connection is secured between the mobile and chip. It's not a data critical device but does only allow SSID secure connections. The goal of the valid cert TLS connection between the client and device was to alleviate the problems of warnings in the mobile browsers when connecting directly to the local IP and also to hopefully be able to use a web client module in a phone app. Web client modules/frames in phone apps can be coded to connect to a page/site as long as it's https and a valid cert. The modules are just extensions/libraries of the installed OS browsers as I understand it. These modules won't connect unless valid certs are there, they don't even give the option to trust/bypass. (Tested with my self signed cert on the device). So I'm kind of stuck with a captive portal using http, or...somehow creating a valid cert to pass for at least 12 months; or designing a remote hardware switch to control the device, which isn't out of the question. Cost wise it makes more sense to use a mobile device because everyone has one. If internet access was available, I'd use MQTT and this wouldn't be an issue. I'm going to move forward with an http captive portal and test on android/apple for a half descent user experience.
I do appreciate all the suggestions and info provided, thanks again.