Posts on this page:

Working with certificate revocation lists (CRL) in PowerShell (part 2)

Hello S-1-1-0!

In previous post we gave an introduction into techniques to work with certificate revocation lists in PowerShell. We explored common steps to read CRL’s basic information, CRL extensions and revoked certificate collection. Today I will discuss about CRL handy shortcuts and signature validation.

Get CRL next publication date and number

In some environments, it is impossible to automatically copy CRLs from CA server to CRL distribution points or there is a scenario when PKI administrators run custom scripts to monitor CRL health status at CRL distribution points and update them if they are about to expire. For such purposes I maintain two shortcut methods to quickly identify required values.

CRL validity is determined by a NextUpdate field. If the current time passes that timestamp, the CRL is considered expired. To provide better validity handling, Microsoft use their own Next CRL Publish CRL extension. This extension contains a date/time value at which CA will issue new CRL. This value (when present) is always set prior to value in NextUpdate field to provide a time window to replicate newly published CRL across all distribution points prior existing CRLs expire. I have a good article on this subject: How ThisUpdate, NextUpdate and NextCRLPublish are calculated (v2). However, Next CRL Publish extension is presented in CRLs issued by Microsoft CAs and is absent in 3rd party CAs, as the result, next CRL publication date is determined solely by Next Update field. Moreover, there might be a case when CA is in the decommission process and issues its last CRL which is supposed to be valid infinitely.

To simplify all these validations, I developed a GetNextPublish method. The logic of this method is as follows:

  1. If Next CRL Publish extension is presented, extension’s value is returned.
  2. If Next CRL Publish extension is absent: a value in the NextUpdate field is returned. If return value is null, the CRL is valid infinitely and no updated are expected.
PS C:\> $crl.GetNextPublish()

otrdiena, 2016. gada 25. oktobri 20:00:00

PS C:\>

For monitoring purposes you may want to compare CRL numbers (they are numbered sequentially) across all CRL distribution points with a base value (for example, retrieved from CA database). This will ensure that there are no stale CRLs especially when CRL was published manually. For such purposes, I maintain a GetCRLNumber method:

PS C:\> $crl.GetCRLNumber()

If the CRL Number extension is absent, then zero value is returned, because such CRLs doesn’t have CRL numbering capabilities. This is the case for Version 1 CRLs, or non-conformant CAs.

Signature Validation

Let’s take a look into our CRL (from DigiCert):

PS C:\> $crl

