Fix CERT_E_CRITICAL (0X800B0105) certificate unknown critical extension

When you see this error

You're browsing a secure site — maybe a corporate portal, an old SharePoint site, or a device management console — and your browser throws a big red warning. Or you get it in an application log from a service that can't connect to a remote endpoint. The exact error reads: CERT_E_CRITICAL (0x800B0105). It means Windows Certificate Store found an extension in the server's certificate that it doesn't recognize, and that extension is flagged as "critical."

This is most common with older servers still using certificates issued by a CA that's been deprecated or uses non-standard extensions — I've seen it a lot with internal PKI deployments that use Windows Server 2008 R2 or 2012 CAs. Also happens with certain hardware appliances that generate self-signed certs with oddball OIDs.

What's actually happening

Every X.509 certificate can have custom extensions — things like "private key usage period" or "subject alternative name." The issuer marks some as critical. Microsoft's CryptoAPI (CAPI2) treats critical extensions as mandatory. If it can't parse the extension, it flags the entire certificate as invalid. This is by design. It's a security feature, but it's also a pain when the extension is benign and simply not recognized by older Windows versions.

The real fix depends on where the error appears. If it's from an internal CA, you can update the issuing CA's certificate template. If it's from a vendor-supplied cert, you need to replace it. If it's from an intermediate or root CA that hasn't been updated, install the latest Microsoft root update.

Step-by-step fix

Step 1: Identify the failing certificate

1. Open an elevated command prompt (right-click Command Prompt, select Run as administrator).
2. Type certlm.msc and press Enter. This opens the local machine certificate store.
3. Click on Intermediate Certification Authorities and then Certificates. Look for any certificate with a red X or warning icon.
4. Double-click any suspect cert. Go to the Details tab. Look for Critical extensions. If the field shows Unknown Extension and the value starts with 1.3.6.1... or another OID, that's your culprit.
5. Make a note of the OID value. You'll need it.

Step 2: Update Windows root certificates

1. Open Windows Update and check for updates. Install any updates that include Root Certificate Update (KB931125 for older systems).
2. On Windows 10/11, run this command as admin: certutil -generateSSTFromWU roots.sst. This downloads the latest root cert store from Microsoft.
3. If you're on Server 2012 R2 or older, manually download the root update package from Microsoft's website.
4. After update, restart the computer. Then re-test the connection.

Step 3: Replace the server certificate

If step 2 didn't fix it, the issue is likely a custom extension in the server certificate itself. Here's what to do if you control the server:

1. Log into the server that hosts the site or service throwing the error.
2. Open IIS Manager (or whatever service management console). Locate the SSL binding.
3. Export the current certificate to a .cer file: double-click cert in the store, go to Details, click Copy to File, save it.
4. Open the .cer file in a text editor (it's base64). Look for an Unknown Extension section near the bottom.
5. If you see an extension with an OID like 1.3.6.1.4.1.311.21.10 (Application Policies) or 1.3.6.1.5.5.7.1.24 (private key usage period), those are safe to ignore but Windows may still choke on them if they're marked critical. The fix: request a new certificate from a CA that doesn't include that extension, or use a CA that marks it as non-critical.
6. If the cert is from a public CA (like DigiCert or Let's Encrypt), simply request a new one. Let's Encrypt certs never have this issue.
7. If it's an internal CA certificate, open Certificate Authority MMC, find the issuing CA, right-click it, select Properties, go to the Extensions tab, remove any custom extensions that aren't needed.

Step 4: Force CAPI2 to ignore non-critical extensions (advanced, not recommended)

I'm including this for completeness, but it's a band-aid. You can disable the critical extension check via registry, but it weakens security. Only do this on a test machine.

1. Open Regedit as admin.
2. Go to HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\OID\EncodingType 0\CertDllCreateCertificateChainEngine\Config.
3. Create a DWORD value named EnableCriticalExtensions and set it to 0.
4. Restart the service or computer.

What to check if it still fails

• Check the certificate chain. Open the server certificate, go to Certification Path. If any intermediate or root cert shows the same error, you need to fix those first. They're often the real cause.
• Verify the date. An expired certificate can show this error too, especially if the CA certificate expired and the new one has updated extensions.
• Test with a different client. Try accessing the same site from a Linux machine using curl. If it works fine, the issue is Windows-specific. If it also fails, the cert is genuinely malformed.
• Check the Application event log. Open Event Viewer, go to Windows Logs > Application. Look for CAPI2 events (Event ID 4107 or 4108). Those will tell you exactly which certificate failed and why.
• Update your OS. I've seen Server 2012 R2 and Windows 8.1 machines fail on perfectly valid SHA-256 certificates because they don't support certain newer extensions. Install all available updates.

If none of that works, you're likely dealing with a certificate that has a genuinely invalid extension — not just an unknown one. In that case, contact the CA that issued it. They'll need to re-issue without the bogus extension. Don't waste time trying to force trust on a broken cert.