I am currently learning a LOT about Azure, Azure Active Directory, and Azure Key Vault (AKV).
To start with, please see this article:
In particular, I am interested in this statement:
When designing an application, keep the following points about management certificates in mind:
- The Service Management API does not verify that a certificate is still valid. Authentication will succeed against an expired certificate.
At first glance, this strikes me as peculiar and even a little odd. I am but a security newb, however, and am looking for some clarification and insight here.
Additionally, it also appears that the same is happening with certificate connections to Azure Key Vault. That is, I can upload an untrusted (but self-signed) certificate to the AKV service, and while I do not have to verify the certificate on the client-side (seen below), I can make a call with that same certificate to the server and it will return data accordingly.
For some code, here is a snippet from this article.
public static class CertificateHelper
{
public static X509Certificate2 FindCertificateByThumbprint(string findValue)
{
X509Store store = new X509Store(StoreName.My, StoreLocation.CurrentUser);
try
{
store.Open(OpenFlags.ReadOnly);
X509Certificate2Collection col = store.Certificates.Find(X509FindType.FindByThumbprint,
findValue, false); // Don't validate certs, since the test root isn't installed.
if (col == null || col.Count == 0)
return null;
return col[0];
}
finally
{
store.Close();
}
}
}
You can see that the false is passed into the Find method so that it does not verify the certificate (on the client side). This makes sense so far (for testing purposes), but this unverified certificate can then be used to retrieve data from the Azure Key Vault (where the certificate does not appear to be verified on the server). It is also worth noting that this certificate is self-signed and has not been added to any trusted publisher or root authority on the client (so it does fail if you pass in true to the Find method above), nor has it been added to any store on the server (to my knowledge). One thought is that it could be added to a trusted store on the server, but I have not seen any documentation on this.
So, I wanted to ask this question here to see if this is considered an appropriate (and safe/secure) policy to not verify a certificate on the server, and if so, why? It would seem to me the whole reason to have a certificate is to verify it on both the client and server side.
Thank you in advance for any clarification.
EDIT: Solution
After @Mky's helpful answer I am editing/appending this question with corrections to my own understanding.
First, my understanding above is incorrect in the 2nd part of the question. The certificates are not uploaded to AKV, but to Azure Active Directory. Because of this, AAD serves as the point of security and authentication. AKV takes the client request that has the certificate attached to it and then authenticates with that certificate to AAD.
Furthermore, in this entire process, the private key is used during the authentication process from the calling client (client/web application) to sign a serialized and encoded message created from the certificate credential. So, even though the certificate might not be valid/verified from the client's certificate store, it must still have the private key installed from which the certificate was used to create. Hope that makes sense. I for one feel like my head is spinning from all of this!
