Hello folks, PowerShell Crypto Guy is again on the board! Today I want to talk about a useful OCSP Client Tool which is available in my PowerShell PKI module.

A long time ago in a galaxy far, far away....

A time ago I started Online Responder deployment and was faced the problem that there are no good tools to test it's configuration and how it works. PKIView.msc and certutil.exe just can tell whether the OCSP is functional or not. No details about request and/or response details. After a little research I found pretty useful and nice tool called Ascertia OCSP Client Tool. Actually this is a great tool with a lot of powerful features, including raw ASN.1 traces and so on. I thought that it is worth to buy the tool and contacted their sellers. Holy ****, the price killed me. They asked about 1,800 (1.8k) euros for a single license! Even though the tool is very cool, I wasn't ready to spend such money for it. But, if you manage Lorne Greene or Johnny Cash, then Ascertia's product may be for you.

After additional internet search, I didn't found other similar products at all. Not talking about lower prices. This was a unfortunate fact for me and I started to think in another way — learn Abstract Syntax Notation (ASN.1), Distinguished Encoding Rules and so on. This way wasn't easy too, because ASN is not something you can learn in few days (even basics). At first, I got a great book ASN.1 — Communication Between Heterogeneous Systems written by Olivier Dubuisson and ASN.1 Editor. I can't tell that the book is too good for beginners, but there are no too much options. Eventually, I made first steps in the crazy ASN.1 world and got first results. Since there are no too much .NET-like classes to work with ASN structures, I wrote my own basic parser which is exposed by ASN1 class. After that I just opened RFC2560 and looked to ASN.1 module which can be found at the document end (entire RFC is worth to read for PKI administrators). Step by step and I created several classes which represent underlying ASN structures. For example, RFC defines CertID structure that identifies client certificate to be verified and similar object exist in my library: CertID class. You can found similar mappings for other structures, like OCSPSingleRequest, OCSPSingleRequestCollection and so on. Everything related to OCSP client profile is placed under PKI.OCSP namespace.

Getting started

Due to some reasons, I couldn't to decide how to implement this stuff as a PowerShell cmdlets, therefore I leave this as a number of .NET classes which can be used in PowerShell or your own projects. Generally you will deal with OCSPRequest Class which will do everything you need. At first we will look at class constructors: OCSPRequest Constructor. There are a lot of constructors that use various OCSP request settings. In this post we will explore only basic constructor: OCSPRequest(X509Certificate2). We just instantiate OCSP request by using an X509Certificate2 object to be verified. Let's try it with a SSL certificate used by login.live.com website:

PS C:\> ipmo pspki
PS C:\> $Cert = (Test-WebServerSSL login.live.com).Certificate
PS C:\> $cert

Thumbprint                                Subject
----------                                -------
F48729C10EAB495CC21CEF59C1DE1B1A6EF9C058  CN=login.live.com, OU=Passport, O=Microsoft Corporation, STREET=One Micros...


PS C:\>

I'm using Test-WebServerSSL command from my module to get a SSL certificate from web server. Now we instantiate OCSPRequest object:

PS C:\> $Request = New-Object pki.ocsp.ocsprequest $cert
PS C:\> $Request


Version     : 1
Nonce       : False
NonceValue  :
Extensions  : {}
URL         : http://evsecure-ocsp.verisign.com/
RequestList : {System.Security.Cryptography.X509Certificates.X500DistinguishedName}
RawData     : {48, 81, 48, 79...}



PS C:\> $Request.RequestList

CertId                                  Extensions                              CertificateName
------                                  ----------                              ---------------
PKI.OCSP.CertID                         {}                                      System.Security.Cryptography.X509Cer...


PS C:\> $Request.RequestList[0].CertId | fl *


HashingAlgorithm : 1.3.14.3.2.26 (sha1)
IssuerNameId     : 45A7D4D407751A5FBDED1E191D4A8DEC52D24155
IssuerKeyId      : FC8A50BA9EB9255A7B55854F9500638FE9586B43
SerialNumber     : 029AEE645495B81DE15A1ABBCB60D6C0



PS C:\>

The code automatically retrieves OCSP URLs (if they are listed in the Authority Information Access extension). In the RequestList property we see a collection of request items, where each element represents a certificate to be verified and optional extensions (we will talk about them in next posts). This means that you can put multiple certificates into a single OCSP request. Inner CertId represents actual certificate. The only information we need to identify the certificate — serial number, issuer name hash and issuer public key hash. Now we are ready to submit the request by using SendRequest method. Method has no parameters:

