MTLS - Mutual TLS (Everything you need to know)

Introduction to Mutual TLS Transport Layer Security (MTLS)

MTLS stands for Mutual TLS Transport Layer Security.
In a secure communication between a client and a server, MTLS ensures that both the client and server authenticate each other.
MTLS goes beyond one-way TLS, where only the client validates the server's authenticity.
With MTLS, both the client and server validate each other's authenticity to ensure secure communication.
MTLS involves the use of certificates, public-private keys, and certificate authorities (CAs).
The private key, certificate signing request (CSR), and certificate are key components in setting up MTLS.
Certificate authorities (CAs) validate the CSR and issue the certificate.
The certificate contains the common name that should match the URL of the server.
MTLS is a one-time process and ensures automated validation of client-server authenticity.

The server returns its certificate public key to the client.
The client contacts the Certificate Authority (CA) to confirm the authenticity of the server's public key.
Once confirmed, the handshake process begins.
The client generates a session key using the server's public key, encrypts it, and sends it to the server.
The server decrypts the session key using its private key.
The session key is a symmetric key, allowing both encryption and decryption of data.
The client is assured of the server's authenticity at this point.
The client and server can now communicate securely using the session key.
Mutual Transport Layer Security (mTLS) requires both client and server authentication.
The server creates a Certificate Signing Request (CSR) and a server key.
The CSR is sent to the CA, which uses its own root certificate and key to produce a server certificate.
The server certificate is sent back to the server.
The server uses the server key and certificate to create a keystore.
The keystore is used to start the service over HTTPS.
mTLS uses a truststore, which contains the certificates of allowed clients.
The truststore ensures that only authenticated clients can access the server.

Importing the root certificate into the trust store allows any client issued by the certificate authority to access the application.
The client generates its own public and private key and CSR (certificate signing request), which is signed by the root certificate authority.
The client uses its own key and certificate, along with the CSR for the root certificate authority, to access the server.
The server creates its own key and certificate, and the certificate authority signs the server's CSR to generate the certificate.
The server and client each have their own key and certificate for authentication.
The commands provided in the script automate the creation of the trust store, importing the root certificate, and generating the key and certificate for the server and client.
The script also copies the necessary files into the project's resources folder.
The demo focuses on implementing one-way SSL/TLS authentication, where only the client authenticates with the server.

The server uses a certificate generated using the common name "myserver.com".
The client uses the name "API-server.skulla.com" and has changed it in the script and everywhere.
The host file needs an entry for the certificate's common name.
The ping command resolves the name correctly.
The client needs to use the "-k" option to ignore server validation.
The client can make a legitimate call to the server by providing the "CA cert" option.
The server response, issued by the same certificate authority, does not cause any complaints.
The trust store is created by the project, but not needed in one-way authentication.
Enabling the trust store property allows two-way authentication.
The server rejects requests from clients without proper public and private keys.
The client needs to use the proper curl command with the client key and client cert.
The root certificate is imported into the trust store from the client side.
The client has already created the private key and CSR and obtained a signed certificate from the same certificate authority.
The client is allowed to call the server using the CA roots in the trust store.

The server needs to prove that it is the same kind, so it uses its own key in the curl command.
The client also needs to prove its identity, so it inserts its own key in the command.
The response is received only after both the client and server authenticate each other.
The video explains how to use Amazon API Gateway to securely communicate with a Spring Boot application deployed in an EC2 instance.
The video is a part two of a document available on Medium.