Re: Got X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY when there was a root in the store.
Dave, Sorry for a late reply, but I was able to zero in on the real problem. I was converting X509 objects to DER and that to Apple's SecCertificateRef. In the lookup method I was again getting DER from SecCertificateRef and an X509 from it. Strangely, both the objects have the same printed subject name, but differ in the encoded form. So I'm now just avoiding the conversion to SecCertificateRef for good. Just storing DER data (and converting directly back to X509) serves my purpose well. Thanks, Karthik On Tue, Jan 25, 2011 at 7:45 AM, Dave Thompson dthomp...@prinpay.comwrote: 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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Got X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY when there was a root in the store.
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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Got X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY when there was a root in the store.
Can anybody help me with this? On Wed, Jan 19, 2011 at 10:42 AM, Karthik Ravikanti karthik.ravika...@gmail.com wrote: I created a self signed certificate and used it to sign a server's certificate. I put root in the client's store, using a custom X509_LOOKUP, overriding the get_by_subject() method. I see that I'm indeed returning the correct certificate in the return object from get_by_subject() and also a return value of X509_LU_X509. I also compared the issuer name of the server certificate and the subject name of the root certificate by printing then using X509_NAME_print_ex(). But what seems to be failing is X509_NAME_cmp(). I saw that the canon_enclen's of the root and server were different by 12 bytes. To be clear, I'm getting the server certificate (which the server loads from a PEM file) during the SSL handshake, while the root certificate was loaded from a DER file. I'm also attaching the certificates in question. The password for the Server.pem file is 'particle'. Any clues?
Re: Got X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY when there was a root in the store.
To overcome this, 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. 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: *2694546820:error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01:rsa_pk1.c:100:* *2694546820:error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check failed:rsa_eay.c:699:* *2694546820:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:184:* *2694546820:error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed:s3_clnt.c:1059:* * * * * On Fri, Jan 21, 2011 at 3:50 PM, Karthik Ravikanti karthik.ravika...@gmail.com wrote: Can anybody help me with this? On Wed, Jan 19, 2011 at 10:42 AM, Karthik Ravikanti karthik.ravika...@gmail.com wrote: I created a self signed certificate and used it to sign a server's certificate. I put root in the client's store, using a custom X509_LOOKUP, overriding the get_by_subject() method. I see that I'm indeed returning the correct certificate in the return object from get_by_subject() and also a return value of X509_LU_X509. I also compared the issuer name of the server certificate and the subject name of the root certificate by printing then using X509_NAME_print_ex(). But what seems to be failing is X509_NAME_cmp(). I saw that the canon_enclen's of the root and server were different by 12 bytes. To be clear, I'm getting the server certificate (which the server loads from a PEM file) during the SSL handshake, while the root certificate was loaded from a DER file. I'm also attaching the certificates in question. The password for the Server.pem file is 'particle'. Any clues?
Got X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY when there was a root in the store.
I created a self signed certificate and used it to sign a server's certificate. I put root in the client's store, using a custom X509_LOOKUP, overriding the get_by_subject() method. I see that I'm indeed returning the correct certificate in the return object from get_by_subject() and also a return value of X509_LU_X509. I also compared the issuer name of the server certificate and the subject name of the root certificate by printing then using X509_NAME_print_ex(). But what seems to be failing is X509_NAME_cmp(). I saw that the canon_enclen's of the root and server were different by 12 bytes. To be clear, I'm getting the server certificate (which the server loads from a PEM file) during the SSL handshake, while the root certificate was loaded from a DER file. I'm also attaching the certificates in question. The password for the Server.pem file is 'particle'. Any clues? ServerRoot.pem Description: Binary data Server.der Description: Binary data Server.pem Description: Binary data ServerRoot.der Description: Binary data
