I am working on a small M2M project (a few hundred nodes connected to a single cloud server), and want to use client certificate authentication, with each client getting its own unique cert at manufacture time. During development we have been using a self-signed .crt and .key to generate the client certificates, and all has been going well. We can issue and revoke certs as needed and our cloud service does the right thing with regard to refusing the connection if the client's cert is invalid or revoked.

Now we're getting closer to production time, and I wonder if this is a safe-enough approach, or whether there is some value in buying a PKI package from a "real" CA. The client nodes will be distributed around the world and will be connecting via regular Internet connections (no VPN, probably plenty of NAT'ted connections), if that makes any difference.

  • Welcome to the Information Security stack exchange! You may want to read the site tour at help --> site tour to get a "free" badge!
    – Jonathan
    Commented Feb 2, 2015 at 21:15

1 Answer 1


If you trust the security in place in the configuration of your own CA and you don't need other entities to trust you but only your nodes to trust each other, you're probably OK with your current setup.

If you want other entities to trust you, you should use a public CA or you could issue that third party a certificate such that they can trust your certificates. You could also exchange certificates and have mutual authentication whereby you trust each other.

If you don't trust your CA configuration, you should use a public CA. Note that a public CA will usually have a root HSM in offline mode which stores the root certificate and subordinate CA servers for different roles (issuing, revocation etc) and the audits and validation on these can be quite thorough.

I'm sure there are lots of other considerations but I'll leave that to those here who know better.

You must log in to answer this question.

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