> From: owner-openssl-us...@openssl.org On Behalf Of DarkMike > Sent: Tuesday, 05 July, 2011 03:34
> I have already tried signing and verifying the message and it > works great [with dgst -sign/verify] > Now I want to focus on the certificate verification, > limit it to x509v3, sha1, rsa encryption and command line solution, > with a little bit of bash scripting where needed. > And apparently also only single-level CA, see below. You're making extra work, because 'verify' does your b, probably c, and d/e, and implicitly a because only trusted roots should be configured. But if you really want to: > I am aware that I need to verify: > a) who issued the certificate, > b) if it is still valid, > *c) if not revoked > d) check signature algorithm > *e) verify the signature > f) then extract client public key and use it to verify msg > signatures > > (*) - steps I have not went through yet > > Have I missed any important thing in verification procedure? > For a single-level of CA: get CA(issuing) pubkey (from the CA cert) as you correctly say below. For multiple levels of CA, you have to repeat the whole process at each level up to root. And f isn't part of cert verification, it's an additional step that is the reason you want cert verification. > I have not created any revocation list yet, thus will focus > on (c) at the end, > > For (e): > I have found the following command that do the whole thing > for me in one step: > > openssl verify -CAfile ./demoCA/cacert.pem ./client_cert.pem > > works fine, then I thought that it would also be possible to: > > -extract public key from cacert.pem > -use ca public key to perform the verification > > (v) openssl x509 -in ./demoCA./cacert.pem -pubkey -noout > > ./demoCA/ca_pub_key.pem Yes. > (x!) openssl verify -CAfile ./demoCA/ca_pub_key.pem ./client_cert.pem > No. The 'verify' utility uses only cert format, and checks more than just the signature. To do what you ask above, you need to extract the "TBS" or "body" part of client_cert, and the "signature" part, and use dgst -sha1 -verify like you did for the client data but with the CA pubkey. Do openssl asn1parse -in clicert.pem . If you have "comments" in your cert file, as some openssl commands put there by default and all PEM-read-specific routines allow, remove them first. You can add -i to show the nesting. You should see a SEQUENCE of three things: - a SEQUENCE with several things in it. This is the body/TBS. - a SEQUENCE of an OID for (here) sha1WithRSAEncryption, and NULL - a BIT STRING. This is the signature. Extract the body (including TLV prefix) to a separate file. This starts at the offset in the second line of the parse output (probably always 4) and goes for the "hl" plus "l" in that line. Although not very clearly documented 'asn1parse' can do this: 'openssl asn1parse -in clicert.pem -strparse 4 -out clic.body -noout' Alternatively, convert to der (with x509 -outform der, or base64 -d on a PEM file with no comments) and use dd or maybe perl. Confirm that the signingalgorithm (last-3 to last-1 lines, duplicated as the second element in the body lines 4-6) is sha1WithRSAEncryption (and NULL, since sha1-RSA has no params). Similarly extract the signature to clic.sign; asn1parse is smart enough to adjust to the body of the BIT STRING. For dd use the offset in the last line plus "hl" plus one, and length "l" minus 1 or just go to EOF. (You could instead get the signature by un-hexing x509 -text . But getting the correct DER of the body from -text would be difficult at a minimum and maybe impossible.) Then dgst -sha1 -in clic.body -verify capubkey -signature clic.sign . <snip rest> ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
