Solutions to sign certificates

Question

For a system with multiple application servers and multiple clients, I would like to introduce mutual authentication as well as other security protections provided by TLS.

The servers and clients may be located on different networks as well as on the same network.

Each entity (client or server) has its own keystore that stores its private/public key pair and a X.509 certificate that wraps the public key. But, at this point, the certificate is self-signed. So, it will not be verified by the other communicating entities. After some research, I've looked at some solutions:

1. Creating a private CA that will sign the certificates. If I understand well, the CA's certificate must be present in the truststore of each entity so that certificates of other entities may be verified using the CA's certificate.
2. Creating a private CA as the first solution. But, the private CA's certificate is signed by a commercial CA (e.g. Verisign). I don't know what it adds to the previous solution.
3. Signing each entity's certificate by a commercial CA. But this solution seems expensive.
4. Use of self-signed certificates only. Each entity's certificate is self-signed by it and must be added to the truststore of each entity it wants to communicate with.

It's my first experience with security. Among the solutions that you consider as valid, which one do you recommend?

Thanks

Thedrick

Consider CAcert. – Verulamium

Answer 1

I've numbered your options for easier reading.

Your option 4 has comparable security and management specifics as the first one. I.e. your options are narrowed down to own-vs-thirdparty CA services. While you can buy your own CA certificate from CA authority, it would cost, emm, a lot. But how much is "a lot" is determined on case by case basis by CA salesmen.

In terms of management complexity I'd put them in the following order (first is the easiest): 3, 1, 2, 4

In options 1, 2, 4 you have to manage your certificates which requires both knowledge of PKI and it's security procedures (besides purely technical, you will need to ensure that private keys are protected) and software for certificate generation and management (openssl and alike won't be enough for most activities, and most likely you will need to write your own code for certificate generation).

And it's a good idea to have an OCSP server too, which you would have to run yourself in case of options 1, 2, 4.

Aikido

I would also hope that not everyone can get hold of an intermediate CA (option 2), since they might be able to issue certificates for machines that are not theirs, and have it recognised by any browser. – Borrego

Thanks for your answer. Do you know about some documentation for creating your private CA? – Thedrick

@MickaelMarrache, you might be interested in this question. – Borrego

@Borrego Thanks for the link. I also found this tutorial - fusesource.com/docs/broker/5.3/security/i305153.html. What do you think? – Thedrick

@MickaelMarrache I'd suggest reading a book or two about PKI infrastructure (eg. amazon.com/gp/product/0072131233). Articles won't be enough cause besides coding side there's an infrastructure management side in your question, and it's very important, even more important than coding one. – Bainbrudge

@Borrego "since they might be able to issue certificates for machines that are not theirs, and have it recognised by any browser." A CA can restrict what names a "sub-CA" can generate certificates for. See the ExtendedKeyUsage and NameConstraints extensions (section 4.2.1.10 of RFC5280) – Porter