Try our new Certificate Revocation List Check Tool
CRLcheck.exe is a tool developed to verify digital signatures of executable files. It collects files from known paths on your client, checks their signature, and checks Certificate Revocation Lists (CRL) and OCSP download. This helps avoid delays in launching files.

CRLcheck.exe Certificate Revocation List Check Tool to automatic verify CRL and OCSP internet reachability of all your EXE files that your client runs.



Over the past 20 years, I have personally witnessed how Certificate Revocation on Windows systems is often underestimated, even within large enterprises. This issue significantly affects both client and server systems if not managed correctly. It can manifest in various ways, from start-up delays of applications to failed upgrades on servers, to inexplicable occurrences that happen sporadically. Worst of all, these issues can be challenging to reproduce consistently. Problems like these often persist for weeks when left unaddressed. By the time somebody delves into the problem in detail, the issue may have disappeared, only to resurface days later.

 Windows famous Blue circle of wait


In numerous instances, workplaces experienced start up delays, with security software like Antivirus wrongly accused of causing these delays.

This is how this happens and we have seen several times from SBS to enterprise:

  1. Developers use digital signatures to make their software more secure, primarily to pass all scans (since signed software is deemed safe by Virustotal).
  2. IT security integrates proxies or web filters to enhance company security. They aim to inspect everything except browser traffic at the edge, ensuring they are aware of all activities and direct update attempts.
  3. The end user and then the workplace engineer report delays in application startup or migration.
  4. The workplace analyst wrongly accuses the client security team (EDR/AV solution).
  5. The client security team hard-excludes directories or processes from any security scans using filenames and/or MD5/SHA checksums.
  6. In many cases, it turns out to be just a digitally signed Microsoft Windows executable or DLL, with Windows attempting to access the mentioned CRL (Certificate Revocation List) from the Internet. Due to Internet routing through a proxy, the URL is blocked, causing the issue.

That’s all?

They just reduced parts of the security by 10% because someone missed a part and they wanted to make things safer and also more performant.


Moreover, during OS deployments such as Windows 7, 10, and 11, we have encountered several large-scale deployments gone awry due to delays in driver installations, particularly for storage or NIC drivers, leading to clients being unable to reach the Certificate Revocation List (CRL) Fully Qualified Domain Name (FQDN) through the WAN.

Those involved in patching server systems, such as Windows Server or Exchange Server, often observe varying patching times or overall slowness. These issues may be directly linked to the endpoint’s inability to reach specific Certificate Revocation lists on the internet.

While there are command-line tools like certutil.exe available to analyse these problems, we found that they were not sufficient for our needs. Consequently, we made the decision to develop our own tool to address these challenges effectively.

What crlcheck.exe does?

  • Find all EXE files in a common directory, processes running as users, or a directory specified by the user
  • Check if the executable is digitally signed and has CRL + OCSP listed
  • Verify if it can download the CRL + OCSP from the Internet
  • Export all .CER and .CRL files, along with decrypted information found in each CRL list
  • Check the cached CRL + OSCP your client often uses and do the same

What crlcheck.exe generates at the end / What is the Target:

You have a list of FQDN Fully qualified Domain Names that your endpoint references regarding digital signing and you can hand over the list to your Security or
networkengineer to verify those URL and make sure they are opn on firewall.

CRLcheck.exe is a tool designed to collect executables (*.exe) from well-known paths on your client.

It checks whether they are digitally signed with a certificate and then retrieves the Certificate Revocation Lists (CRL) and OCSP for each signed file it finds.

It then verifies if the client can successfully request and download that file from the Internet.

 What we talk about shown in a certificate itself:



Why is it essential to check CRL and why this should work?

  1. Security reason
  2. Performance reason

For software suppliers, it is a best practice to code-sign their executables with commercial certificates. If those certificates are compromised or stolen, the operating system provides an option to check for such incidents through the Certificate Revocation List (CRL) over HTTP (Port 80).

Because it is not possible to recall a certificate, the certificate revocation list details certificates signed by valid CA that should no longer be trusted. Certificates may be revoked for many reasons, such as if the certificate was issued erroneously or if the private key of a valid certificate has been compromised.

This process functions only when the client is connected to the internet and, in an enterprise setting, is not behind a proxy or firewall that blocks these requests.

If you have an isolated environment with no internet access, you may even need to supply those CRL files on an internal web server so that some software works flawlessly.


Why this is important in Enterprise or where you have Proxy and Web filters

Often, browser traffic is directed to a Web Security Proxy, while the client (system) traffic goes through another route, potentially being blocked. In such cases, the CRL process may lead to significant delays when starting an executable. In most Windows systems, you will observe a blue circle beside the mouse pointer and the application you just initiated when this delay occurs.

 Windows famous Blue circle of wait


