Day 15/#30daysofK8s

To validate if the public key received from a server is legit, the server sends along a certificate to provide proof of authenticity. A Certificate can be self-signed, not making it very authenticate. Any self-signed certificate is detected by the browser and it warns of such a website(remember every appliance URL and insights URLs that required adding certificates to the website’s list).

To prove the authenticity, the certificate must be signed by a certificate authority(CA). CAs are well-known organizations(e.g. Symantec, DigiCert) that verify the information and validate the certificate. A web browser has a whitelist of a few CAs that it uses when establishing communication.

There are 3 steps involved with creating a new certificate — 1)Certificate Signing Request(CSR), 2) VAlidate Information, and 3) Sign and send the certificate

CSR(Certificate Signing Request) — is a request created with the CAs for a new certificate. openssl req -new -key my.key -out my.csr -subj="/C=US/ST=CA/O=MyOrg, Inc./CN=my-bank.com"

Validate Information — CAs validate the information sent in the CSR. CA uses different sources to verify that the person sending the request is the actual owner of the website.

Sign and send certificate — Once all the info checks out, the certificate is signed and can now be used.

To know if the CA themselves are legit and the certificate claiming to have been signed by the CA is legit, the CAs themselves have a public-private key pair, they use the private key to sign the certificate and their public key is already present in the browser’s CA list. On chrome, check the certificate settings to see a list of all the authorized CAs. These inbuilt CAs are all public. For private CAs, an organization may have its own private CAs and install their public key in all the org members’ browsers.

Admin — generates private-public key pair for SSH-ing into the server.

Server — creates a private-public key pair for securing HTTPS traffic. For this, the server has to first send a certificate signing request with a CA. The server already has CA’s public key. CA validates the CSR and signs the certificate with its public key and sends it back to the server.

Whenever a user sends a request to the server, the server first sends the certificate to the user with its public key, for establishing a secure connection. The user’s browser validates the certificate and uses it to retrieve the browser’s public key. It uses this public key to generate a symmetric key that it uses for future communications. This symmetric key is encrypted with the server’s public key and is sent back to the server. The server uses this symmetric key whenever it receives some message from the user.

How does the server know that the client is who it says it is? For this, even the client should generate a certificate, get it signed by CA and share it with the server.

All of this(both server and client communication establishment) happens under the hood. This whole process of generating and maintaining digital certificates is called Public Key Infrastructure(PKI).

The public and private keys can both be used to encrypt and decrypt the data. If a public key is used to encrypt the data, the data can only be decrypted with its paired private key and vice versa. So this also means that if we encrypt the data with a private key, anyone with the public key, which is basically everyone can decrypt the data. Ironically, data must be encrypted with the public key, so that only people with its paired private keys can decrypt it.

Certificate(Public Key) — extensions are .pem or .crt

Private key — extensions are *-key.pem or .key