SSL/TSL certificates is a topic worthy being understood as an engineer. I encountered this certificate issue when I worked on hosting this blog website. Also the certificate as a security measure is used in Kubernetes as well. So in this blog, I will cover my understanding to SSL/TLS(Secure Socket Layer/Transport Layer Security) Certificate.
The certificates here is used to guarantee trust between two parties during a transaction. In network scope, it ensures the communication between client and server is encrypted and the server is who it says it is. Before steping into the certificate, let’s talk about the story about the safety of the communication between client and server first.
If a client is trying to access a server with unencrypted credentials without certificates，a hacker will be able to
step in the communication and steal the unencrypted credentials easily, which is obviously unsafe. Then we may consider
that we can encrypted the credentials with a specific method. This method intuitively can be called a key for the
credentials. But the serve can not decrypt the credential without the key. During the conversation the encrypted
credential and the key will be passed to server together. Similarly, the hacker can also step in the conversion steal
the encrypted credential and key together to decrypt the real credentials. This is known as symmetric encryption.
The encryption provide safety for the credentials but it has to use the same key to decrypt.
As described above, symmetric encryption doesn’t provide high safety in the communication between server and client.
Therefore, asymmetric encryption is introduced here. Asymmetric encryption is actually to generate a pair of key for
a user, we say, private key(held by user who generates this pair) and a public lock(put on the ‘door’ to access to
a specific server). If another one tries to access to the server as well, he has to generate his own pair and put his
own public key in another ‘door’ to the server. Now, when a client sends credentials, a symmetric key and a public key
will be transit together. After they arrive at server, the credentials will be decrypted by the private key. Under this
scenario, even if a hacker step in the communication and steal the symmetric key and public key, he still cannot
decrypted the credentials without a private key. The only way for the hacker to get the credentials is let you type
the credential into the form he presents, for example, he fakes an exactly same looking server he hosts by himself.
To prevent his new way to steal the credentials, there comes the certificates.
Everyone can generate a certificate. To verify if a certificate is secure, we have to see if the certificates are signed by certificate authority. For example, this blog website has the certificates signed by AWS. With the signature by certificate authority, a hacker will be rejected when he try to sign his fake certificate(same to the actual website) by certificate authority. The public keys of the certificate authority are build in the browsers and the private keys are held by certificate authority themselves. That is the case in web browser. If there is an application or tool like kubernetes requiring certificate authority, the public key can be set inside an specific application or tool as well. The above discussion is all about how to make sure the server we try to access is the real and legit server we want. However, sometimes the server also needs to validate the client is a legit client instead of a hacker. So a client certificate will be required then. In a web browser, we may not see the client certificate required because the whole process happens under the hood.
The whole architecture to secure communication between client and server involving above certificate authority, the
generation and maintenance of the digit certificate etc. is known as PKI(Public Key Infrastructure).