> From: owner-openssl-us...@openssl.org On Behalf Of Karthik Ravikanti > Sent: Friday, 21 January, 2011 09:16
> To overcome [snipped], in my get_by_subject lookup method, I'm returning > the certificate whose subject when printed with X509_NAME_print_ex() > matches with the one being asked for. I'm not sure NAME_print_ex matches in exactly the same cases that cert-chain matching does (or should), although for 'normal' cases (no spurious delimiters/tags, no Unicode weirdness like surrogates) it should be OK. FWIW I saw the certs (and key) you posted 2011-01-19 (consistently) have the commonName as UTF8 unnecessarily (actually uses only IA5 and IIRC only Printable). > Before returning however, I'm overwriting the subject and issuer fields > by the queried subject. I know this is stupid, so I'll remove this once I figure > out what's wrong. > However, after this, I got this: [trimmed] > 0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01 > 04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check failed > 0D0C5006:asn1 encoding routines:ASN1_item_verify > 14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed This means the signature didn't verify on one of the certs checked. You could set a breakpoint in the checking logic to see which one. Possibilities: - the cert from the server doesn't have a valid signature by the issuer (CA). Either it was brokenly issued (or forged!) in the first place, or the copy (currently) used by the server has been damaged (perhaps tampered with). - the server cert is signed by a different key than in the CA cert your lookup found. This could be because your lookup is wrong, or it might be there are actually multiple different CA certs/keys with the same name, and issuer-name alone (or hash canon issuer-name alone) doesn't uniquely identify the parent cert when you try to lookup. This latter is a known limitation in OpenSSL's chaining logic. (If a child has AuthKeyID extension, the chaining logic will check it, but if it mismatches can't recover by trying a different parent.) In theory this ambiguity can happen if a CA rolls to a new period with no other change, but perhaps fortuitously in practice CAs change functions and roles (and ownership!) more often than their cert validities (which are usually quite long, like 10-30 years) expire. It may be more likely with a subsidiary or intermediate CA, which could have a shorter period and tend to keep the same role if it survives at all, but I haven't encountered it in the wild yet. - the server cert is correctly signed by the CA cert, but the CA cert you (find and) use is not correctly signed by its own key (selfsigned). If the issuername and/or subjectname you are "overwriting" on lookup differ by even one bit from the values actually in the cert created by the CA (for itself) then the signature fails. I would guess the third is most likely but the second is possible; the first is vanishingly unlikely (and can be checked by grabbing the cert from an s_client run and using commandline verify against a good CA cert). ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
