Introduction

CryptographicException: Keyset does not exist usually means the process can see the certificate but cannot open its private key. When the error appears only through WCF, the usual explanation is that the WCF service is running under a different identity than your interactive test, so the service account lacks access to the certificate key container. The fix is normally about certificate installation and private-key permissions, not about changing WCF bindings blindly.

Why It Works Outside WCF but Fails Inside WCF

On Windows, an X.509 certificate and its private key are related but not identical resources. Code may successfully find a certificate in the store and still fail when a signing or decryption operation tries to open the private key.

WCF often triggers this during:

• message security using X.509 certificates
• transport security with client certificates
• service identity operations that require the private key

The reason it fails only in WCF is often process identity. A console test may run as your user account, while the WCF service runs as:

• an IIS application pool identity
• 'NetworkService'
• 'LocalSystem'
• a Windows service account

If that service identity does not have access to the private key, you get Keyset does not exist.

Verify That the Certificate Has a Private Key

Before touching permissions, confirm the certificate is the right one and that a private key is actually installed.

A small C# check:

1using System;
2using System.Linq;
3using System.Security.Cryptography.X509Certificates;
4
5class Program
6{
7    static void Main()
8    {
9        using var store = new X509Store(StoreName.My, StoreLocation.LocalMachine);
10        store.Open(OpenFlags.ReadOnly);
11
12        var cert = store.Certificates
13            .Find(X509FindType.FindByThumbprint, "YOUR_THUMBPRINT", false)
14            .OfType<X509Certificate2>()
15            .FirstOrDefault();
16
17        Console.WriteLine(cert != null ? cert.Subject : "certificate not found");
18        Console.WriteLine(cert != null && cert.HasPrivateKey);
19    }
20}

If HasPrivateKey is false, permission changes will not help. You either imported the wrong certificate or lost the private key during import.

Install the Certificate in the Correct Store

WCF services usually work best with the certificate in LocalMachine\My when the service runs under a machine-level identity such as IIS or a Windows service account.

Importing the certificate into CurrentUser\My may work in an interactive test and fail in the hosted service. That mismatch is one of the most common causes of the "works in my test app" version of this problem.

When importing a PFX, ensure the private key is marked as machine-accessible if the service needs it at the machine level.

Grant the Service Identity Access to the Private Key

If the certificate is correct and has a private key, grant read access to the identity running the service.

On a server, a common GUI path is:

1. open mmc
2. add the Certificates snap-in for the computer account
3. find the certificate under Personal
4. right-click the certificate
5. choose All Tasks then Manage Private Keys
6. grant read access to the service identity or app pool identity

For IIS, the identity might be IIS AppPool\YourAppPoolName.

You can also test access programmatically:

1using System;
2using System.Security.Cryptography.X509Certificates;
3
4class Program
5{
6    static void Main()
7    {
8        using var store = new X509Store(StoreName.My, StoreLocation.LocalMachine);
9        store.Open(OpenFlags.ReadOnly);
10        var cert = store.Certificates.Find(
11            X509FindType.FindByThumbprint,
12            "YOUR_THUMBPRINT",
13            false
14        )[0];
15
16        using var rsa = cert.GetRSAPrivateKey();
17        byte[] data = System.Text.Encoding.UTF8.GetBytes("test");
18        byte[] sig = rsa.SignData(data,
19            System.Security.Cryptography.HashAlgorithmName.SHA256,
20            System.Security.Cryptography.RSASignaturePadding.Pkcs1);
21        Console.WriteLine(sig.Length);
22    }
23}

If this fails under the hosted service account but succeeds as an administrator, you have confirmed a permissions issue.

Check the WCF Configuration Too

WCF configuration still matters. The certificate lookup must reference the right store location, store name, and search value.

A typical configuration fragment looks like this:

1<serviceCredentials>
2  <serviceCertificate
3    findValue="YOUR_THUMBPRINT"
4    storeLocation="LocalMachine"
5    storeName="My"
6    x509FindType="FindByThumbprint" />
7</serviceCredentials>

If the config points to CurrentUser while the real certificate is in LocalMachine, you can get a failure that looks cryptographic even though the underlying issue is simply bad lookup configuration.

Common Pitfalls

The most common mistake is granting permissions to the wrong identity. The account running Visual Studio is not necessarily the account running WCF under IIS or as a Windows service.

Another mistake is importing only the public certificate without the private key. In that case the certificate appears in the store but cannot sign or decrypt.

People also often use the wrong certificate store location. CurrentUser and LocalMachine are not interchangeable for hosted services.

Finally, avoid copying thumbprints directly from the GUI without checking for hidden characters or whitespace.

Summary

• 'Keyset does not exist usually means the process cannot open the certificate's private key'
• If it happens only in WCF, the service identity is often different from your test identity
• Verify that the certificate has a private key and is installed in the correct store
• Grant the actual service account read access to the private key container
• Check storeLocation, storeName, and lookup settings in WCF configuration
• Fix certificate placement and permissions before changing bindings or security mode