1

I'm curious to know how mTLS works in more detail in regard to client authentication.

Firstly, I issued 3 certificates: root CA, server and client. The last two are signed with the root CA.

Secondly, I imported the client's .p12 (the client certificate and the private key incorporated) and the root CA (certificate only) to my KeyChain.

Finally, I configured nginx on my localhost with SSL enabled and set the server certificate and the private key. I also set the rootCA as an "appropriate authority" for clients' certificates like so:

listen        443 ssl;

ssl_certificate     /usr/local/etc/nginx/ssl/testcasignedsrv/x509-server.crt; // server's certificate
ssl_certificate_key /usr/local/etc/nginx/ssl/testcasignedsrv/x509-server.key; // server's private key

ssl_client_certificate /usr/local/etc/nginx/ssl/testcasignedsrv/ca.crt; // self-signed CA that signed the client's and server's certificates, "CSU" in this case
ssl_verify_client on; // enables client's authentication

Everything seems to work fine since when I visit the localhost I'm presented with a pop-up to choose the certificate

enter image description here

After I choose one, the authentication succeeds in accordance to the following mTLS figure

enter image description here

As far as I understand, the client certificate is sent to the server, then the Signature of the client certificate (the signature of the issuer inside the client certificate) is verified with the rootCA public key. If it matches, the client is allowed to the web-server.

My question is what do I need the client's public and private keys for in terms of mTLS? Maybe when I hit "OK" in the browser the client's own signature created (with the private key) and somehow verified with the root CA? Could anyone please clarify.

Joe D
  • 143
  • 5
  • *"what do I need the client's public and private keys"* - I hope the question marked for duplicate answers this. In short: The private key is used to proof that the certificate is actually owned by the client. The mechanism is basically the same as with the client validating that the server certificate is actually owned by the server. – Steffen Ullrich Jan 25 '22 at 19:48
  • Ok, what is the public key of the client certificate is used for, if in order to authenticate only `signature` of the issuer inside the client certificate and the `issuer's public key` are used? – Joe D Jan 25 '22 at 20:10
  • The public key of a leaf certificate (no matter if client or server) is used to check the signature done with the matching private key. The signature done with the private key and send within CertificateVerify is the proof that the client actually owns the private key for the provided certificate. – Steffen Ullrich Jan 25 '22 at 20:14
  • Let's focus on the client certificate. I'm using this in my project and there are 2 fields in the client certificate that I find a bit confusing.. `Signature - is the issuer's signature, represented as an array of bytes. Given the public key of the issuer and the signature itself, one can verify that the certificate has actually been issued by a particular issuer` ------------------ `Public Key - is also an array of bytes and in the context of client's authentication used for...` Could you please finish what it's really used for in simple terms? – Joe D Jan 25 '22 at 20:26
  • The signature in the certificate is used to validate the trust chain, i.e. that it is signed by a trusted CA - see [here](/questions/56389/) for details. The public key is (as I explained) used to verify the signature send in CertificateVerify during the TLS handshake. Essentially there are two parts here: a) check that the certificate is the expected one (trusted, valid, ...) and b) check that the peer has the matching private key to proof ownership, i.e. that it is not send by some man in the middle instead of the real certificate owner. – Steffen Ullrich Jan 25 '22 at 20:29

0 Answers0