CERT_E_ISSUERCHAINING (0X800B0107) fix for certificate chains

When you see this error

You're setting up HTTPS on a Windows server — maybe IIS, maybe a custom app. You import a certificate and try to bind it. Then you get the error: "A parent of a given certificate did not issue that child certificate" with code 0X800B0107. Or maybe you're using certlm.msc and it shows a yellow warning on the cert. This exact thing happens when a CA admin pushes a new root or intermediate, or when you copy a cert from another server without grabbing the whole chain. I've seen it after a failed auto-enrollment too.

Root cause in plain English

The certificate you're using has a parent — an intermediate CA or root CA — that isn't in the trusted store. Or the order in the chain file is wrong. Windows tries to build the chain from the leaf cert up to a trusted root. If it finds a parent that doesn't match the issuer field on the child, it throws this error. The culprit is almost always a missing intermediate certificate. It's not a corrupt cert, it's an incomplete chain.

Another common cause: someone exported the cert without private key and without the full chain. Or they put the root cert in the wrong store. Don't bother checking the cert dates first — that's rarely the problem here.

Step-by-step fix

1. Open the certificate in MMC
   Run certlm.msc (Local Machine) or certmgr.msc (Current User). Find the problematic cert in Personal or Web Server. Double-click it, go to the Certification Path tab. It shows you exactly where the chain breaks — usually a red X on an intermediate or root.
2. Export the full chain in correct order
   If you have the cert as a .pfx or .p7b, double-check it includes all intermediates. Use certutil -dump certname.pfx to list every cert in the file. The order must be: leaf -> intermediate -> root. If it's reversed, you'll get this error. Use openssl pkcs12 -in cert.pfx -nokeys -out chain.pem to extract and reorder manually.
3. Install missing intermediates
   If the chain shows a missing intermediate, get the .crt file from your CA admin or the vendor. Import it into Intermediate Certification Authorities store (local machine). Right-click that store -> All Tasks -> Import. Make sure to select the right store — don't put intermediates in Personal.
4. Rebuild the chain with certutil
   Run this command to force chain rebuild:
   

   certutil -f -p yourpassword -importPFX YourCert.pfx NoChain

   The -f flag forces it. Then run:
   

   certutil -store My

   Look for your cert and verify it shows "No certificate chain". If it does, the import worked but chain is still broken — go back to step 3.
5. Restart the service using the certificate
   After you fix the chain, restart IIS (iisreset) or your custom service. Otherwise Windows caches the old broken chain. If using a .NET app, recycle the app pool.

If it still fails

Check these three things:

• Is the root CA in Trusted Root store? If your CA is internal, the root must be in Trusted Root Certification Authorities (local machine). Missing root = same error.
• Are all certs matching? Look at the Issuer field on the leaf cert. It must match the Subject field on the intermediate. Use certutil -viewstore My to compare.
• Did you import to the wrong user store? If you imported as Current User but the app runs as Local System or NETWORK SERVICE, it won't see those certs. Always use Local Machine store for services.

One more thing — sometimes the chain file has extra whitespace or line breaks. Open it in Notepad++ and make sure it starts with -----BEGIN CERTIFICATE----- and ends clean. Corrupted files trigger this error too. If none of that helps, regenerate the cert from your CA with the correct chain order.