CRYPT_E_AUTH_ATTR_MISSING (0x80091006) – The Fixes You Need

Cause #1: The Signing Certificate's Private Key Isn't Accessible

This is the one I see 80% of the time. The error pops up when you try to send a signed email in Outlook, open a signed document, or install a signed driver. The certificate is there, but the private key got nuked or never imported correctly.

I've had this happen after a user reinstalled Office or moved their certificate between machines. The public key travels fine, the private key doesn't. You need the private key to sign anything. Without it, the crypto API throws 0x80091006 because the authenticated attributes — the digital signature's guts — can't be built.

How to fix it

1. Open certmgr.msc (Certificate Manager for the current user).
2. Look under Personal → Certificates for the certificate that's causing the error. It's usually the one used for email signing or code signing.
3. Double-click the certificate. Go to the Details tab. Check the Key Usage field. You should see Digital Signature listed.
4. Now check if you have the private key. In the certificate's General tab, look for the key icon at the bottom. It should say You have a private key that corresponds to this certificate. If it says No private key, that's your problem.

If the private key is missing, you've got two routes:

• Reimport the certificate and key from a .pfx or .p12 file. Double-click the file, check Mark this key as exportable, and store it in the Personal store. Make sure the private key is included — you can verify this when importing.
• Regenerate the certificate if it's self-signed or from an internal CA. In a domain environment, run certreq -new -q on the machine that issued it, then re-import.

I've also seen cases where the private key is there but corrupted. In that case, delete the certificate, import a fresh copy, and test again.

Cause #2: The Root or Intermediate Certificate Is Missing or Untrusted

Another common one. The signing certificate is fine, but the chain of trust is broken. The machine can't verify the signing certificate because it doesn't trust the CA that issued it. This triggers the error when the crypto API tries to validate the authenticated attributes — it hits a dead end in the chain.

Real-world trigger: You get a signed email from someone using a certificate issued by an internal enterprise CA, but your machine doesn't have the root CA's certificate in the Trusted Root Certification Authorities store. Or you're trying to sign a PowerShell script with a code signing cert from a third-party vendor, and the intermediate CA cert wasn't pushed via Group Policy.

How to fix it

1. Open certlm.msc (local machine certificates) or certmgr.msc depending on where the signing certificate lives.
2. Find the signing certificate in Personal → Certificates.
3. Double-click it, go to the Certification Path tab. This shows the chain: root → intermediate(s) → end certificate.
4. Any red X next to a certificate means it's not trusted. For a root, it needs to be in Trusted Root Certification Authorities. For an intermediate, it goes in Intermediate Certification Authorities.

To fix a missing root or intermediate:

• Export the missing certificate from the CA server or a known-good machine. Use certlm.msc → right-click the certificate → All Tasks → Export. Export as .cer (DER encoded).
• Import it on the broken machine. For a root: Trusted Root Certification Authorities → Certificates → right-click → All Tasks → Import. For an intermediate: same but under Intermediate Certification Authorities.
• If it's a domain environment, push the missing certificates via Group Policy. Go to Computer Configuration → Windows Settings → Security Settings → Public Key Policies → Trusted Root Certification Authorities. Saves you a ton of manual work.

I've also seen this fix after a Windows update rolled back a root certificate — the error started after patch Tuesday. Re-importing the root fixed it.

Cause #3: The Signed Message or File Is Corrupted or Modified

Less common but still happens. The error shows when the signed data — email, document, or file — got altered after signing. The crypto API sees the signature, but the authenticated attributes don't match the content. This is a data integrity failure.

Real-world trigger: You save a signed Word document to a network share that does antivirus scanning, and the AV engine modifies the file in transit. Or someone forwards a signed email and the forwarding process strips or changes attributes. I've seen this with Outlook's S/MIME encryption on older Exchange servers.

How to fix it

1. If it's an email: ask the sender to resend the message. If you're the sender, clear the signed email and re-sign it. Don't forward or reply without re-signing.
2. If it's a file: get a fresh copy from the original source. Don't trust the corrupted one — the signature is invalid for a reason.
3. Check if antivirus or file-scanner software is causing the modification. Temporarily disable it and test again. If the error goes away, add the folder or file type to the AV scanner's exclusion list.
4. For documents: open in a text editor to see if there's extra data appended. Some network scanners add headers. If so, get the file from a path that bypasses the scanner.

This fix is straightforward: get a clean copy. If you can't, the data is toast — don't waste time trying to fix a corrupted signature.

Quick-Reference Summary Table

That's it. Start with the private key check — that's your best bet. If that doesn't work, look at the certificate chain. Corrupted data is rare but quick to rule out. You'll have this fixed in ten minutes.