— Kiaasa Dhanori Pune

If an SSL certificate is not showing in the IIS Server Certificates console even though you installed it in the Local Machine store, the usual cause is a missing private key, and you can re-link it with certutil -repairstore. IIS Manager only lists certificates that have an associated private key and are valid for Server Authentication, so a perfectly trusted certificate can still be invisible to inetmgr.

The problem: a valid certificate that IIS refuses to list

You requested a certificate from a Certificate Authority (CA), received the issued .cer file, and imported it into the Local Computer certificate store. You then open IIS Manager, select the server node, and double-click Server Certificates to create the HTTPS binding. The certificate you just installed is nowhere in the list.

This is confusing because the certificate looks healthy in the Certificates MMC snap-in (certlm.msc). It is present, it chains to a trusted root, and the dates are valid. Yet the IIS Server Certificates feature behaves as if it does not exist, so you cannot bind it to your website.

Why IIS Server Certificates hides the certificate

The Server Certificates module does not display every certificate in the machine store. It applies two filters, and a certificate must satisfy both to appear:

1. The certificate must have an associated private key in the Local Machine My (Personal) store.
2. The certificate must be valid for Server Authentication — its Enhanced Key Usage (EKU) must include the OID 1.3.6.1.5.5.7.3.1, or have no EKU restriction at all.

By far the most common reason a certificate is missing from the console is that the private key is not bound to it. SSL relies on a key pair: the public key travels inside the certificate, while the matching private key stays on the server and is what proves ownership during the TLS handshake. Without the private key, the certificate cannot terminate HTTPS, so IIS deliberately omits it.

How the private key gets lost

The orphaned-certificate situation typically happens in one of these ways:

• You imported a .cer / .crt file (which contains only the public certificate) instead of a .pfx / .p12 file that bundles the private key.
• You deleted the pending certificate request in IIS ("Complete Certificate Request" was never matched to its original request), which discards the key material that was waiting to be paired.
• The certificate was generated on one machine and moved to another without exporting the private key.
• The CSR (Certificate Signing Request) was created with an external tool, and the key landed in a different location than where you imported the issued certificate.

Before you fix it: verify the certificate is otherwise valid

Rule out the simple causes first. Open certlm.msc (Local Computer certificates), browse to Personal > Certificates, double-click your certificate, and confirm:

• Validity dates: the current date and time fall between the Valid from and Valid to values.
• Subject / Common Name: the CN (or a Subject Alternative Name) matches the hostname clients will use — for example the CN is www.contoso.com, a bare hostname, not a full URL like https://www.contoso.com/. A CN written as a URL is a common copy-paste mistake.
• Trusted issuer: the certificate chains to a CA in the Trusted Root Certification Authorities store (the Certification Path tab shows no errors).
• Intended purpose: the Details tab lists Server Authentication (1.3.6.1.5.5.7.3.1) under Enhanced Key Usage.

The decisive clue is on the General tab: a healthy certificate shows the line "You have a private key that corresponds to this certificate." If that line is absent, the private key is missing and that is exactly why IIS is hiding it.

The solution: recover the private key with certutil -repairstore

Windows often still has the orphaned private key in its key container from when the CSR was generated — it just lost the link to the certificate. The certutil -repairstore command re-associates the certificate with its key, fixing the visibility problem without re-issuing anything.

Step-by-step

1. Find the certificate's serial number. In certlm.msc, open the certificate, go to the Details tab, and select the Serial number field. Copy the hex value (for example 1a2b3c4d5e6f...). Remove any spaces — the value must be one continuous string of hex digits.
2. Open an elevated command prompt. Right-click Command Prompt or Windows Terminal and choose Run as administrator. The repair touches the machine store, so administrator rights are mandatory.
3. Run the repair. Target the my store (the Personal store of the Local Computer) and pass the serial number:
   1. certutil -repairstore my <serialnumber>
   A real example looks like certutil -repairstore my 1a2b3c4d5e6f7890abcdef1234567890.
4. Watch for success. The command should print the certificate details followed by CertUtil: -repairstore command completed successfully. This means the key pair was found and re-bound.
5. Re-check the General tab. Reopen the certificate in certlm.msc; you should now see "You have a private key that corresponds to this certificate."
6. Refresh IIS. In IIS Manager, click away from and back to the server node, or press F5 inside the Server Certificates view. The certificate now appears and can be bound to your site.

If you maintain the server with PowerShell, you can confirm the fix programmatically. The HasPrivateKey property should report True:

1. Get-ChildItem Cert:\LocalMachine\My | Select-Object Subject, HasPrivateKey, Thumbprint

Targeting the right store