PS C:\> $Response = $Request.SendRequest()
PS C:\> $Response


Version                  : 1
ResponseType             : id_pkix_ocsp_basic
ResponseStatus           : Successful
ProducedAt               : 2012.08.11. 17:36:41
NonceReceived            : False
NonceValue               :
ResponderKeyId           :
ResponderNameId          : System.Security.Cryptography.X509Certificates.X500DistinguishedName
Request                  : PKI.OCSP.OCSPRequest
SignerCertificates       : {[Subject]
                             CN=VeriSign Class 3 Extended Validation SSL OCSP Responder, OU=Terms of use at https://www
                           .verisign.com/rpa (c)06, OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US

                           [Issuer]
                             CN=VeriSign Class 3 Extended Validation SSL CA, OU=Terms of use at https://www.verisign.co
                           m/rpa (c)06, OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US

                           [Serial Number]
                             3BA789454D2121FB254A17F55C12E1C8

                           [Not Before]
                             2012.05.22. 3:00:00

                           [Not After]
                             2012.08.21. 2:59:59

                           [Thumbprint]
                             FB8C8AC27E323AC8D7E458A05FB2F2712C3429D9
                           }
Responses                : {PKI.OCSP.CertID}
ResponseExtensions       : {}
HttpHeaders              : {Connection, Proxy-Connection, content-transfer-encoding, nncoection...}
SignerCertificateIsValid : True
SignatureIsValid         : True
ChainErrorInformation    :
ResponseErrorInformation : {}
SignatureAlgorithm       : 1.2.840.113549.1.1.5 (sha1RSA)
RawData                  : {48, 130, 6, 187...}



PS C:\>

A returned response object (OCSPResponse) has a lot of useful properties:

• Version — RFC2560 defines only one version which is 1.
• ResponseType — identifies response type. Most online responders use basic responses.
• ResponseStatus — this property identifies whether the OCSP request was correctly formed. This property doesn't tell anything about certificate status.
• ProducedAt — gets the time when the response was produced. This time may not match with current time, because Online Responder can pre-cache (if there were previous requests against the certificate in the subject) and return cached response.
• ResponderNameId — RFC2560 specifies two options how Online Responder can identify itself — by name ID (issuer subject) or key ID (subject issuer's public key hash). In our case, VeriSign OCSP identifies itself by name. Windows OCSP identifies itself by key ID. Key ID is recommended, because Windows CA supports CA certificate renewals with different keys, while the issuer name remains the same. Here is an excerpt from a such responder identification:

Version                  : 1
ResponseType             : id_pkix_ocsp_basic
ResponseStatus           : Successful
ProducedAt               : 2012.08.12. 21:52:06
NonceReceived            : False
NonceValue               :
ResponderKeyId           : 45A828CD3252C02A081640F5127E799985827B29
ResponderNameId          :
Request                  : PKI.OCSP.OCSPRequest

• Request — contains original request object. Nothing special.
• SignerCertificates — returns a list of certificates that was used to sign OCSP response. Many Online Responders include only leaf certificate (OCSP signing certificate). Online Responder may be configured in a way to put signing certificate and entire (or partial) certificate chain.
• Responses — contains a collection of certificate status objects. This property contains information about requested certificate revocation status:

PS C:\> $Response.Responses


CertId         : PKI.OCSP.CertID
CertStatus     : Good
ThisUpdate     : 2012.08.11. 17:36:41
NextUpdate     : 2012.08.18. 17:36:41
Extensions     : {}
RevocationInfo :



PS C:\>

CertId property must be the same as CertId property in the original request. CertStatus identifies the status of the certificate. In our case, the certificate is not revoked. ThisUpdate and NextUpdate properties identifies the response validity. During this timespan, we can trust this information. If the certificate is revoked, then we will see the following information:

PS C:\> $Response3.Responses


CertId         : PKI.OCSP.CertID
CertStatus     : Revoked
ThisUpdate     : 2012.08.12. 19:10:24
NextUpdate     : 2012.08.13. 12:30:24
Extensions     : {}
RevocationInfo : Serial number: 40D897F4000000000109 revoked at: 2012.03.26. 21:17:00



PS C:\>

• SignerCertificateIsValid — identifies whether the signing certificate is valid and is intended to sign OCSP responses.
• SignatureIsValid — identifies whether the signature is valid.

There are other properties and you can get details about them here: OCSPResponse Properties.

I think, this is enough for the first time. In the next post I'll continue with advanced topics about OCSP client. Again, if you want to test this tool, you can download it here: http://pspki.codeplex.com/