Skip to content

monitor CRL with CRLFreshCheck PowerShell module

In my last post I showed how to use Azure Blob Storage with CDN for PKI Certificate Revocation List’s

Today I will show how to monitor CRL health with Russell Tomkins awsome powershell module CRL Freshness PowerShell.

I have followed Russell’s Guide and added both CDP locations (internal IIS http and external Azure Blob https)

Checking both locations will also indicate if the CRL-Copy job has failed (in my case AzCopy)




Windows Server

PowerShell Module

SMTP relay


  1. Download and extract CRL Freshness PowerShell on the issuing CA or preferably a Windows server for batch operations.
  2. Edit the parameters in CRLFreshChecks.psm1 ($Logfile , $TempFile , $MailFrom , $MailTo , $MailServer
  3. Configure a CSV file containing internal and external CDP locations (crl.csv)
  4. Configure a .ps1 file importing the module and calling the command-lets with import parameter (crl.csv)
  5. Create a scheduled task that calls the powershell .ps1 once everyday


A successful check will look like this in the $Logfile

The following has been copied from Russell’s blog.  If you find this great little tool usefully, please go to his blog and give your appreciation.

What does the cmdlet actually do?

Designed for the monitoring base CRLs via HTTP paths, it allows admins to directly query the status of a CDP and CRL freshness for either a single or batch of CDP’s that are critical for your organisation. It allows for the directory querying of web servers via IP address (whilst preserving the host header) so you can confirm that all web servers have fresh CRL data available no matter which one the load balancer directs clients to.

The primary mechanism for determining if a CRL is expiring is comparing the “Next CRL Publish” extension against the current time.  This extension when present, indicates the next time when a CA intends to publish an updated version of the CRL. The script will flag a CRL as “expiring” if the current time is more than 30 minutes after this time.

Not all CAs will publish this extension into their CRLs. In this scenario, the script will simply default to give warnings at 4 days from the CRL expiration. The cmdlet also has the ability to completely override the warning period with a value of your choosing. This can be useful if as above the “Next CRL Publish” is missing or you only want to receive a warning when the time gets closer to the CRL actually expiring.

Published inITPKIPowershellWindows Azure

Be First to Comment

Leave a Reply

Your email address will not be published. Required fields are marked *