The store name my maps to the Personal store. Because IIS reads the Local Computer account (not your user account), make sure the certificate lives under Certificates (Local Computer) > Personal. The table below maps the friendly names to the certutil store identifiers you will type most often.

If repairstore does not recover the private key

Sometimes certutil -repairstore reports success but the private-key line still does not appear, or it fails because the original key container is genuinely gone. In that case the key cannot be conjured back — you must obtain a copy of it or start over:

• Re-import from a PFX. If you exported the certificate with its private key to a .pfx file (or have one from another server), import that PFX. It restores both the certificate and the key in one step, after which the certificate appears in IIS immediately.
• Re-key the certificate. Generate a fresh CSR on this server (so the private key is created locally), submit it to the CA, and complete the request on the same machine. Most CAs allow a free reissue for the remaining validity period.
• Use the original request machine. If the CSR was generated elsewhere, complete the certificate request on that machine, export to PFX, then import on the web server.

Common pitfalls

• Importing the wrong file type. A .cer or .crt never contains a private key. To move a working certificate between servers, always export and import a .pfx.
• Spaces or wrong case in the serial number. Strip every space from the value the Details tab shows; certutil wants an unbroken hex string.
• Wrong account store. Installing into Current User > Personal instead of Local Computer > Personal hides the certificate from IIS even when the key is present.
• Deleting the pending request. Removing the "pending" certificate request in IIS throws away the private key; never delete it before completing the request with the issued certificate.
• Forgetting elevation. Running certutil -repairstore without administrator rights fails to write to the machine store.
• Missing Server Authentication EKU. A code-signing or client-authentication certificate will be hidden from Server Certificates even with a valid private key, because it lacks the 1.3.6.1.5.5.7.3.1 purpose.

Verification: confirm the SSL binding works end to end

After the certificate reappears and you create the HTTPS binding, verify the whole path rather than trusting the console alone:

1. In IIS Manager, select the site, choose Bindings, add an https binding on port 443, and pick the recovered certificate from the dropdown — it now appears because it has a private key.
2. Browse to https://your-hostname/ and confirm the padlock shows with no certificate warnings.
3. From PowerShell, test the live handshake: Test-NetConnection your-hostname -Port 443 should report TcpTestSucceeded : True.
4. Inspect the served certificate and its key match with certutil -verify -urlfetch against the exported public cert, or view the chain in the browser's certificate viewer.
5. Re-run Get-ChildItem Cert:\LocalMachine\My | Where-Object { $_.HasPrivateKey } and confirm your certificate is listed.

A note on IIS 7 / IIS 8 versus modern Windows

This behavior is identical on IIS 7, IIS 7.5, IIS 8, IIS 8.5, and the current IIS 10 on Windows Server 2016 through 2022 and Windows 11 — the Server Certificates filter and the certutil -repairstore fix have not changed. Note, however, that Windows Server 2008 / 2008 R2 (which shipped IIS 7/7.5) are end of life and no longer receive security updates; if you are still running them, plan a migration to a supported Windows Server release. The procedure here applies unchanged on the supported versions, and on modern systems you can also manage bindings and key recovery entirely from PowerShell with the WebAdministration and PKI modules.

Key Takeaways

• IIS Server Certificates only lists certificates that have a private key and are valid for Server Authentication.
• A certificate missing from the console almost always has an orphaned or missing private key, not a trust or date problem.
• Re-link the key with certutil -repairstore my <serialnumber> from an elevated prompt, using the spaceless serial from the Details tab.
• If repair fails, recover from a .pfx backup or re-key/reissue the certificate so the private key is created locally.
• Always confirm "You have a private key that corresponds to this certificate" and test the live HTTPS binding before declaring success.

Frequently Asked Questions

Why is my SSL certificate not showing in IIS Server Certificates?

Because IIS hides any certificate that lacks an associated private key or is not valid for Server Authentication. Check the General tab in certlm.msc for the private-key line; if it is missing, run certutil -repairstore to re-bind the key.

What does certutil -repairstore actually do?

It re-associates a certificate in the specified store with the matching private key that Windows still holds in its key container, repairing the link that was broken — for example when a pending request was deleted or only the public .cer was imported.

Can I recover a private key that is truly gone?

No. If the key container no longer exists, certutil -repairstore cannot recreate it. Import a .pfx that contains the key, or generate a new CSR on the server and have the CA reissue the certificate.

Where should the certificate be installed for IIS to see it?

In the Local Computer account's Personal store (the my store), not the Current User store. IIS reads the machine store, so a certificate placed under your user account will not appear in Server Certificates.

For more Windows Server and IIS sysadmin walkthroughs, subscribe on YouTube @explorenystream.