I'm trying to understand the logic of CAs, trust and client certificates. I have a general understanding but am having a tough time bridging some gaps.

In a hypothetical situation a software system might be composed of n machines. I want to generate a custom CA for this system and have it self signed. The CA would consist of a certificate and a private key. The private key would (I assume) stay private on one machine, be used only for making other certs and not be used for any inter machine communication. From what I understand, each machine that will have a certificate created in this way has to have the public key of the CA in order to validate itself AND other machines that it tries to communicate to/from.

To generate the CA key, I make a private key as normal and self sign it. That will generate a private key AND a certificate. To make client certificates I make a private key and then a signing request using the certificate of the CA.

Here are my questions about this:

  1. Is the certificate of the CA actually the public key? If not, does it contain the public key?
  2. Does every machine that needs to communicate need to have a local copy of the CA certificate in order to validate other certificates?
  3. Were my assumptions incorrect or incomplete?

Thanks for any help and understanding!!


1 Answer 1


For concreteness, let's take the concrete case of RSA. You generate your keys -- will consist of a public key -- two numbers (N, e) and a private key (N, d) so that if you use c = m^e mod N to encrypt an RSA message you can use m = c^d mod N to decrypt it. (In reality its not quite so simple, you have to worry about hybrid encryption, padding, constant-time modular exponentiation).

Certificates will contain the public key, plus data describing the organization, all of which is generally cryptographically signed -- typically by another trusted entity, except for self-signed certificates which are signed by their own public-key. To sign someone's certificate (which I will call cert) you need the private key S = Hash(cert)^d mod N. However, to verify that a signature is correct you only need a public key, by checking that S^e mod N is the same as the hash of the original cert.

So to answer your questions:

  1. Certificates are not the public key, but contain (1) the public key along with (2) other identifying information (who the organization is, what resources the certificate should be used for), and (3) a signature from some other trusted organization.

  2. If you want to validate the certificate for say https://crypto.stackexchange.com, your browser (or OS) needs to ultimately follow a chain of trust to a certificate it knows and trusts. That is the certificate served by stackexchange is valid for *.stackexchange.com is validated to belong to Stack Exchange, Inc. operated out of New York, NY. It was signed by DigiCert High Assurance CA-3 (who presumably validated the identity of Stack Exchange). The DigiCert High Assurance CA-3 intermediate Certificate Authority was itself signed by DigiCert High Assurance EV Root CA. The public certificate for DigiCert High Assurance EV Root CA is self-signed and your OS or web browser needs to have it to be able to trust it (e.g., for an OS may be stored: /etc/ssl/certs/DigiCert_High_Assurance_EV_Root_CA.pem or for a web browser /usr/share/ca-certificates/mozilla/DigiCert_High_Assurance_EV_Root_CA.crt).

  3. I think you had the gist of it. You create one CA with a CA certificate (acting as a public key + more data) that you share widely, and a private key kept secret only used to sign other certificates. When one of your machines (call it M) needs a certificate - private-key pair (e.g., to do SSL), then M creates their own private key and a certificate signing request (CSR) -- basically an unsigned certificate (technically it is self-signed - to ensure it wasn't tampered prior to being signed by the CA). The CSR is securely sent to the computer with the CA's private key, which signs the CSR to create a signed-certificate which is sent back to M. Now M can create use the certificate plus its own private key to setup SSL connections.


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.