Some days ago I received an odd complain that some of the Root CAs we use had the wrong Subject Key Identifier (SKI). I knew that the claim was false but I also knew that I'll have to prove it. The guy did dig on our own specifications and calculated the SKI as we required, the hash of the certificate public key but unfortunately the identifiers did not match.
In order to reproduce the problem I extracted the public key of the Root CA, converted to DER, hashed it with SHA1 and verified that indeed the hash did not match. Let’s do a demonstration of what I did with a public available Root CA:
Now let's calculate the SHA1 of the public key:
As reported, both hashes did not match!
At this point I was a bit confused and decided to read some documentation before moving forward. After some reading I found the answer in the 188.8.131.52 section of the the RFC3280 “Internet X.509 Public Key Infrastructure - Certificate and Certificate Revocation List (CRL) Profile ” (http://www.ietf.org/rfc/rfc3280.txt)
In our case we use method 1) for the SKI but in my calculations I was taking into consideration the whole public key, including tag, length, etc, while I should have used the key bits only.
With the following command I was able to locate the “BIT STRING” with the naked key:
And I only need to extract it and put it on a file in DER format:
The remaining part was to calculate the SHA1 hash which was the same as the SKI:
The same method was used to verify the SKI of a Root CA using SHA256 as a hashing algorithm.
memcpy (and friends) with NULL pointers
2 months ago