SSL/TLS enabling - openssl

Question

From here, I learnt that, we need a public key and user identification:

to create CSR

---

Goal is to establish SSL/TLS connections between two nodes(client & server).

Based on the above diagram, my understanding is, to give public key as input to create CSR but step 4 uses private key(server-key.pem) to create CSR(server.CSR)

---

Step 1) Create certificate authority key(private key)

$ openssl genrsa -aes256 -out ca-key.pem 4096

Step 2) Create Certificate authority(root certificate) with the input(ca-key.pem)

$ openssl req -new -x509 -days 365 -key ca-key.pem -sha256 -out ca.pem

Step 3) Create a private key for web server

$ openssl genrsa -out server-key.pem 4096

Step 4) Create Certificate signing request(CSR) by entering user identification. This will create public key in-turn.

$ openssl req -subj "/CN=dockerbuild.harebrained-apps.com" -sha256 -new -key server-key.pem -out server.csr

Step 5) Add the configuration

$ echo subjectAltName = IP:40.xx.xx.164,IP:10.0.0.4,IP:127.0.0.1,DNS:dockerbuildsys.westus.cloudapp.azure.com,DNS:dockerbuild.harebrained-apps.com > extfile.cnf

Step 6) Create server certificate

$ openssl x509 -req -days 365 -sha256 -in server.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out server-cert.pem -extfile extfile.cnf

Step 7) Create client private key

$ openssl genrsa -out key.pem 4096

Step 8) Create CSR for client by entering user identification

$ openssl req -subj '/CN=client' -new -key key.pem -out client.csr

Step 9) Certificate extension file for client

$ echo extendedKeyUsage = clientAuth > extfile.cnf

Step 10) Create client certificate

$ openssl x509 -req -days 365 -sha256 -in client.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out cert.pem -extfile extfile.cnf

Step 11) Removing signing requests

$ rm -v client.csr server.csr

Step 12) Remove write permissions on keys

$ chmod -v 0400 ca-key.pem key.pem server-key.pem

Step 13) Read permissions to certificate for every user

$ chmod -v 0444 ca.pem server-cert.pem cert.pem

Step 14) Uploaded on server side, Certificate authority(ca.pem), server certificate(server-cert.pem) & server key(server-key.pem)

---

I have very good understanding on symmetric and asymmetric key encryption.

We use asymmetric keys to solve key distribution problem(symmetric key) between two parties

I understand that, every certificate has public key + Identity of owner(that provides certificate)

---

Questions:

1) Are ca-key.pem, server-key.pem & key.pem symmetric keys?

2) Why to create Certificate authority(ca.pem)? Why do we need a private key(ca-key.pem) to create Certificate authority?

3) Why do we need a private key to create CSR? Because it contradicts with the diagram(above)?

4) Why to create Certificate Signing Request(CSR) before creating a certificate? both client & server

5) Why do we need two certificates(server certificate server-cert.pem & client certificate cert.pem)?

6) Does openssl req -subj "/CN=dockerbuild.harebrained-apps.com" -sha256 -new -key server-key.pem -out server.csr create server.csr that contain a public key + user identification? If yes, how this public key different from the public key provided by certificate(server-cert.pem)?

7) If there are no symmetric keys created in the above process, then how client & server communicate with encryption?

8) How server-key.pem/server-cert.pem/ca.pem(uploaded on server) work with key.pem/cert.pem/ca.pem(on client)?

Answer 1

1) Are ca-key.pem, server-key.pem & key.pem symmetric keys?

These are asymmetric keys. There are no symmetric keys at all involved when creating certificates. Symmetric keys are only involved for the actual encryption in TLS.

2) Why to create Certificate authority(ca.pem)? Why do we need a private key(ca-key.pem) to create Certificate authority? Because it contradicts with the diagram(above)

A CA is a trust anchor. The private key of the CA is used to issue (sign) new certificates. The CA certificate containing the public key is trusted by the party which likes to verify the certificate. See SSL Certificate framework 101: How does the browser actually verify the validity of a given server certificate? to get a better idea how CA certificates and leaf certificates and signatures (done using the private key) play together.

It is not actually necessary to have a CA, i.e. one could use a self-signed certificate. But in this case each party who like to verify the connection using the certificate needs to have some previous knowledge of each self-signed certificate it should be able to verify. This does not scale well, i.e. it is easier to explicitly trust a CA and then derive from this trust into the certificates issues by the CA.

3) Why do we need a private key to create CSR? Because it contradicts with the diagram(above)?

The CSR gets signed to prove that you own the private key matching the public key in the CSR (and thus in the future certificate).

4) Why to create Certificate Signing Request(CSR) before creating a certificate? both client & server

Usually the CSR is created by a different party than the CA. In this case the CSR is a signed container which provides information about the certificate the party likes to have issued. It is not technically needed to create a certificate but organizationally.

5) Why do we need two certificates(server certificate server-cert.pem & client certificate cert.pem)?

We don't. Usually only the server certificate is needed to make sure that the client communicates with the correct server. Client certificates are only needed with mutual authentication where the server likes to authenticate the client too using a certificate.

6) Does server.csr contain a public key + user identification? If yes, how this public key different from the public key provided by certificate?

The public key in CSR is the same as in the certificate. There are user specific information in the certificate (the domain) but the CA must verify through other means that these information are actually correct (i.e. user owns the domain) before issuing the certificate.

7) If there are no symmetric keys created in the above process, then how client & server communicate with encryption?

The TLS handshake contains an authentication part (check that the server is the expected one based on the certificate) and a key exchange. The latter generates symmetric keys used for encrypting the application data. See How does SSL/TLS work? for the details.

8) How server-key.pem/server-cert.pem/ca.pem(uploaded on server) work with key.pem/cert.pem/ca.pem(on client)?

The private key of the server certificate is used to sign some challenge inside the TLS handshake in order to prove that the server owns the given certificate. The private key of the client certificate is used in a similar way if mutual authentication is done. The CA certificate is used to verify the certificate (again, see SSL Certificate framework 101: How does the browser actually verify the validity of a given server certificate?).