Accessing Certificate in Code with Thumbprint

Noah Hendrikx 101 Reputation points

Hi there,

we have a strange problem on one of our app services, accessing our certificate in our dotnet core application.

We configured the "WEBSITES_LOAD_CERTIFICATES" environment variable with our certificate thumbprint like described in

On starting the application, whe get the error on accessing the X509 Store With following exception:

[Error] Microsoft.AspNetCore.DataProtection.KeyManagement.XmlKeyManager: An exception occurred while processing the key element 'key id="" version="1" />'.System.Security.Cryptography.CryptographicException: Access denied.

But when i access the certificate store on kudu tools console, i can get the certificate under CurrentUser/My.

It is also working on our production system like that. Just not on our test environment.

And it gets even stranger: We got it working for now with entering a random string into WEBSITE_LOAD_CERTIFICATES with the value 'ABCABCABCABCABCABCABCABCABCABCABCABCABCABC'

So right now it is working, but i have a strange feeling running the environment like that.

Thanks in advance for any help!

Azure App Service
Azure App Service
Azure App Service is a service used to create and deploy scalable, mission-critical web apps.
7,191 questions
0 comments No comments
{count} votes

Accepted answer
  1. Noah Hendrikx 101 Reputation points

    Ok it looks like the problem lies in the certificate itself. I created a free"App Service Managed Certificate" and entered the thumbprints of this certificate and now it works.

    We have a wildcard certificate issued by COMODO. It seems that this one is issued or the .pfx file is generated with options not compatible with the "Microsoft.AspNetCore.DataProtection" service we use in our application, which uses the private key of the certificate, which strangely could not be read.

    I hope maybe this information will help some other people finding the same issue.

    Thank you very much for your help and your time!

2 additional answers

Sort by: Most helpful
  1. Noah Hendrikx 101 Reputation points

    Hi and thanks for your reply.

    To answer your first question: We configured "WEBSITE_LOAD_CERTIFICATES" via application settings in the portal. Also the private key certificate we want to access in the code is included via the "TLS/SSL settings" in the portal. We copied the thumbprint from the "TLS/SSL settings" in the portal and ensured, it has no invisible characters or anything else. We also have a custom domain binding, using this certificate and the website loads perfectly with this certificate.

    When i access the Kudu-Tools of the app service and go to "Debug console" (on the top) -> "PowerShell" i can perform a cd cert:\CurrentUser\My and a ls and the certificate thumbprint which i entered in "WEBSITE_LOAD_CERTIFICATES" is listed there.

    In our code we access the certificate as follows:

    ` using (var certStore = new X509Store(StoreName.My, StoreLocation.CurrentUser))
    var certCollection = certStore.Certificates.Find(X509FindType.FindByThumbprint, thumbprint, false);
    if (certCollection.Count > 0)
    return certCollection[0];

                throw new Exception($"Unable to load certificate by thumbprint '{thumbprint}'");`

    We do the exact same thing on our production environment, just with another certificate and of course another thumbprint.

    Thank you

    1 person found this answer helpful.
    0 comments No comments

  2. SnehaAgrawal-MSFT 19,511 Reputation points

    Thanks for asking question! Just to confirm how have you configured? As WEBSITE_LOAD_CERTIFICATES has to be added via the Application settings in the portal (does not work if you add it in your Web.config)

    Current user certificate store is local to a user account on the computer and is in the registry under the HKEY_CURRENT_USER root. Also, all current user certificate stores except the Current User/Personal store inherit the contents of the local machine certificate stores. Similar thread here might be helpful

    Reference :

    0 comments No comments