Certificate Authentication in Key Vault

Question

I have some secrets that I would like to keep in Azure Key Vault. I know I can use a client id and certificate to authenticate with Key Vault instead of using a client and and secret following these steps:

1. Get or Create a Certificate
2. Associate the Certificate with an Azure AD application
3. Add code to your application to use the Certificate

Most examples use either makecert or New-SelfSignedCertificate to create the certificate. Is a self signed certificate problematic in this case for a production application? This is only for an application to authenticate with Azure Key Vault and it's not something a client will ever see in their browser.

If a self signed cert is still frowned upon in this case then is purchasing a cert from a trusted authority the same process as purchasing an SSL/TLS certificate? Is it even the same type of certificate?

Answer 1

There is (with some caveats) nothing inherently wrong with using a self-signed certificate. There is no difference from a pure crypto perspective between a purchased and a self-signed certificate. The sole difference is that a purchased certificate has been signed by one or more certificate authorities (CAs) who distribute their public keys with most browsers/operating systems/etc. This means that a user can have a much higher confidence that a purchased certificate is legitimate, while they must take a leap of faith to accept a self-signed certificate.

In your case, however, you seem to be able to control the client application, and actual users should never see this certificate. Therefore, you can use a self-signed certificate without worry, so long as you take precautions to prevent man-in-the-middle attacks (i.e. someone generating their own self-signed certificate and pretending to be you.). One of the most effective ways to do this is via certificate pinning. In essence, you ship the public key for your certificate with you client application, and your client application will only accept certificates that provide that public key. This makes it much more difficult for a malicious actor (who has not stolen your certificate) to preform a man-in-the-middle attack.

TL;DR: So long as you take steps to prevent man-in-the-middle attacks, and you keep your certificate secure, there is nothing wrong with using a self-signed and self-generated certificate to secure non-user-facing connections.