XENROLL_E_KEYSPEC_SMIME_MISMATCH 0x80095005 Fix: Signing Cert Can't Have SMIME

When This Error Hits

You're enrolling a certificate for email signing — maybe through Windows Certificate Manager (certmgr.msc) or via a smart card enrollment agent. Halfway through, you get hit with:

XENROLL_E_KEYSPEC_SMIME_MISMATCH (0x80095005)

This usually happens when you request a certificate with the Key Usage set to Digital Signature but the certificate template has the S/MIME extension flagged. I've seen this most often on Windows 10 22H2 and Windows 11 23H2 when enrolling from a domain-joined machine against an Enterprise CA running Windows Server 2019 or 2022.

Root Cause — Plain English

The error means you're trying to use a signing-only certificate for S/MIME (Secure/Multipurpose Internet Mail Extensions). Think of it like trying to unlock a mailbox with a key that only opens a door — they're both keys, but the lock expects a specific shape. The certificate template says "This cert is for S/MIME, not just signing", but your request says "I only want signing, not S/MIME." Windows sees that mismatch and throws 0x80095005.

The S/MIME extension is separate from the basic Key Usage. Even if your template has Digital Signature enabled, if the Enhanced Key Usage (EKU) includes 1.3.6.1.5.5.7.3.4 (Secure Email), the enrollment engine expects the cert to also support S/MIME key exchange. Your signing-only request doesn't have that, so it fails.

The Fix — Step by Step

You have two paths: request the cert with the right KeySpec, or fix the template. I'll give you both. Try Path 1 first — it's faster and doesn't require CA admin access.

Path 1: Request with the Correct KeySpec Using certreq

This is the fix I use on help desks. You'll create a custom INF file that tells Windows to request the cert for S/MIME, not just signing.

1. Open Notepad as administrator.
2. Paste this, replacing YourTemplateName with the actual template name (e.g., User or SmartcardUser):

[Version]
Signature="$Windows NT$"

[NewRequest]
Subject = "CN=Your Name, OU=Your Dept, O=YourOrg"
KeySpec = 2
Exportable = TRUE
RequestType = PKCS10
KeyUsage = 0xA0

[Extensions]
2.5.29.37 = "{text}1.3.6.1.5.5.7.3.4,1.3.6.1.5.5.7.3.2"

KeySpec = 2 is the magic number — it sets the cert for S/MIME (key exchange). KeyUsage = 0xA0 means Digital Signature and Non Repudiation, which S/MIME needs. The EKU line 1.3.6.1.5.5.7.3.4 is Secure Email, and 1.3.6.1.5.5.7.3.2 is Client Authentication (often bundled).

3. Save as smime_request.inf to a folder like C:\Certs.
4. Open Command Prompt as administrator and run:

certreq -new -config "YourCAServer\YourCA" C:\Certs\smime_request.inf C:\Certs\smime_request.req

Replace YourCAServer\YourCA with your CA server's DNS name and CA name. You can find this by running certutil -config from an admin prompt on a domain-joined machine.

5. Submit the request: certreq -submit -config "YourCAServer\YourCA" C:\Certs\smime_request.req C:\Certs\smime_request.cer
6. Install the certificate: certreq -accept C:\Certs\smime_request.cer

That should get you past 0x80095005. If it fails, the problem is in the template itself.

Path 2: Fix the Template (Requires CA Admin)

If you control the CA, open Certificate Templates Console (certtmpl.msc) on the CA server. Find the template you're using, right-click, and Duplicate Template. On the Request Handling tab, make sure Key Exchange (S/MIME) is selected, not Signature only. Also go to the Extensions tab and verify Enhanced Key Usage includes Secure Email (1.3.6.1.5.5.7.3.4). Reissue the template from the CA, then re-enroll.

If you're using a smart card certificate, the same principle applies — the template must allow S/MIME key exchange. Many smart card templates default to Signature only for email, which causes this exact error. Switch it to Key Exchange (S/MIME) and you're done.

What to Check If It Still Fails

• Check the CA server version — Windows Server 2012 R2 has a known bug where KeySpec = 2 gets ignored on some templates. Upgrade to Server 2019+.
• Look at the certificate template permissions — You need Enroll permission on the template. Run certtmpl.msc, right-click the template, go to Security, and confirm your user or group has Enroll checked.
• Check the CA's certificate manager — Sometimes an admin inadvertently blocked S/MIME enrollment on the CA itself. Run certsvc.msc on the CA, right-click Certificate Templates, and ensure your template is listed and enabled.
• Verify the INF file's key usage flags — If you used KeyUsage = 0x80 (signing only), change it to 0xA0. The 0x20 that some guides suggest for S/MIME is wrong — 0xA0 covers both Digital Signature and Non Repudiation, which S/MIME certs need for email signing.

I've seen this error trip up even seasoned admins, especially when migrating from Windows 10 to 11. The fix is almost always the KeySpec value or the template's request handling setting. Try Path 1 first — it's saved me hours of digging through CA logs.