Understanding SSL

Table of Contents

TODO

The entity that wants to be secured will use its own private key and send a CSR (Cerficate Signing Request) to a Certificate Signing Authority (CSA).
The CSA will use their private key to approve this CSR and they will give a certificate to the requesting entity.

All of the client applications have the CSA’s public key.
All of the client applications will also have the public key of the secured entity (the bank).
Check the path /etc/ssl/certs for the list of available public keys that are being used by the local computers.
The client application needs to send a request to the secured entity with a key that is encrypted using the public keys of the CSA and the secured entity.
Since the secured entity has a certificate from the CSA and it’s own private key, it will use it’s private key and the certificate from the CSA to validate whether this request from the client application can be trusted or not.
This is how the communication between the client applications and the secured entity are protected/secured.

root.key is the private key of the server that wants to be secured.
root.crt is the root certificate of the server that wants to be secured.
kafka.keystore.jks is for the server that wants to be secured.
kafka-signing-request.crt is the CSR from the server to the local CSA.
kafka-signed.crt is the signed certificate from the local CSA.
The server’s root certificate and the signed certificate from the CSA are imported into keystore. This is because, for development purposes, we also the secured server. The secured server’s keystore needs to have the root certificate and the signed certificate imported.
We also import the root certificate into the trust store. This is because, for development purposes, we are also the client application. So, the client application’s trust store needs to have the root certificate.