mTLS introduction
Introduction
There is a standard called mutual TLS (mTLS). While TLS has the function of verifying the server’s identity, mTLS has the function of verifying not only the server’s identity but also the client’s identity. This article explains how to implement mutual TLS using certificates.
Preparation
As a prerequisite, we need to understand the mechanism called Public Key Infrastructure (PKI). In public key cryptography, confidentiality can be ensured through encryption using public keys, and tamper detection and authenticity verification are possible through signatures with private keys and verification with public keys. In addition, we need to verify in advance whether the public key itself is correct and whether the destination is correct. If the destination is not correct, encryption is meaningless.
We actually operate a public key infrastructure and implement TLS (and HTTPS). We need to link public keys with identity information and have them recognized that this public key belongs to this person (organization). The entity that provides this recognition is the Certificate Authority (CA). This CA can be operated by a publicly recognized company or can be created privately.
CAs include root CAs and intermediate CAs under them. Note that root CAs rarely issue server certificates directly; for security reasons, the structure is such that intermediate CAs handle issuance. By using this mechanism, the party verifying public keys only needs to have the root CA certificate for verification. This is because the public key sent from the server contains the CA hierarchy up to the root CA, making it clear which root CA certificate should be used for verification. These root CA certificates are included by default in operating systems and browsers.
Topics of mTLS
Client Certificate
As you may already understand, in mutual TLS, the client side (the party initiating communication) also needs a certificate to prove its identity.
Certificates can be distinguished between server certificates and client certificates, and the Extended Key Usage field must specify the value Client Authentication (1.3.6.1.5.5.7.3.2).
According to RFC5280:
If the extension is present, then the certificate MUST only be used for one of the purposes indicated.
So, if EKU is specified, the usage should be clearly limited. Conversely, if EKU is not specified, the usage is not limited, so it seems it could also be used as a client certificate. (This depends on the accepting party’s policy.)
In AWS ACM, you can issue public certificates with Amazon.com as the root CA, but the Extended Key Usage value is fixed at Server Authentication (1.3.6.1.5.5.7.3.1) and cannot be changed, so only server certificate use is assumed.
To issue client certificates in AWS, you need to use AWS PrivateCA and build your own root CA.
Steps in Client Side
The difference from TLS is that after the client verifies the server certificate with the CA certificate, the client performs the Certificate, ClientKeyExchange, and CertificateVerify steps. (In the case of TLS 1.2)
I won’t go into details here, but the important point is that a signature must be created using the private key that was the source for creating the client certificate. This signature is sent to the server and verified, thereby proving the client’s identity.
Closing Thought
I thought that Extended Key Usage should clearly separate server certificates and client certificates, but in reality, it doesn’t seem to be mandatory. Many implementations don’t distinguish between them. It depends on security requirements and design.