Mutual authentication - setup, flow, verification

Question

I am implementing mutual authentication between a single client hosted app (CLIENT) and my spring boot 2 application (SERVER). I understand the steps to be as follows:

• The server generates a keystore and truststore. The keystore being used for storing the server's certificates and private key. The truststore used for storing other credentials (certificates from certificate authority (CA) or trusted client certificates).

• A CSR is raised for the server which is then passed to a CA. The CA generates a signed certificate from the CSR. This is the installed in the server keystore.

• The client (which has it's own keystore and truststore) provides their public key to the server. This is then installed in the server truststore.

When a https request is made from client to server:

1. The client makes a request to access a protected resource.
2. Server responds with their public certificate.
3. Client verifies that certificate (looks in truststore and checks if it signed by a trusted CA).
4. Client presents their public certificate to server.
5. Server then verifies certificate against their truststore.
6. Assuming verification success client is granted access to the protected resource.

So I have a few things which I'm a bit confused about...

• Are the steps outlined above broadly correct?
• How does the server verify the client certificate? (I think it looks at the truststore for that certificate but not sure what actually happens after that).
• I've seen examples of the CA certificate being installed in the server truststore instead of the actual client's public certificate ~ is there a use case when this should or should not be done? For my use case I have been provided with a signed certificate from the client (third party). The CA who signed that is different from the CA who signed the server certificate.
• Does this process actually authenticate the client i.e. this client can now have access to the servers protected resources but another client who might present a different certificate will not have access? (like a more secure method of providing a username and password)
• Where does common name (CN) checking come into all of this? I note in Spring Boot X.509 you can derive a username from the CN and then use this to lookup the appropriate user details from the user details service.
• If the client certificate gets compromised for whatever reasons is this managed by just removing it from the server's truststore?
• Is there an advantage, in my scenario of using a trusted CA e.g. verisign to produce a client certificate over a self-signed one? i.e. the certificate is passed to me directly from the trusted third party, and then installed.

Answer 1

In respect to your first question, yes your outlined steps are correct! Here is the general mutualSSL flow with a graphical overview: (source)

1. A client requests access to a protected resource.
2. The server presents its certificate to the client.
3. The client verifies the server’s certificate.
4. If successful, the client sends its certificate to the server.
5. The server verifies the client’s credentials.
6. If successful, the server grants access to the protected resource requested by the client.

Your second question (How does the server verify the clients certificate?): The server verifies the clients certificate with the help of the signature. The signature is usually a hash-value, build of the complete certificate. The hash-value is signed with the private key of a corresponding CA (certificate authority). The server verifies the signature of the client certificate with the help of the CA's public certificate.

Your third question (Servers truststore containing the clients public key/certificate or the corresponding CA certificate?): If you use for example self-signed certificates, you probably have to import the clients public key/certificate directly into the servers truststore. If your client uses an CA signed certificate, it is appropriate for you server to store the CA public key/certificate only, because it is used to verify the clients certificate.

Your fourth question (Does this process actually authenticate the client): Yes! As you can see in the answer to your second question, the certificate is verified by checking the signature. The signature is a hash over the complete certificate. A standard X.509 contains information to identify the subject. By checking the signature the subject is authenticated. A standard X.509 certificate contains amongst other things e.g. this information: Subject name, Subject Public Key Info, Public Key Algorithm, Issuer Unique Identifier (optional), ...

Your fifth question (Where comes CN checking?): The CN (common name) verification is executed during the certificate check. The CN identifies the valid hostname for the current certificate. It is limited to one entry. As an extension the SAN (subject alternative name) was introduced. A certificate can contain more than one SAN. The CN (and the SAN) entry is part of the certificate and is verified with the help of the certificates signature check.

Your sixth question (If the client certificate gets compromised for whatever reasons is this managed by just removing it from the server's truststore?): Therefore the CAs use so called revocation lists. If you are using for example self-signed certificates it would also be okay to just remove the compromised certificate entry from the servers truststore.

Your seventh question (Is there an advantage, in my scenario of using a trusted CA e.g. verisign to produce a client certificate over a self-signed one?): There exist a few advantages of using a CA signed certificate instead of self-signed ones.

• The certificate and eventually the revocation is managed by the CA
• The certificate is valid to every relying party of the public CA, e.g. Verisign
• Most of the public CAs offer standardized ways of creating a certificate