Please see sample from the field at end of this post for Microsoft Server, Fortinet Forticlient, Citrix, Exchange etc.


This does NOT affect me because we have a category on our firewall with all the CRL+OCSP in a realtime list:

Yes, but that list is not always ajour/uptodate. We had a case where it affected OS deployment with INTEL drivers for storage.

Why this happens

Firewall, Proxy, or security engineers sometimes overlook or may not be aware of this process, resulting in potential performance issues on client machines. They isolate clients in VLANs or behind a Proxy and forget about the Certificate Revocation List (CRL) process. The controlled traffic is routed to the proxy, but some applications or drivers hit the WAN gateway directly and are blocked. This is good and wanted, but some traffic must be allowed. It is critical that in such cases, people know which CRL/OCSP address an application that is signed uses. This tool will help you find those addresses.

Why this is always and issue which lands at security engineer’s desk instead of PKI-engineer which does certificates?

When encountering performance issues, it is common for IT professionals to mistakenly attribute blame to security tools like Antivirus. However, in many cases, these allegations are misdirected.

Modern security solutions, including Antivirus and Intrusion Prevention Systems (IPS), rigorously inspect certificates to assess file risk. This comprehensive examination often triggers multiple Certificate Revocation List (CRL) and Online Certificate Status Protocol (OCSP) lookups.

Consider the scenario of launching an application such as myapp.exe. In this situation, a sophisticated AV solution not only scrutinizes the application’s code signature but also investigates auxiliary files like DLLs and other executables, along with their associated chains. This meticulous process can initiate a series of CRL lookups, inadvertently causing delays during application start up or even resulting in application hang-ups.

Through our experiences, we have observed that security endpoints are frequently accused of causing performance slowdowns, when in reality; the root cause often lies in the resource-intensive nature of Certificate Revocation checking. Disabling or uninstalling the antivirus may appear to resolve the issue, but it merely halts the CRL lookup process, leading to inaccurate attribution of the problem.

Furthermore, disabling a third party Antivirus or shutting it down often results in a fallback to Windows Defender. This transition, however, does not necessarily resolve the underlying issue, as both Windows Defender and the third-party AV solution may cease certificate checking operations, falsely indicating that the problem has been resolved.


The tool running:


CRLcheck.exe does:

 * Search for EXE files on your client

* Checks their code-signing certificates

* Search for the Certificate Revocation List used

* Check if you can download the CRL

* Validate the certificate chain

* Check certificate and CRL expiration

* Export a list of all information as a file

* Crosscheck if you are using revoked certs

If you run this tool in enterprise it may generate Security/false-positive:

We have tested the release with Enterprise AV Trellix ENS 10.X and the latest DEFS, sandboxes (FortiSandbox and Trellix ATD), and on Virus Total. This tool utilizes the existing Microsoft CERTUTIL.exe and X509 API from Windows for various operations. Please note that SIEM/EDR solutions (for example, Rapid7) MAY trigger a false positive alert if you have Certificate handling alerts enabled.



* Check MTU sizes per NIC

* Change MTU size

* Check web speed

* Check Proxy settings





Built for min. Microsoft .NET Framework


Checksum SHA-256
















 Crlcheck.exe should run on foollwing os and endpoints:

C# .NET 4.8 included in following OS out of the box

You can install Microsoft .NET 4.8 on following OS

Windows 10 version 1903 (May 2019 Update) and later versions

Windows 10 version 1709 (Fall Creators Update) and later versions

Windows Server 2019

Windows Server 2016

Windows 8.1

Windows Server 2012 R2

Windows 7 Service Pack 1 (SP1)

Windows Server 2008 R2 SP1

Windows Server 2019

 File information:


Security AV check done for file crlcheck.exe

I spent half of my life with endpoint security products and Threat Sandboxing. Mainly those two RED flags in virustotal are based on the fact that our own EXE code is not digital signed 😉

The files has been verified in ATD/TIS Trellix Sandboxes and also on Fortisandbox.



3 of 72 this may be related to a) We connect to at starting to check WAN access and also the nature of the tool handling certificates and using certutil.exe. One is a chinese supplier (BKFAVpro) the other two never heard of (Cybereason and SecurAge). Mainly because the crlcheck.exe itself is not signed at the moment.












Checked with Enterprise AV-solution Mcafee/Trellix ENS and AMCORE 6700.10107 from 23.03.2023 12:53PM

 Download version from

Check on TIS/ATD Sandbox of file “7c215e15dd2f007bb0cbf86598122798” crlcheck.exe


Do further search or open found CRL or CER files in Windows tools

Check the cache of the user like with certutil -urlcache

Checking if your client can reach the found CRL + OCSP URL’s


In this sample, it was an old Adobe Elements software, which is out of support:

Automatic decrypt / decode CRL raw files into readable textfiles:

Check if your client uses REVOKED certificates which would be a security concern

