MSSIPOTF_E_CRYPT (0X80097014): CryptoAPI call failed
A signed file's digital signature can't be verified because a CryptoAPI function call failed. Usually a corrupted signature block or missing root certificate.
Quick answer for advanced users: The file's embedded signature block is corrupted or the chain validation hit a missing root/intermediate CA. Re-sign the file with a proper timestamp, or reinstall the missing root certificate in the Trusted Root store.
Context — what's actually happening here
You're hitting 0X80097014 (MSSIPOTF_E_CRYPT) when Windows tries to verify a digital signature — usually on a driver, a system file, or an installer. The error code means a call to a CryptoAPI function failed. It doesn't tell you which function, just that something broke inside the cryptographic library during signature processing.
What's actually happening here is the file's SignedData structure (a PKCS#7 blob embedded in the PE file) is malformed or missing critical fields. The CryptoAPI call might fail because:
- The signature counter-signature (used for timestamping) is truncated or uses an unsupported algorithm.
- A certificate in the chain points to an issuer that's not in the local store — especially the Timestamp CA's root.
- The file was signed with SHA-1 and the system has disabled SHA-1 for signatures (common on Windows 10 1903+).
- An Authenticode-signed file was altered after signing, breaking the hash.
You'll see this most often when installing printer drivers from smaller OEMs that didn't include all intermediate certificates, or after applying a Windows security update that tightened signature validation.
Fix steps
- Check the file's signature with SignTool. Open an elevated Command Prompt and run:
- Check timestamp signature separately. Add
/ts <timestamp-url>or just look at the output for the timestamp counter-signature. If the timestamp verification fails with 0X80097014, the timestamping certificate is likely missing or expired. - Install missing root certificates. Open
certlm.msc(local machine store). Go to Trusted Root Certification Authorities → Certificates. Find the CA that issued the file's signing certificate (the issuer name shows in SignTool output). If it's missing, download and import it from the CA's official site. - Re-sign the file. If you have the original signing certificate (PVK/SPC or PFX), re-sign with a valid timestamp server:
- Remove the digital signature and re-apply it. If you can't re-sign, use
FileDelete.exefrom the Windows Driver Kit to strip the signature first, then re-apply. Not ideal, but works when the signature block is just corrupt.
signtool verify /pa /v "C:\path\to\your\file.dll"
The /pa flag tells it to use the Authenticode verification policy (not the kernel-mode one). Look for the line Signing Certificate — if it says Certificate chain failed or Error: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider, you've found the cause.
signtool sign /f mycert.pfx /p password /fd sha256 /tr http://timestamp.digicert.com /td sha256 "file.dll"
The /tr flag specifies the RFC 3161 timestamp server — use this instead of the old /t flag. Reason: old timestamp servers often fail on modern Windows.
Alternative fixes if the main one fails
- Disable Secure Boot verification (temporary). For kernel-mode drivers only: boot into Recovery mode and run
bcdedit /set testsigning on. This skips signature checks — don't leave it on after testing. - Restore the file from a known-good source. If you got the file from a vendor's website, re-download. Corrupted downloads happen more often than you'd think — especially over flaky HTTPS connections that don't verify content.
- Install the Windows Update KB that fixes SHA-1 signing. On Windows 10 1903+, SHA-1 signed files are blocked by default. KB4524244 (or later cumulative updates) may add exceptions. Check your Windows version first.
- Use a third-party tool like
asn1parse(from OpenSSL) to dump the signature block and look for truncated fields. If the sequence length doesn't match, the file was corrupted after signing.
Prevention tip
Always sign your files with SHA-256 and use an RFC 3161 timestamp server (like http://timestamp.digicert.com). The old timestamp protocol (PKIX with /t) uses a weaker chain that often breaks on newer Windows. Also, include the full certificate chain in the signature — pass the intermediate CA files to signtool sign /ac. This avoids the missing-root trap entirely.
If you're a developer distributing a signed file, test it on a clean Windows VM with no extra certificates installed. If it fails 0X80097014 there, it'll fail on your customers' machines too.
Was this solution helpful?