Imagine having a couple of hundred of embedded devices in the field that need to be remotely managed over SSH or HTTPS.

These embedded devices are exposed on the internet but are installed at secure locations. They are put in an enclosure that cannot be accessed by unauthorised personnel.

The people that require remote access to these devices are limited, and are dedicated support personel.

What is the risk of using self-signed certificates in this case ? Providing we

  • clearly communicate to the people that need to access these systems that these are indeed self-signed server certificates.

  • we install the root CA certificate on the clients

  • It's never an option if you have a business based on this. Communication doesn't make your security stronger.
    – Xavier Lucas
    Oct 31, 2014 at 21:41
  • How are you remotely managing these devices? I would be strongly tempted to manage them with puppet, which also happens to include a CA infrastructure and creates per-computer certs on every client. With that in place you simply need to trust your Puppet CA.
    – Zoredache
    Oct 31, 2014 at 21:52
  • The devices will most likely be provisioned using vagrant / puppet. The reason I'm asking about self-signed certificates is because installing unique CA signed certificates on all devices isn't really scalable. (not to mention the cost). Wildcard SSL certificates also have drawbacks I guess. If one device is compromised all of them are.
    – ddewaele
    Oct 31, 2014 at 22:02

1 Answer 1


using self-signed certificates ... we install the root CA certificate on the clients

Your statements are conflicting: Either you have (your own) root CA to sign all certificates, or all these certificates are only signed by themselves (self-signed) which means there is no root CA.

If all of the machines are managed by the same party then you can use a common trusted root CA for all the certificates. It not only simplifies everything, but it can actually be more secure if all clients used to manage the machines only accept this single CA as trusted and if this CA only issues certificates for this machines. Having self-signed certificates is instead a maintenance nightmare, because you would need to trust each of these certificates explicitly instead of just trusting a single CA.

But, I doubt that you will be able to roll out your own CA in a secure way based on your current knowledge. Since a compromise of your own CA would immediately compromise the certificates of all your machines, I would strongly recommend that you get a recognized (instead of a self-proclaimed) security professional on board to help you with this issue.

Apart from that it might be a good idea to ask such questions at security.stackexchange.com.

  • Actually, the OP's original statement was correct. He needs to install the root CA cert on the clients, and then his CA generates certs. This is no different to (for example) Verisign getting their root CA embedded in your browser.
    – davidgo
    Nov 1, 2014 at 6:06
  • This part was correct, but calling these kind of certificates self-signed is wrong. A self-signed certificate is not signed by a private CA but only by the certificate itself, so no common CA is involved. Or, to cite wikipedia "...that is signed by the same entity whose identity it certifies". Nov 1, 2014 at 8:00
  • I guess I got the terminilogy wrong. I did mean certificates that are signed by a private CA. Is there a specific name for that ?
    – ddewaele
    Nov 1, 2014 at 11:27
  • This is called creating your own PKI. Nov 1, 2014 at 12:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .