[ipxe-devel] OCSP issues
Brian Rak
brak at gameservers.com
Thu Nov 20 18:13:57 UTC 2014
Recently we switched over to SHA256 signed SSL certificates, and I've
been having issues with OCSP ever since. It seems that OCSP
verification never completes for our certificate anymore, though it
works fine in browsers (and works according to ssllabs).
I enabled OCSP debugging, and the root of the issue seems to be that the
length of the SHA1 hash and the length of the response don't match.
I added this patch:
diff --git a/src/crypto/ocsp.c b/src/crypto/ocsp.c
old mode 100644
new mode 100755
index d4815a1..7fe30eb
--- a/src/crypto/ocsp.c
+++ b/src/crypto/ocsp.c
@@ -411,8 +411,12 @@ static int ocsp_compare_responder_key_hash ( struct
ocsp_chec
/* Sanity check */
difference = ( sizeof ( digest ) - responder->id.len );
+ DBGC2 ( ocsp, "OCSP %p digest id length: %i responder id
length: %i\n", o
if ( difference )
- return difference;
+ {
+ DBGC2 ( ocsp, "OCSP %p digest id length (%i) and
responder id leng
+ //return difference;
+ }
/* Generate SHA1 hash of certificate's public key */
digest_init ( &sha1_algorithm, ctx );
@@ -421,6 +425,12 @@ static int ocsp_compare_responder_key_hash ( struct
ocsp_chec
cert->subject.public_key.raw_bits.len );
digest_final ( &sha1_algorithm, ctx, digest );
+ DBGC2 ( ocsp, "responder key hash is:\n" );
+ DBGC2_HDA ( ocsp, 0, responder->id.data, responder->id.len );
+
+ DBGC2 ( ocsp, "computed key hash is:\n" );
+ DBGC2_HDA ( ocsp, 0, digest, sizeof(digest) );
+
/* Compare responder ID with SHA1 hash of certificate's public
key */
return memcmp ( digest, responder->id.data, sizeof ( digest ) );
}
Which produces the following output:
<6>ipxe: OCSP 0x29704 digest id length: 20 responder id length: 22
<6>ipxe: OCSP 0x29704 digest id length (20) and responder id length (22)
different!
<6>ipxe: responder key hash is:
<6>ipxe: 00000000 : 04 14 fa 58 db 09 53 bc-19 c5 e7 b5 8b f6 10 f8 :
...X..S.........
<6>ipxe: 00000010 : 1e 84 6d 3a 8f d8 : ..m:..
<6>ipxe: computed key hash is:
<6>ipxe: 00000000 : fa 58 db 09 53 bc 19 c5-e7 b5 8b f6 10 f8 1e 84 :
.X..S...........
<6>ipxe: 00000010 : 6d 3a 8f d8 : m:..
It looks like there's an extra \x04\x14 at the beginning of the
response. Other then that, the computed hash appears to match.
Any idea where this is coming from?
If I just add a dumb offset to this check:
- return memcmp ( digest, responder->id.data, sizeof ( digest ) );
+ return memcmp ( digest, responder->id.data + 2, sizeof ( digest ) );
Verification works correctly (though, obviously this isn't a fix).
Reproducing this is fairly straightforward, just try 'chain
https://api.vultr.com' (that particular url doesn't have a valid iPXE
script, but since the issue happens before that even gets executed that
should be ok)
I'm on IRC as 'devicenull' if you need any further info.
More information about the ipxe-devel
mailing list