Version             : 2
Type                : Base CRL
IssuerName          : System.Security.Cryptography.X509Certificates.X500DistinguishedName
Issuer              : CN=DigiCert SHA2 Secure Server CA, O=DigiCert Inc, C=US
ThisUpdate          : 2016.10.18. 20:14:33
NextUpdate          : 2016.10.25. 20:00:00
SignatureAlgorithm  : 1.2.840.113549.1.1.11 (sha256RSA)
Extensions          : { (Authority Key Identifier), (CRL Number), (Issuing Distribution Po
RevokedCertificates : {Serial number: 0c587cfa9bf443daeab70526d4bc009f revoked at: 2015.11.06. 21:57:32, Serial number:
                       0b3ba5097ac6f59b551a1338357a0981 revoked at: 2015.11.09. 11:22:51, Serial number: 0e213e45ff44bd
                      975d6d22cbb8a40f2d revoked at: 2015.11.09. 19:21:01, Serial number: 08d64d9f888feee694b32d06bba9f
                      b83 revoked at: 2015.11.09. 19:22:03...}
RawData             : {48, 131, 4, 111...}
Handle              : 0

PS C:\>

Here we see a SignatureAlgorithm property that stores the information about signature algorithm (captain obvious is here too). This information is used to validate the signature against issuer. Let’s take proper and invalid issuer certificates:

PS C:\> $issuer = New-Object Security.Cryptography.X509Certificates.X509Certificate2 C:\Certs\DigiCertSHA2SecureServerCA
PS C:\> $nonissuer = New-Object Security.Cryptography.X509Certificates.X509Certificate2 C:\Certs\verisign.cer
PS C:\> $issuer

Thumbprint                                Subject
----------                                -------
1FB86B1168EC743154062E8C9CC5B171A4B7CCB4  CN=DigiCert SHA2 Secure Server CA, O=DigiCert Inc, C=US

PS C:\> $nonissuer

Thumbprint                                Subject
----------                                -------
A5EC73D48C34FCBEF1005AEB85843524BBFAB727  OU=Class 2 Public Primary Certification Authority, O="VeriSign, Inc.", C=US

PS C:\>

And try to use both certificates to validate signature:

PS C:\> $crl.VerifySignature($issuer,$true)
PS C:\> $crl.VerifySignature($nonissuer,$true)
PS C:\>

We can observe that DigiCert is the issuer of this CRL, while VeriSign is not. Plain and simple. VerifySignature method accepts two arguments: an instance of X509Certificate2 class and boolean value that indicates whether to perform CRL issuer name validation along with raw signature validation. In this case, SubjectName field of the issuer (or candidate at that point) is compared with IssuerName property of the CRL. Moreover, binary comparison is performed. This was made to be compatible with RFC3280 (although, obsolete, but still in use) which requires binary match. RFC5280 allows case-insensitive string match.

When using CRLs in your code to validate revocation status, do not forget to validate CRL signature as this will make your code more reliable and trustworthy.

Currently, VerifySignature supports RSA, DSA and ECDSA signatures. Alternate signature algorithms (RSASSA-PSS) are not yet supported, but I do have plans to add support of alternate signature formats.

Interoperability with CryptoAPI

In the past, I used CryptoAPI native functions (through p/invoke) to decode CRL objects. Since I have a reliable and very robust ASN.1 parser, I moved CRL decoder to a fully managed .NET code without using a piece of unmanaged code. As the result, normally you don’t need to dispose CRL object in order to release unmanaged resources and prevent memory leaks. However, there might be a need to get an unmanaged reference to CRL object. For such purposes I maintain a Handle property that contains a reference to a CRL object in unmanaged memory. Normally, it is zero:

PS C:\> $crl.Handle

If you need an unmanaged reference, call GetSafeContext method. This method will copy CRL object into unmanaged memory and retrieve a pointer to that memory block:

PS C:\> $crl.GetSafeContext()

                                                  IsInvalid                                                    IsClosed
                                                  ---------                                                    --------
                                                      False                                                       False

PS C:\> $crl.Handle

Now, you can use this handle to pass into unmanaged functions. For example, into CertAddCRLContextToStore function to add CRL into Windows Certificate Store. When CRL handle is populated, it must be freed after you finish working with CRL object by calling ReleaseContext method:

PS C:\> $crl.ReleaseContext()
PS C:\> $crl.Handle
PS C:\>

The difference between ReleaseContext and Reset methods is simple: ReleaseContext releases only unmanaged resources, while keeping managed object alive. If there are no unmanaged resources associated with the current object, the method does nothing (no errors are thrown). Reset method releases unmanaged resources (if necessary) and clears managed object by clearing all fields and setting them to default null/empty values.

That’s all for today. In next post, I’ll talk about CRL generation in PowerShell, so stay tuned!

Working with certificate revocation lists (CRL) in PowerShell (part 1)

Hello everyone!

Today I would like to summarize techniques on working with X.509 certificate revocation lists (CRL) in PowerShell. There are a lot of examples in my weblog, but most of this information is provided as context-specific addition to work in a given article’s context. Before talking about the subject, I’d like to put few words about the reason of this blog post and why it is written in that way.


As PowerShell evolves, it starts to cover more and new areas. And this process continues since PowerShell birth (in 2006). Systems administrators become more critical to script functionality. Previously, if something was not doable at all, we skipped that thing. With PowerShell we are able to do much more things. Maybe, not natively, maybe not in an elegant manner (say, through complex parsing), maybe very ugly, but we can do that right now. If community is interested in some area, they will develop a framework to make things easier and available to everyone.

One big area I’m interesting in is public key infrastructure, CryptoAPI, certificates and everything related to them. This happened several years ago (I recall it was in 2009) when I already was a passionate PowerShell enthusiast. Unfortunately, I realized that PowerShell has very-very basic support of certificate-related stuff. Mostly, this is due to poor support from underlying .NET platform. As the result, I attempted to start my big project to integrate cryptography into PowerShell through PS module and standalone scripts. Apparently, I was one of the first PS enthusiasts who started cryptography integration into PowerShell. I made huge work during these 7 years, went through tons of mistakes, bad choices, misunderstandings, trials and probes. It took 7 years and still continues. As of now, I have developed one of the best PowerShell module to work with PKI I’m aware of: PowerShell PKI. It is not just a module, it is a whole framework, which offers additional functionality through .NET-style objects and methods you can call from PS console. All this makes me confident in PowerShell PKI area.

Read more →

How to convert PEM to PFX in PowerShell (revisited)

Hello everyone!

Some time ago I wrote a script that converts PEM file to CryptoAPI compatible format: How to convert PEM file to a CryptoAPI compatible format. The script involves some non-PowerShell commands (certutil) which associates private key with a certificate instance. I received several feedback comments about avoiding certutil in favor of native PowerShell/.NET managed code. In this post I want to show some code that eliminates certutil from the script.

Just to recall what we generally do when converting PEM to X509Certificate2/PFX:

  • Read the certificate information from PEM file and instantiate a X509Certificate2 object;
  • Read PKCS#1 or PKCS#8 private key;
  • Convert PKCS#1/PKCS#9 private key to CryptoAPI PRIVATEKEYBLOB;
  • Associate PRIVATEKYEBLOB with an X509Certificate2 instance.

Read more →

Reading multiple signatures from signed file with PowerShell

Hello S-1-1-0, it’s time for another blog post. Another PowerShell and CryptoAPI blog post.

Identifying the problem

Recently I had a trivial (or non-trivial?) challenge: read multiple signatures from signed files. Usually files have only one signature:


Read more →

Manage pending certificate requests in ADCS with PowerShell

I think, I have to publish several articles that would cover common PKI/ADCS administration tasks with PowerShell by using my PowerShell PKI module (of course!). Today I'll cover very simple, but very common task: managing pending certificate requests.

In this post we would propose the following scenario:

  • IIS admin requested certificate for internal SharePoint portal
  • Certificate template is configured to require CA manager approval to issue the certificate.
  • No certificate will be issued until CA manager review and approve the request.

Just to make it clear, CA manager approval is configured in the certificate template, as follows:

you, as CA manager, received notification about incoming certificate request. Your task is to review the certificate request to ensure that it is properly constructed and conforms internal security policies and then make decision: approve or deny certificate request. You can do this by using Certification Authority MMC snap-in, but this would require a lot of clicks and without having a chance to automate this. Another solution that includes PowerShell offers you great automation capabilites.

Read more →