Knowledge Base

1. Overview

This issue occurs when Windows or the signing application can see your certificate, but is unable to access the private key stored on the USB token.
Without access to the private key, the signature cannot be created, which is why the message appears.

This is most commonly seen in:

• Adobe Acrobat / Adobe Reader when applying a signature
• Microsoft Word / Office when signing a document

2. Symptoms

You may experience one or more of the following:

• Error: “Keyset does not exist” or “Keyset not defined”
• Certificate shows in the list, but fails when signing
• Adobe detects the certificate, but signing fails immediately after PIN entry
• Word/Office does not detect the token even though Adobe does

3. Root Cause (Simple Explanation)

Your certificate has two parts:

Part	Location
Public certificate	Visible to Windows and apps
Private key	Stored on the USB token

The error means:
The application sees the public certificate but cannot reach the private key on the token.

This is usually caused by:

• Windows using a copy of the certificate that has no private key
• Application using the wrong crypto provider (CSP vs KSP)
• Middleware (SafeNet) not linked correctly with Windows
• Running the app in a different security context (as Admin vs standard user)

4. How to Fix the Issue (Step by Step)

✅ Step 1: Verify the token is recognized

1. Open SafeNet Authentication Client Tools
2. Make sure the token appears and you can log in with your PIN
3. Confirm that a key pair is visible on the token

If this fails → reinstall or update SafeNet Authentication Client.

✅ Step 2: Remove orphaned certificate copies

Sometimes Windows keeps a duplicate of the certificate without a private key.
This causes apps to select the wrong one.

1. Open mmc.exe
2. Go to:
   File → Add/Remove Snap-in → Certificates → My user account → Personal → Certificates
3. Locate your Entrust document signing certificate
4. Right-click → Delete any copy that does not say
   “You have a private key that corresponds to this certificate.”

After deleting orphans, the app will use the hardware token version correctly.

✅ Step 3: (Optional but recommended) Re-link certificates

If Windows lost the association:

certutil -user -repairstore my "<THUMBPRINT>"

Replace <THUMBPRINT> with the certificate thumbprint if needed.
This step ensures Windows rebinds the certificate to the token.

5. Application-Specific Steps

✅ For Adobe Acrobat/Reader

Adobe can work two ways:

Mode	When to use
Via Windows Certificate Store	Most common; relies on CSP/KSP
Via PKCS#11 Module	More reliable when Windows has orphaned copies

If signing still fails after the above steps, switch to PKCS#11:

1. Preferences → Signatures
2. Identities & Trusted Certificates
3. Add PKCS#11 security module from SafeNet (eTPKCS11.dll)
4. Select the token-backed cert again

✅ For Microsoft Word / Office

Office uses the Windows CSP/KSP provider only, not PKCS#11.
So if Adobe works but Word fails, it usually means Office is still detecting a certificate copy.

Delete orphans (Step 2) and retry in Word.

6. Avoiding the Issue in the Future

Recommendation	Why
Keep a single copy of the certificate (token only)	Prevents Windows from selecting the wrong one
Do not import .cer files into Personal store	These don’t contain private keys
Don’t run Adobe as Admin unless SAC runs as Admin too	Different security contexts = no key access
Keep SafeNet Client updated	Windows 11 updates can break older SAC versions

7. Quick verification checklist

Before retrying the signature, confirm:

✅ Token visible in SafeNet Client
✅ Cert is not duplicated in Windows
✅ App is running in normal user context
✅ Using correct CSP/KSP (Office) or PKCS#11 (Adobe alternative)