Hello S-1-1-0 again, I'm back!
In the first part we discovered basic OCSP requests and responses. Today's stories:
- Nonce
- Service Locator
Nonce
By default, Online Responder may pre-cache OCSP response for particular certificate, especially if the certificate is used very frequently (for example, SSL certificate at login.live.com) until it (response) is expired. This reduces server load, because there is no need to sign the same response for each incoming request. And this behavior is recommended by RFC5019. Here is an example for StartSSL/StartCom SSL certificate:
PS C:\> $Cert = (Test-WebServerSSL www.startssl.com).Certificate PS C:\> $cert Thumbprint Subject ---------- ------- C37CB1A4AB0FC7702E31F72DDD781B8FEAE0F085 OID.1.3.6.1.4.1.311.60.2.1.3=IL, OID.2.5.4.15=Private Organization, SERIAL... PS C:\> $Request = New-Object pki.ocsp.ocsprequest $cert PS C:\> $Response = $Request.SendRequest() PS C:\> $Response.ProducedAt svetdiena, 2012. gada 19. augusta 23:43:47 PS C:\> Get-Date otrdiena, 2012. gada 21. augusta 19:05:42 PS C:\>
Look at this example. The response was originally signed at 19th august, while today is 21st. This means that server returned cached response.
On the other side, RFC2560 allows clients to send a special request that includes Nonce extension. When Online Responder sees Nonce extension in the OCSP request, responder MUST reject all cached responses for the certificate, perform revocation checking against revocation providers and send new response. Nonce extension is a sequence of arbitrary data (whatever you want) and responder SHOULD return the same extension value as specified in the request.
RFC5019 allows responders to not include Nonce extension in the response if it is not coinfigured to support this extension:
In the case where a responder does not have the ability to respond to an OCSP request containing a option not supported by the server, it SHOULD return the most complete response it can. For example, in the case where a responder only supports pre-produced responses and does not have the ability to respond to an OCSP request containing a nonce, it SHOULD return a response that does not include a nonce.
Windows Online Responder does not support Nonce extension by default and will return "Unauthorized" status in the response. This behavior is not fully conformant with mentioned RFC. But you can enable Nonce support in the revocation configuration properties. Windows clients do not use Nonce too.
Certain commercial responders (VeriSign/Symantec or Thawte) does not support Nonce extension and always return cached response that does not include a Nonce (hence, this behavior is conformant with RFC5019). But there are responders that supports Nonce by default.
As for Nonce extension value I decided to use Ticks property of the DateTime class which is passed as a simple OCTET STRING ASN.1 type. This guarantees, that two OCSP requests will have different extension values. In order to enable Nonce extension, we will use another constructor for OCSPRequest class: OCSPRequest(X509Certificate2, Boolean):
PS C:\> $Request = New-Object pki.ocsp.ocsprequest $cert,$true
PS C:\> $Request
Version : 1
Nonce : True
NonceValue : 04 12 36 33 34 38 31 31 37 34 30 38 38 39 32 33 30 32 35 34
Extensions : {1.3.6.1.5.5.7.48.1.2 ()}
URL : http://ocsp.startssl.com/sub/class4/server/ca
RequestList : {System.Security.Cryptography.X509Certificates.X500DistinguishedName}
RawData : {48, 106, 48, 104...}
PS C:\>
You see that Extensions property contains one extension with OID = 1.3.6.1.5.5.7.48.1.2 (id-pkix-ocsp-nonce) and we see some data in the NonceValue property. If we send such request, the ProducedAt property in the response will be updated to current time:
PS C:\> $Response = $Request.SendRequest()
PS C:\> $Response
Version : 1
ResponseType : id_pkix_ocsp_basic
ResponseStatus : Successful
ProducedAt : 2012.08.21. 19:46:53
NonceReceived : True
NonceValue : 04 12 36 33 34 38 31 31 37 34 30 38 38 39 32 33 30 32 35 34
ResponderKeyId :
ResponderNameId : System.Security.Cryptography.X509Certificates.X500DistinguishedName
Request : PKI.OCSP.OCSPRequest
SignerCertificates : {[Subject]
CN=StartCom Class 4 Server OCSP Signer, O=StartCom Ltd. (Start Commercial Limited), C=IL
[Issuer]
CN=StartCom Extended Validation Server CA, OU=StartCom Certification Authority, O=StartCom
Ltd., C=IL
[Serial Number]
0623
[Not Before]
2012.07.22. 20:01:44
[Not After]
2012.09.01. 22:41:54
[Thumbprint]
66EDC5E64FD37BC9F710D55B17EC6AA6EF655805
}
Responses : {PKI.OCSP.CertID}
ResponseExtensions : {1.3.6.1.5.5.7.48.1.2 ()}
HttpHeaders : {Connection, Proxy-Connection, Content-Transfer-Encoding, Content-Length...}
SignerCertificateIsValid : False
SignatureIsValid : True
ChainErrorInformation :
ResponseErrorInformation : {MissingOCSPRevNoCheck}
SignatureAlgorithm : 1.2.840.113549.1.1.5 (sha1RSA)
RawData : {48, 130, 6, 96...}
PS C:\> Get-Date
otrdiena, 2012. gada 21. augusta 19:49:34
PS C:\>
Now we see that the response is not cached and returned nonce value in the request matches nonce value in the response. Additionally we see that Online Responder at StartSSL/StartCom is not fully conformant with RFC2560 §4.2.2.2.1, because delegated signing certificate does not include id-pkix-ocsp-nocheck extension and do not provide revocation checking options.
OCSPResponse Class contains a DisplaySigningCertificateUI() method which displays signing certificates in a familiar UI dialog.
As the last note, Nonce extension should not be used on a regular basis and should be used only when application requires it. And application must be ready to receive a response without nonce as expected.
Service Locator
Consider the following scenario: you have a isolated network with limited or no internet connection. However, particular application must perform revocation checking for commercial certificate. In this scenario, revocation checking may fail due to limited internet connection. RFC2560 supports this scenario by implementing Service Locator OCSP extension — 1.3.6.1.5.5.7.48.1.7 (id-pkix-ocsp-service-locator).
How it works? Imagine you have a specially configured Online Responder that acts as a proxy server. Client sends OCSP request to this proxy server. Initial request contains target certificate's Authority Information Access extension and Issuer field — all as a part of the Service Locator extension. Proxy server uses this information to locate an authoritative OCSP server and sends request to the server. When OCSP response is received by a proxy, the response is resigned by proxy server and returned to the client.
Nor Windows OCSP, nor Windows client supports service locator extension, because this scenario is required only in specific cases. But OCSP Client tool shipped with my PowerShell PKI module can check whether your Online Responder proxy is configured correctly. The following constructor may be used: OCSPRequest(X509Certificate2, Uri, Boolean, Boolean). With this constructor you must specify OCSP proxy URL address as the second parameter. The last parameter specifies whether you want to use service locator extension. As a test proxy you can use http://ocsp.globaltrustfinder.com which is owned by Ascertia:
PS C:\> $Cert = (Test-WebServerSSL login.live.com).Certificate
PS C:\> $Request = New-Object pki.ocsp.ocsprequest $cert,"http://ocsp.globaltrustfinder.com",$false,$true
PS C:\> $Request
Version : 1
Nonce : False
NonceValue :
Extensions : {}
URL : http://ocsp.globaltrustfinder.com/
RequestList : {System.Security.Cryptography.X509Certificates.X500DistinguishedName}
RawData : {48, 130, 1, 163...}
PS C:\>
Note: there is a bug in PSPKI v2.0. Service Locator extension is included in the encoded raw data, but do not appear in Extensions property.
PS C:\> $Response = $Request.SendRequest()
PS C:\> $Response
Version : 1
ResponseType : id_pkix_ocsp_basic
ResponseStatus : Successful
ProducedAt : 2012.08.21. 22:24:00
NonceReceived : False
NonceValue :
ResponderKeyId :
ResponderNameId : System.Security.Cryptography.X509Certificates.X500DistinguishedName
Request : PKI.OCSP.OCSPRequest
SignerCertificates : {[Subject]
CN=GlobalTrustFinder OCSP Service_nocheck
[Issuer]
CN=Ascertia Root CA 2, O=Ascertia, C=GB
[Serial Number]
0120
[Not Before]
2012.05.17. 15:18:21
[Not After]
2028.12.21. 14:15:33
[Thumbprint]
6900E0E33FB99003558E687713080B6D8BACA34D
, [Subject]
CN=Ascertia Root CA 2, O=Ascertia, C=GB
[Issuer]
CN=Ascertia Root CA 2, O=Ascertia, C=GB
[Serial Number]
00E5
[Not Before]
2009.04.17. 16:22:35
[Not After]
2029.03.15. 14:59:59
[Thumbprint]
7624BD1349F4E6A189A2EB5A8E9FA8AE62CE62DE
}
Responses : {PKI.OCSP.CertID}
ResponseExtensions : {}
HttpHeaders : {Connection, Proxy-Connection, Content-Length, Content-Type...}
SignerCertificateIsValid : False
SignatureIsValid : True
ChainErrorInformation : {PartialChain}
ResponseErrorInformation : {}
SignatureAlgorithm : 1.2.840.113549.1.1.5 (sha1RSA)
RawData : {48, 130, 12, 127...}
PS C:\> $Response.Responses
CertId : PKI.OCSP.CertID
CertStatus : Good
ThisUpdate : 2012.08.16. 12:00:13
NextUpdate : 2012.08.23. 12:00:13
Extensions : {}
RevocationInfo :
PS C:\>
Here we see that original request was sent to OCSP proxy and it returned re-signed non-authoritative response. Proxy takes only Responses property from authoritative response and signs it with it's own OCSP signing certificate. This non-authoritative response is fully compliant with RFC2560 and should be trusted by the client application (though, clients must trust Ascertia's root CA certificate).
Summary
Even though, Nonce and Service Locator extensions are not widely used in the Internet PKI, it may be useful to support them for specific scenarios. And it is more important to have a tool that helps you to test whether your OCSP servers are configured correctly and responds as expected. Have a fun with PowerShell PKI module!
Post your comment:
Comments: