I am considering an IoT device connected to my local network (default settings, no VPN, no NAT, no DMZ) with or without Internet access. My device will run as a HTTP server offering a RPC mechanism with authentication and authorization. It advertises itself with mDNS and I talk to it using my mobile app or my RaspberryPi.

It seems that the norm in IoT development is to have mutual (two-way) SSL. Does that mean that one-way SSL cannot secure my trafic? Why?


  • I do understand the technical differences between one and two way SSL, I do not understand why is One-way (almost) never considered in IoT production.
  • I understand having mutual SSL for a local device is difficult: you need to share server public key and cert to client and vice-versa. One-way, on the other hand, seems easier (does not require user action).
  • Some mass produced devices like Philips Hue would rather have a local http endpoint open and unsecured than a one-way SSL encryption. Why would one make this choice?
  • I expect this question not to be opinion-based. Apologies if this is the case.

2 Answers 2


SSL/TLS works well when the "server" is at known location (a fixed hostname) that can match the CN of the certificate it presents.

This doesn't work well for device on home networks (e.g. most IoT devices) because they tend to get IP addresses issued from RFC1918 blocks and do not have DNS entries. This means they can not be issued with certificates (well they can but most browsers will reject them). This is why devices like Philips Hue use unsecured HTTP endpoints of the device, they are basically relying on access to the network being secured to protect the device.

When mutual TLS is used it is for when the device is connecting to some central service, the client has it's own cert/private key to authenticate that it is able to act on behalf of the owner with that central server.

As a point of clarification to your question you do not need to distribute the servers cert/key to all the clients, just the certificate of the CA that issued the certificate is needed to prove the cert is trusted.


A good example of a secured local device connection is IKEA's Tradfri lighting which uses COAP over DTLS with a pre-shared key (in a QR code) on the device which is used to generate a per client key. This ensures physical access to setup a new client and protects data in flight on the local network.

  • If the host is not at a fixed DNS name or IP address then normal certificate verification fails, as the cert asserts that the device at that address is who it say it is (normal "single sided" SSL). For mutually authenticated SSL you should not be using the same key/cert for both parties. The server and client should reach have their own cert/key signed by a mutuality trusted CA
    – hardillb
    Commented Jul 2, 2018 at 14:42
  • Thanks for the answer and sorry for the long silence @hardillb. "This means they can not be issued with certificates (well they can but most browsers will reject them)." Considering a communication with my IoT device, I do not see when I will use a browser to do so... "you do not need to distribute the servers cert/key to all the clients, just the certificate of the CA" This is for one-way TLS, correct? Because for mutual I believe you do need to give the cert and the key, which makes things way more difficult. Regarding Tradfri, the pre-shared key is for auth, not encryption.
    – valentin
    Commented Jul 2, 2018 at 14:43
  • No the tradrfi pre-shared key is to handshake and create a per-device key for encryption
    – hardillb
    Commented Jul 2, 2018 at 16:03

Generally, TLS is good for much more than x.509, but many implementations limit it to only x.509.

x.509 is a technique for a secure indirect trust. "A" trusts "B", if "B" has a certificate, which is signed by "C" and "C" is trusted by "A". That works also in real life; you trust someone you don't know, if a letter is presented signed by a person you trust. Maybe you see the pitfall: if the letter says, please give a cup of coffee you won't give your car. Therefore the additional information in the certificate is also relevant to scope the trust. That's why a server usually has it's dns name or ip-address in it's certificate. Generally you may include different information (e.g. "living room lamp"), but many implementations are also at least preconfigured to use/check the DNS/IP stuff. And all that is only working if someone cares about the trusted "C's". Usually the OS or Application provider does this by updating the list of valid "certificate authorities". That's a lot of complexity, with implementations developed mainly for none IoT use-cases. Or who is going to update the list of valid "certificate authorities" on your device? I guess you will have to do it on your own.

If you can spend time in it, check your implementation, if it offers also PSK cipher suites. If not, maybe you can adjust the "validation check" of the servers certificate. But it requires a lot of reading to find a good solution. And sometimes the used TLS implementation just doesn't offer that.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.