Client Certification Authentication and Certification Pinning
Hello People!
At the end of last year, I just started to work with Ruby and it’s being an amazing journey/challenge and I’m really enjoying it.
One of my most recent tasks was to create a secure architecture where our applications could communicate through REST. Of course, the first thing we did was to implement an OAuth strategy but we would like to add one more security layer between this communication, so, we decided to implement a Client Certification Authentication + Certification Pinning, and it is working smoothly, I was so proud of the result that I decided to turned it opensource and create this article talking a little bit about those strategies and their implementation so, let’s go!
What is a Client Certification Authentication?
Client Certificate Authentication is mutual certificate-based authentication, where the client provides its Client Certificate to the Server to prove its identity. This happens as a part of the SSL Handshake (it is optional).
So, it is a way to ensure that your server will only accept requests from known clients. Basically, the server will know the certificates (or only the CA) of the clients and will only allow the HTTPS connection if the client certificate sent matches with the certificates or CA that is trusted.
In our scenario, we are saying that my webserver (in our case Nginx) will only accept requests sent with the certificate issued from a trusted CA.
# mTLS block
ssl_client_certificate /etc/nginx/certificates/client_ca.crt;
ssl_verify_client on;What is a Certification Pinning?
Certificate Pinning restricts which certificates are considered valid for a particular website, limiting risk. Instead of allowing any trusted certificate to be used, the client will “pin” the certificate authority (CA) issuer(s), public keys, or even end-entity certificates of their choice, any other certificate that isn’t in the allowed list will be blocked and the TLS connection will be terminated.
In our case, we are using Certification Pinning to ensure that our client is receiving the HTTPS response from a known server. With that, we can cover the HTTPS request/response security and avoiding Man-in-the-Middle attacks (or making it harder to be done).
Ok Julio, but what are we pinning?
In this implementation, I’m using the certificate fingerprint and pinning only his base64. It is easier than loading the certificate file and converting to DER format to compare, we actually don’t need the server certificate public key, just his fingerprint.
If you liked it and want to check it out in a practical example, I created a Github repository where you can clone it and play around.
Hope you enjoyed this article and thanks for reading it.
References:
- https://owasp.org/www-community/controls/Certificate_and_Public_Key_Pinning
- https://carvesystems.com/news/cert_pin/
- [PT-BR] https://cryptoid.com.br/banco-de-noticias/o-que-e-o-certificate-ou-public-key-pinning-e-qual-a-sua-importancia/
- https://techcommunity.microsoft.com/t5/iis-support-blog/client-certificate-authentication-part-1/ba-p/324623#:~:text=Client%20Certificate%20Authentication%20is%20a,Handshake%20(it%20is%20optional).
- https://textslashplain.com/2020/05/04/client-certificate-authentication/
- https://freedomben.medium.com/what-is-mtls-and-how-does-it-work-9dcdbf6c1e41