Easy browse through certificates information of executables on your client

Generates CSV/SSV exports for your security/firewall/proxy teams

You can also investigate another common source of network problems, such as the Maximum Transmission Unit (MTU)/Maximum Segment Size (MSS) size in your network or Proxy settings and conduct a download speed test.


Check MTU size per interface

Check PROXY settings, which is also relevant for CRL checks:

Because MS tries to explain:


Sample usage cases from the daily field:


Sample case Fortinet Forticlient VPN fail,
stuck at 40% percent Status

 Forticlient VPN reaches 40% and is unable to connect when a user blocks CRL on private firewall. Fortinet does what other should they warn the user if that happens. Sadly this happens in the background of the VPN client (hidden) and you

Endless try to find out the reason.


With crlcheck.exe of the client you would have seen that the VPN client in that environment is unable to read the request OCSP adress from



Sample case Fortinet Fortigate enterprise environment


Customer 1000+ enterprise had sporadic delay on all kind of applications. Whenever external for the applications analysed the issue it was non-present just to come back.

The effect was discovered after the network team migrated to a newer Fortigate model and integrated an internal firewall between different VLANs, implementing a serial hook-up and a McAfee Web Gateway cluster behind the Fortigate Web/IPS filter.

Had the person in charge had our tool at hand, this issue may have been avoided. The main focus of the network team was on directing attention towards the client management team and client security team. They even considered replacing the AV solution.

The team relied heavily on built-in service/protocol lists from Fortigate, which, at that time, did not include all the necessary Certificate Revocation List (CRL) and Online Certificate Status Protocol (OCSP) addresses.

This oversight was based on too much trust to built-in groups on Fortinet, which were expected to cover those Fully Qualified Domain Names (FQDNs).

Service list built in and updated realtime by FortiGuard


We solved this with making our own rules:

Sample from Fortigate for other Certs they missed:

F-SBID( –name “Root.Certificate.URL_Custom”; –protocol tcp; –app_cat 17; –service HTTP; –flow from_client; –pcre “/(crl\.microsoft\.com|\.omniroot\.com|\.verisign\.com|\.symcb\.com|\.symcd\.com|\.verisign\.ne t|\.geotrust\.com|\.entrust\.net|\.public- trust\.com|\.globalsign\.|\.digicert\.com|crl\.startcom\.|crl\.cnnic\.cn|crl\.identrust\.com|crl\.thaw te\.com|crlsl\.wosign\.com|www\.d\-trust\.net)/”; –context host; –weight 15; )

In our case:

F-SBID( –name “”; –protocol tcp; –app_cat 17; –service HTTP; — flow from_client; –pcre “/(pki\.infineon\.com)/”; –context host; –weight 15; )

 You can see also the same effect here:


Sample case Microsoft Windows Server

The server is unable to reach a certain OCSP FQDN because heavy isolated. Connection fails from or to a another endpoint via TLS.

There is an effect on the CA 2022 itself that has nothing to do with this.


Sample Microsoft Exchange Server

On one of my favorite Exchange blogs i used the last 10 years 😉

From Paul Cunningham blog

The Microsoft Exchange Team blog posted about an issue people are experiencing in the field in which certificate revocation status check failures prevent you from assigning a certificate to any Exchange services.

If Exchange can’t access the CRL, the certificate status is returned as RevocationCheckFailure by the shell. In EMC this is displayed as The certificate status could not be determined because the revocation check failed.

When a certificate fails a revocation check due to any of the above reasons, the EMC prevents you from assigning the certificate to any Exchange service. Note, this does not impact certificates that have already been assigned to Exchange services. The services will continue to function.

– Source

Two of the causes of this are listed as:

# Network or proxy misconfiguration, or a firewall rule preventing Internet access

# Intentional blocking of Internet connectivity from the server


Sample case Citrix

ICA launch delay issue after upgrading to Workspace app 2203 CU2 (

After upgrading to Workspace app 2203 CU2, customer may experience ICA launch delay issues

Problem Cause

From Workspace app version 2203 CU2, cryptnet.dll will be loaded for checking Certificate Revocation List.

If CryptoAPI is NOT able to access any internet CRL server due to customer network security requirements,

it will take more time for CRL checking. It leads delayed launch of wfica32.exe


Sample case Microsoft M365 Intunes

People think with M365 and Intunes Autopilot all problems would be easy? Well kind of until you run into a problem with CRL and want to do an Update of a driver via Intunes.


Sample case Ivanti, modern workplace, Workspace control

Installation (,

  • On computers without Internet access, the CRL validation may cause a delay of, for example, 20-30 seconds before an installation starts. This is by design of Microsoft Windows. To avoid this delay to occur, make sure machines can connect to the Internet. If this is not possible, implement a (manual/automatic) distribution system to keep the publisher’s certificate revocation lists up to date.