CRYPT_E_INVALID_NUMERIC_STRING (0X80092020) Fix

Cause 1: Extra characters in the serial number or thumbprint

This is the one I see most often. You're copying a certificate's serial number or thumbprint from somewhere — a website, an email, a CSV file — and you paste it into a script or a command. Somewhere in that string, there's a space, a dash, a colon, or even a line break. The Windows CryptoAPI function CryptStringToBinary expects only digits (0-9) and letters A-F for hex. Anything else triggers 0X80092020.

How to check and fix it

Open a PowerShell window and run this. Replace YOUR_STRING_HERE with the actual value you're using.

$badString = "YOUR_STRING_HERE"
Write-Host "Original: [$badString]"
$cleanString = $badString -replace '[^0-9a-fA-F]', ''
Write-Host "Cleaned:  [$cleanString]"

If the cleaned string is shorter or looks different, you had extra garbage. For example, a serial number like 00:AB:12:CD:34:EF needs the colons removed. I've also seen tabs, non-breaking spaces from web copy, and even a stray Unicode character from Outlook.

The real fix: always validate your input before passing it to CertUtil, Import-Certificate, or Add-Type -TypeDefinition with a serial number. I run that cleanup regex every time now.

Cause 2: Misformatted serial number in code or scripts

You're writing a PowerShell script or C# code that passes a serial number to a Windows API. The API expects the string in a specific format — usually raw hex, no spaces, no dashes. If you feed it something like "0x00AB12CD" (which has the 0x prefix), it'll barf. Same if you include leading zeros but in a different arrangement.

Fix it by stripping prefixes and formatting correctly

In PowerShell, make sure you strip any 0x or # prefix. Also remove spaces and dashes. Here's a robust one-liner:

$serial = "0x00AB12CD"
$clean = $serial -replace '^0x' -replace '[^0-9a-fA-F]',''
Write-Host $clean

In C#, the same logic applies. Use Regex.Replace to strip non-hex characters. I once spent an hour tracking this down because the serial had a leading zero that got dropped when someone copy-pasted from a GUI that truncated it. Always pad hex strings to an even number of digits if the API expects it. The System.Security.Cryptography.X509Certificates namespace is picky about this.

Cause 3: Corrupted or malformed certificate file

This one's less common but happens. The certificate file itself (usually .cer or .p7b) has been corrupted during transfer, or it was generated incorrectly. The error pops up when you try to import or read it with CertUtil -decode or Import-Certificate. The base64 content might have extra line breaks, or the binary data got mangled.

Quick check and recovery

First, inspect the file. Open it in Notepad. If it's a base64-encoded certificate, you should see -----BEGIN CERTIFICATE----- at the top and -----END CERTIFICATE----- at the bottom. Look for extra junk — stray characters, double headers, or partial content.

If it's a binary .cer file, the header should be exactly 4 bytes (typically 30 82 or similar). You can use a hex editor or PowerShell:

$bytes = [System.IO.File]::ReadAllBytes("C:\path\to\cert.cer")
Write-Host $bytes[0..3]

If the first four bytes aren't what you expect, the file is likely corrupted. Re-download from the source. Also, watch out for FTP transfers in ASCII mode — that'll muck up binary certs. Force binary mode.

If the file looks clean but still throws the error, try converting it to DER format using OpenSSL. That strips any formatting weirdness.

openssl x509 -in broken.cer -outform DER -out fixed.cer

This rewrites the file with strict DER encoding. I've fixed a handful of stubborn cases this way.

Quick-reference summary table