Academic Integrity: tutoring, explanations, and feedback — we don’t complete graded work or submit on a student’s behalf.

I\'m trying to understand the logic of CAs, trust and client certificates. I hav

ID: 653120 • Letter: I

Question

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!!

Explanation / Answer

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.