This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(131.20000000000002, 90%, 22%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EJJ%3C/text%3E%3C/svg%3E)
We have uploaded a certificate under our Azure Active Directory App:-
but the issue is that any user who have access to this Azure AD App >> can view the Thumbprint value of the certificate .. so is there a way to hide this Thumbprint value from end users?
Thanks
I just wanted to check in and see if you had any other questions or if you were able to resolve this issue?
Why? The Thumbprint plays no part in the authentication process, it's just an identifier for the certificate.
If you want to restrict end users from seeing it, you can block their access to the Azure portal altogether: https://learn.microsoft.com/en-us/azure/active-directory/fundamentals/users-default-permissions#restrict-member-users-default-permissions
But users with admin roles will still be able to see the thumbprint value.
@Vasil Michev but as i know that Thumbprint should not be exposed, as hackers can submit the Thumprint along with the TenantId and ClientId and they can call AD Active Directory App... in other words inside our azure function we pass those info to call the Azure AD APP; ClientId, TenatID & Certificate Thumprint.. so which values are actually confidential in this case?
@Vasil Michev but as i know that the Thumbprint is like a key for the certificate and should not be exposed, and it is part of the authentication process..
Also currently we are passing those values;ClientId, TenantID & Thumprint so which values are confidential and which are not?
Not exactly. The thumbprint is just a unique identifier for the certificate. It's technically needed, as it tells Azure AD which certificate to use for verifying the signed token, but the signing process itself is based on the private key. Without having access to the private key itself, the thumbprint gives you nothing.
On the client side (your app or PowerShell script), you can pass the thumbprint as a way to identify which certificate to use, but you can also pass a certificate object itself, or even a PFX file. You still need to have access to the private key in order to submit a signed assertion, which is then examined by Azure AD. As part of the process, Azure AD will use the corresponding public key of the certificate matching the thumbnail value. This is again just a pointer, if no matching certificate is found, or a certificate with the same thumbprint, but different public key is configured (i.e. someone somehow manages to get your cert's thumbprint and tries to "spoof" the certificate), the validation will fail, and no token will be issued.
Take a look at the MSAL documentation if you want more details, perhaps I'm not explaining it properly: https://learn.microsoft.com/en-us/azure/active-directory/develop/msal-net-client-assertions
I just wanted to check in and see if you had any other questions or if you were able to resolve this issue? If the information helped address your question, please Accept the answer. This will help us and also improve searchability for others in the community who might be researching similar information.
I just wanted to check in and see if you had any other questions or if you were able to resolve this issue?