How to Clear the Windows Server Active Directory Certificate Services (ADCS) CRL Cache via PowerShell

The Revocation Crisis

In an enterprise Windows Server environment secured by a Public Key Infrastructure (PKI), the Active Directory Certificate Services (ADCS) server acts as the absolute authority. It issues digital certificates to laptops (for 802.1x Wi-Fi authentication), web servers (for HTTPS), and employees (for Smart Card logins).

If an employee’s laptop is stolen, the IT administrator immediately logs into the ADCS server and revokes that laptop’s certificate. The ADCS server instantly adds the certificate’s serial number to a cryptographic blacklist called the Certificate Revocation List (CRL) and publishes that list to an internal web server.

However, Windows clients do not constantly download this massive list every time they authenticate. To save bandwidth and speed up the authentication process, every Windows machine (and server) maintains a local cache of the CRL on its hard drive. If a client downloaded the CRL on Monday, and it is valid until Friday, it will stubbornly refuse to download a fresh copy until Friday.

This creates a catastrophic security vulnerability: The laptop was stolen and the certificate was revoked on Tuesday, but the corporate Wi-Fi Radius server is using a cached CRL from Monday. The Radius server thinks the certificate is still valid and allows the stolen laptop to connect to the corporate network. To force an immediate security update across your infrastructure, you must forcefully clear the local CRL cache on your authentication servers using PowerShell.

Locating the Crypto Caches

The Certificate Revocation List cache is not a simple text file you can delete. It is deeply integrated into the Cryptography API (CAPI) subsystem of the Windows operating system. The physical binary representations of the CRLs are buried within the highly protected AppData\LocalLow\Microsoft\CryptnetUrlCache directories, but they must be manipulated using cryptographic command-line tools.

Purging the Cache via PowerShell

You must perform this operation on the servers that are currently validating the certificates (e.g., your NPS/Radius servers, IIS web servers, or VPN gateways).

Open an elevated PowerShell session as an Administrator.

Step 1: Viewing the Current Cache

Before you destroy the cache, you can ask the certutil engine to dump the current URLs it has cached in memory.

certutil -urlcache CRL

This command will output a massive list of internal HTTP and LDAP URLs where the server previously downloaded Revocation Lists, along with their expiration dates.

Step 2: Forcefully Obliterating the Global Cache

To force the server to forget every single CRL it has ever downloaded, you must execute the delete command. This violently flushes the CryptnetUrlCache directory.

certutil -urlcache * delete

(Note: Using the * wildcard ensures that both CRLs and AIA (Authority Information Access) caches are completely destroyed).

Step 3: Obliterating the System Context Cache

The command above clears the cache for the user currently logged into the server. However, critical background services (like the Network Policy Server / Radius daemon) do not run as your user account; they run under the SYSTEM context.

To flush the cache for the underlying operating system services, you must force certutil to execute the command specifically within the SYSTEM context.

# The -setreg command temporarily forces certutil to act on the machine context
certutil -setreg chain\ChainCacheResyncFiletime @now

This command modifies the Windows Registry. It tells the cryptographic chain building engine: “Any cached CRL older than right now (@now) is mathematically invalid and must be ignored.”

Step 4: Restarting the Cryptographic Services

To ensure all background services immediately recognize the registry change and drop any CRLs they might be holding in active RAM, restart the Cryptographic Services daemon.

Restart-Service -Name CryptSvc -Force

The Security Enforcement

The cache is now completely annihilated. When the stolen laptop attempts to authenticate to the corporate Wi-Fi, the Radius server will intercept the connection and examine the laptop’s certificate. Because its local CRL cache is empty, the Radius server is forced to reach out across the network to the ADCS web server and download a fresh, live copy of the Certificate Revocation List.

It will instantly spot the stolen laptop’s serial number on the freshly downloaded blacklist, violently terminate the TLS handshake, and permanently block the device from the network. By purging the cache, you have closed the vulnerability window from days to milliseconds.

Get the best tech tips delivered straight to your inbox.

Join thousands of readers mastering Apple, Google, Microsoft, and Linux.