CERT_E_WRONG_USAGE (0X800B0110): Fix Certificate Usage Error

You're staring at 0x800B0110 and your app won't connect. I've been there — it's a certificate usage mismatch, and the fix is straightforward once you know what's happening.

The Real Fix

Open an elevated Command Prompt (Run as Administrator) and run this:

certutil -repairstore my "CERT_SERIAL_NUMBER"

Replace CERT_SERIAL_NUMBER with the actual serial number of the certificate throwing the error. To find it, run:

certutil -store my

Look for the cert with the issue, copy its serial number (has no spaces), and plug it in.

If that doesn't clear it — and it often doesn't with third-party certs — you need to reinstall the certificate with the correct Enhanced Key Usage (EKU) properties. Here's the command that worked for me on Windows 10 22H2 and Server 2022:

certutil -addstore -f -v my "C:\path\to\certificate.pfx"

But wait — that only works if the PFX already has the right EKU. If it doesn't, you'll need to specify it explicitly. Export the cert from the current store first, then import with the right usage:

certutil -importpfx -p YourPassword -c MY "C:\path\to\cert.pfx"

Still failing? Then the certificate itself has a bad EKU. You can't fix a server cert that's only signed for client authentication — it's a mismatch by design. The provider gave you the wrong cert.

Why This Happens

What's actually happening here is the certificate's Key Usage or Enhanced Key Usage extension doesn't match what the calling application requested. Every certificate has a set of allowed purposes baked into it at creation: code signing, server authentication, client authentication, email protection, etc. When an app like IIS, Outlook, or a browser tries to use the cert for something outside those purposes, Windows throws 0x800B0110.

Think of it like a keycard that only opens door A but you're trying to get into room B. The lock doesn't care if the key is valid — it's the wrong key for that door.

The error code maps to CERT_E_WRONG_USAGE in the Windows SDK header cderr.h. The exact bit pattern is 0x800B0110, which is a subset of the CRYPT_E family. The 0x800B prefix tells you it's a certificate trust issue, and 0110 specifically points to usage.

Less Common Variations

Code Signing on an Email Cert

If you're signing executables and get this error, your cert likely has EKU for 1.3.6.1.5.5.7.3.4 (email protection) but needs 1.3.6.1.5.5.7.3.3 (code signing). This is common when buying from cheap providers who bundle both but only issue one. The fix: generate a CSR specifically for code signing with the right OID.

Server Auth on a Smart Card Cert

Smart card certs typically have EKU 1.3.6.1.4.1.311.20.2.2 (smart card logon) and 1.3.6.1.5.5.7.3.2 (client auth). Using one for HTTPS — which needs 1.3.6.1.5.5.7.3.1 — will trigger 0x800B0110. Don't bother trying to override this; the cert physically can't serve that role.

Certificate Chain with Intermediate CAs

Sometimes the leaf cert is fine but an intermediate CA cert in the chain has restricted usage. Check the full chain with:

certutil -urlcache -split -f http://your-ca-url/cert.crt

Look for any parent certs with Key Usage set to Digital Signature but missing Key Encipherment — that'll break TLS handshakes.

Prevention

You can't fix a cert's EKU after issuance — it's baked into the signed blob. Prevention means checking before you buy or generate.

• Request the right template. On an internal CA, make sure you use the correct certificate template for your use case. Web Server template for IIS, Code Signing for signed executables, User for email and client auth.
• Inspect before installing. Run certutil -v -store my on a new cert and read the Enhanced Key Usage section. It lists all OIDs. Cross-check against Microsoft's EKU list.
• Use the right tool for the job. If you're doing HTTPS, don't accept a cert that only has Client Authentication. Push back on your PKI admin or certificate authority.
• Test with a sandbox. Before deploying to production, import the cert on a test machine and try the operation. This error surfaces instantly.

One last thing: if you're using self-signed certs for development, you can generate them with the right EKU from the start. Use PowerShell:

New-SelfSignedCertificate -DnsName "localhost" -CertStoreLocation "Cert:\LocalMachine\My" -TextExtension "2.5.29.37={text}1.3.6.1.5.5.7.3.1"

This creates a cert with server authentication EKU, avoiding the error before it starts.