How to Remove Certificates from Windows

Certificates pile up in Windows. A test certificate from a project that ended, a corporate root left behind by software you uninstalled, an expired certificate on a web server, a client certificate that no longer authenticates anything. Removing them is straightforward once you know two things: which of the several certificate stores it is actually sitting in, and whether you want it deleted or merely distrusted.

Those are different operations, and confusing them is the usual reason a certificate “will not go away”. Everything below applies to Windows 11 and to Windows 10, whose support ended on 14 October 2025. The certificate tools have not changed between them.

Delete or disable: not the same thing

Two operations get described interchangeably as “removing” a certificate, and they behave differently.

• Deleting takes the certificate out of the store. If it had a private key, that key goes too, and it is gone unless you exported it first. This is what you want for your own certificates: an expired web server certificate, a test certificate, a client certificate you no longer use.
• Disabling leaves the certificate in place and turns off what it is trusted for. Windows keeps the entry and stops honouring it. This is the safer choice for a certification authority certificate, because it is reversible with two clicks and because it survives in a form you can inspect later.

Guides commonly present the disable procedure under a “how to remove” heading, which leaves people convinced they deleted something that is still sitting in the store. If your goal was to free a slot, clean up after a project, or destroy a private key, disabling does not do it.

Back it up before you touch it

Deleting is not undoable, and a certificate you thought was unused often turns out to be authenticating something quietly. Export first. It costs thirty seconds.

1. Right-click the certificate, choose All Tasks, then Export.
2. If the certificate has a private key and you may need it back, choose Yes, export the private key, which produces a .pfx file protected by a password you set. Otherwise take the default and export the certificate alone as a .cer file.
3. Save it somewhere outside the machine you are cleaning up.

If Yes, export the private key is greyed out, the key was marked non-exportable when it was installed and cannot be recovered. That is worth knowing before you delete the certificate, not after.

Find the certificate first

This is where most of the wasted time goes. Windows keeps certificates in more than one place, and the same certificate can exist in several of them at once. Delete it from one and it still works, because another copy is doing the job.

User store or computer store

There are two separate hierarchies. Open them directly rather than assembling an MMC console by hand:

certlm.msc

opens Certificates – Local Computer, which applies to every user on the machine and to services such as IIS. It requires administrator rights.

certmgr.msc

opens Certificates – Current User, which applies only to your account. Client certificates, S/MIME email certificates and anything you installed by double-clicking a file usually land here.

Both consoles are part of Windows, so nothing needs installing. They replace the whole sequence of opening MMC, adding the Certificates snap-in, choosing an account type and picking the local computer. If a certificate seems to survive deletion, check the other console before doing anything drastic.

Which folder

• Personal holds certificates issued to you or to this machine, and it is where a web server certificate, a client certificate or an S/MIME certificate lives. This is the folder most people actually need.
• Trusted Root Certification Authorities holds the root certificates the machine trusts, both the public ones and any your organisation added.
• Intermediate Certification Authorities holds the middle of the chain, and stale entries here are a common cause of odd validation behaviour.
• Third-Party Root Certification Authorities holds roots that did not come from Microsoft’s own program. On a typical machine it is far emptier than people expect, which is why a guide that sends you straight here often leaves you staring at a list that does not contain your certificate.
• Untrusted Certificates is the distrust list. Nothing here is trusted, by definition. Microsoft’s term for the equivalent list it distributes is the untrusted certificate trust list, describing certificates “publicly known to be fraudulent”.

If you do not know which folder to look in, search by thumbprint or subject from PowerShell instead, which covers every store in one pass. See the PowerShell section below.

Delete a certificate

With Certificate Manager

1. Run certlm.msc or certmgr.msc, depending on which hierarchy the certificate is in.
2. Expand the folder holding it, then select Certificates beneath it.
3. Confirm you have the right one. Double-click it and check the Details tab for the thumbprint, or at least check the Issued To, Issued By and Expiration Date columns. Several certificates can share a friendly name.
4. Export it, as described above.
5. Right-click it and choose Delete, or select it and press the Delete key. Confirm the warning.

With PowerShell

Faster when you do not know where the certificate is. Run PowerShell as Administrator to reach the machine stores. Find it first:

Get-ChildItem -Path Cert:\LocalMachine -Recurse |
    Where-Object { $_.Subject -like "*contoso*" } |
    Format-List PSParentPath, Subject, Thumbprint, NotAfter

PSParentPath in the output tells you exactly which store each hit is in, which answers the “which folder” question without guessing. Swap LocalMachine for CurrentUser to search your own hierarchy.

Then delete by thumbprint, which is unambiguous in a way that a subject name is not:

Remove-Item -Path Cert:\LocalMachine\My\THUMBPRINTHERE

Store names on the Cert: drive are the internal ones rather than the display names: My is Personal, Root is Trusted Root Certification Authorities, CA is Intermediate Certification Authorities, and Disallowed is Untrusted Certificates.

With certutil

Useful in scripts and on machines where you are working from a command prompt. List a store, then delete by thumbprint:

certutil -store Root
certutil -delstore Root THUMBPRINTHERE

Mind the default, because it is the opposite of what people assume: Microsoft documents that “the -user option accesses a user store instead of a machine store”, so certutil works on the machine store unless you say otherwise. To act on your own account’s certificates:

certutil -user -store My
certutil -user -delstore My THUMBPRINTHERE

The identifier can also be a serial number or the certificate’s index number in the listing, though the thumbprint is the one that cannot be mistaken for another certificate.

Distrust a certificate without deleting it

For a certification authority certificate, this is usually the better move. It is reversible, it leaves an audit trail, and it does not fight with the mechanism Windows uses to maintain its own trust list.

1. Right-click the certificate and choose Properties.
2. On the General tab, under Certificate purposes, select Disable all purposes for this certificate.
3. Click Apply, then OK. To narrow rather than kill it, Enable only the following purposes lets you leave, say, email trust on while turning server authentication off.

The other supported route is to move the certificate into the Untrusted Certificates store, which is the same store Microsoft populates with its own distrust list. Both approaches survive the daily trust list refresh described below, which a plain deletion is not designed to.

What you should not delete

Deleting the wrong root is not a cosmetic mistake. Windows validates far more than web pages against these stores: Windows Update, driver installation, activation, code signature checks, and any application that speaks TLS. Removing a root that Microsoft’s own services chain to can leave a machine unable to update itself, which is a much harder problem than the one you were solving.

It also helps to know that your local store is not a static list. Windows maintains trust through certificate trust lists that, in Microsoft’s words, it “downloads the CTLs from the Internet via an automatic mechanism called the CTL Updater”, refreshed daily from ctldl.windowsupdate.com by default. Microsoft notes that this automatic update “can be disabled if necessary, however it isn’t recommended”. So a deletion is a local edit against a list the system actively maintains, which is the practical reason to prefer disabling or the Untrusted Certificates store when your goal is to stop trusting a public root.

Safe to remove, generally: certificates you or your organisation created, expired certificates in Personal, test and development certificates, and roots installed by software you have uninstalled. Leave alone anything issued by Microsoft, anything your IT department deployed, and anything you cannot identify.

After you delete it

The store change is immediate. There is no restart step, and the advice to “restart your server” that circulates with this procedure is not part of it. What can mislead you is caching further up: an application already running may hold a validation result, so close and reopen the browser before concluding nothing happened.

One more reason a site may keep loading after you removed its root: Chrome and Firefox each maintain their own list of trusted root certificates in addition to the Windows store. Removing a publicly trusted root from Windows therefore does not necessarily change what those browsers accept. Test the specific browser you care about rather than assuming the Windows store is the only thing being consulted.

Confirm the certificate is actually gone by listing the store again:

Get-ChildItem -Path Cert:\LocalMachine -Recurse |
    Where-Object { $_.Thumbprint -eq "THUMBPRINTHERE" }

No output means no copy remains anywhere in the machine hierarchy. Run it again against Cert:\CurrentUser to be sure a user-level copy is not still in play.

Frequently Asked Questions

If you are removing a certificate because something is failing rather than as housekeeping, our guides to common SSL errors are the better starting point, and our explainer on root and intermediate certificates covers how the chain fits together.