certutil ocsp request has a empty issuerKeyHash (is that a legal OCSPRequest according to RFC 2560?)
Hi, We have a small private pki that mostly uses unix (c and java clients) but I was assigned the task to check if it is compatible with the "ms world". Most of the software components are small and selfwritten according to RFC 5280 and RFC 2560 and use standard libraries where possible. As a first step I tried to test our ocsp responder, implemented as a small basic rest service, with the certutil. I tried it with one of our test certificates and got response that it is not valid anymore. Our ocsp responder returned CertStatus unknown but it should be valid. The same certificate file can be validated with openssl against the url specified in the AIA extension. In the log files of our responder i found a statement that he did not find a matching issuer for the passed CertID. Next step was that I looked at the asn1 request which certutil wrote out. The reason was that the issuerKeyHash was set but empty! I thought ok maybe certutil will set it when it has access to the issuing ca certificate, so I built a certificate chain file with the CA certificate and the end entity certificate concatenated and started the certutil again. But I got the same result, issuerKeyHash was still empty. Because we have self-signed and self-issued ca certificates in our chain I am quite curious if it is possible to send a complete OCSP request with certutil? A ocsp request with just the issuerNameHash is fine as long as all your cas only have one keypair and don't have self-issued certificates. I googled a bit but it seems nobody is having the same problems? Is ist possible that in the microsoft environment no self-issued ca certificates are supported?
August 7th, 2012 12:01pm

Thank you, that was the reason, after I installed it worked like a charm. Maybe you know this too, just out of curiosity: Is it a implementation detail of the certutil that it requires the ca certificate to be installed in the local machine store or is that a common requirement if I use the cryptographic api under windows? Or is it possible to just have for example a PKCS12 keystore with the client keypair and the certificate chain up to the root and work with that? Thanks.
Free Windows Admin Tool Kit Click here and download it now
August 8th, 2012 4:34am

as per RFC2560, issuerKeyHash is a hash calculated over issuer's public key. If the issuer certificate is not available, then the code cannot calculate the hash. In a custom implementations you can deal with temporary key stores, but native Windows API uses chain information.My weblog: http://en-us.sysadmins.lv PowerShell PKI Module: http://pspki.codeplex.com Windows PKI reference: on TechNet wiki
August 8th, 2012 8:30am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics