Adding Root Certificates to for verification of certificates using libxmlsecurity
Hi , I want to verify a particular certificate stored in an xml ,against a self signed root certificate using openssl. For this, am using libxmlsecurity [ internally has openssl ] for parsing my signature.xml having a certificate . 1. For adding Root Certifiates to *keystore *am using * xmlSecOpenSSLAppKeysMngrCertLoad()* of libxmlsecurity which calls openssl apis to do so . 2. To verify this signature file against a Root Certificate[self signed] i use libxmlsecurity which internally calls *X509_verify_cert* of openSSL. Problem: Signature passes successfully for the first time but fails if i send the verification request again. *X509_verify_cert* returns 0 and the Error Code*XMLSEC_ERRORS_R_CRYPTO_FAILED * is printed. NOTE: Each time I send a verification request I add the Root certificates to keys Store. *Error logs :* : ERROR/(244): Optional Transform node is present : ERROR/(244): xptrExpr = 0x2c97d8 : ERROR/(244): ERROR CODE: 7, ERROR MSG: *certificate signature failure *: ERROR/(244): ERROR: external/libxmlsecurity/android/../src/openssl/x509vfy.c[359] : ERROR/(244): ERROR CODE: 7, ERROR MSG:* certificate signature failure *: ERROR/(244): ERROR: external/libxmlsecurity/android/../src/openssl/x509vfy.c[408] : ERROR/(244): ERROR: external/libxmlsecurity/android/../src/openssl/x509.c[1714] : ERROR/(244): ERROR: external/libxmlsecurity/android/../src/keys.c[1364] : ERROR/(244): ERROR: external/libxmlsecurity/android/../src/xmldsig.c[1034] : ERROR/(244): ERROR: external/libxmlsecurity/android/../src/xmldsig.c[726] : ERROR/(244): ERROR: external/libxmlsecurity/android/../src/xmldsig.c[526] I am not able to understand why for the first time the verification is success but the second it fails with above error code. Any suggestions for the above problem will be helpful. Regards, Mayur
X509 Certificates problem
Hi, I am using VxWorks 5.5 EAP supplicant. I know it's old, but that's the reality. This supplicant is a part of certain HW that authenticates with AAA server using EAP-TTLS. Now, everything works fine when i am using X509 certificates that were generated in openssl 0.9.7e (it's also old, but that's the legacy). But, when i use certificates that were generated in openssl 0.9.8r or even 0.9.8l, the supplicant sends bad certificate error and fails the transaction. Did anybody run into something like that? Is it really related to the openssl versions? I compare them and they are pretty much the same... Quick help will be appreciated. Thanks -- View this message in context: http://old.nabble.com/X509-Certificates-problem-tp32185451p32185451.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
verify and the authority and issuer serial number mismatch error
I have a chain that fails to verify: brs% openssl verify -verbose -issuer_checks -CAfile serversTA.pem -untrusted 'servers-users.pem' dua.pem dua.pem: CN = config, CN = DSA Manager error 29 at 0 depth lookup:subject issuer mismatch CN = config, CN = DSA Manager error 31 at 0 depth lookup:authority and issuer serial number mismatch CN = config, CN = DSA Manager error 29 at 0 depth lookup:subject issuer mismatch CN = config, CN = DSA Manager error 29 at 0 depth lookup:subject issuer mismatch CN = config, CN = DSA Manager error 29 at 0 depth lookup:subject issuer mismatch CN = config, CN = DSA Manager error 20 at 0 depth lookup:unable to get local issuer certificate I think that's because dua.pem contains an AKID that does not match 'servers-users.pem' (it contains keyID, issuer and serial number). That's true but it's deliberate: servers-users.pem is a cross certificate (issued by serversTA.pem). The key matches (servers-users.pem has a public key that's the same as the public key of the actual issuer of dua.pem). Isn't OpenSSL just wrong in doing this? X.509 (2008) says Certification authorities shall assign certificate serial numbers such that every (issuer, certificate serial number) pair uniquely identifies a single certificate. The keyIdentifier form can be used to select CA certificates during path construction. The authorityCertIssuer, authoritySerialNumber pair can only be used to provide preference to one certificate over others during path construction. Isn't OpenSSL's use of authoritySerialNumber to reject the certificate technically incorrect (according to X.509, though I don't see anything in RFC 5280 permitting it either)? Presumably it's ordinarily harmless: OpenSSL's default config doesn't set authorityCertIssuer, authoritySerialNumber in AKID, and ordinarily everything would match up fine anyway. So to find a problem you'd need a setup with this not recommended AKID and cross certificates. So, lucky me! Presumably there's no test of this in PKITS? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
verify and the authority and issuer serial number mismatch error
I have a chain that fails to verify: brs% openssl verify -verbose -issuer_checks -CAfile serversTA.pem -untrusted 'servers-users.pem' dua.pem dua.pem: CN = config, CN = DSA Manager error 29 at 0 depth lookup:subject issuer mismatch CN = config, CN = DSA Manager error 31 at 0 depth lookup:authority and issuer serial number mismatch CN = config, CN = DSA Manager error 29 at 0 depth lookup:subject issuer mismatch CN = config, CN = DSA Manager error 29 at 0 depth lookup:subject issuer mismatch CN = config, CN = DSA Manager error 29 at 0 depth lookup:subject issuer mismatch CN = config, CN = DSA Manager error 20 at 0 depth lookup:unable to get local issuer certificate I think that's because dua.pem contains an AKID that does not match 'servers-users.pem' (it contains keyID, issuer and serial number). That's true but it's deliberate: servers-users.pem is a cross certificate (issued by serversTA.pem). The key matches (servers-users.pem has a public key that's the same as the public key of the actual issuer of dua.pem). Isn't OpenSSL just wrong in doing this? X.509 (2008) says Certification authorities shall assign certificate serial numbers such that every (issuer, certificate serial number) pair uniquely identifies a single certificate. The keyIdentifier form can be used to select CA certificates during path construction. The authorityCertIssuer, authoritySerialNumber pair can only be used to provide preference to one certificate over others during path construction. Isn't OpenSSL's use of authoritySerialNumber to reject the certificate technically incorrect (according to X.509, though I don't see anything in RFC 5280 permitting it either)? Presumably it's ordinarily harmless: OpenSSL's default config doesn't set authorityCertIssuer, authoritySerialNumber in AKID, and ordinarily everything would match up fine anyway. So to find a problem you'd need a setup with this not recommended AKID and cross certificates. So, lucky me! Presumably there's no test of this in PKITS? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Please help: OpenSSL + OpenVPN Elliptic Curves (SHA512, ECDSA, ECDH, Linux, Debian)
On 07/20/2011 12:45 PM, Gaglia wrote: ... Feedbacks always appreciated, in case somebody has further investigated the issue :) __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
DSA Java (Sign Message) C OpenSSL (Verify Signature)
Command Line: OpenSSL generate DSA public and private keys using the command line interface (PEM Files) OpenSSL command line interface convert to DER format for Java Code: Load them into Java using PCKS#8 Reader Classes -Sign a Message (Use Java String.getbytes(UTF8)) Read about problems verify due to string encoding problems. -Base64 Encode the Signature -Transmit it over a Socket with Message Concatenated at end -Receive it over a Socket in C with OpenSSL Lob -Load Public Key from PEM files into OpenSSL use BIO Object -Call OpenSSL Verify and returns Invalid Signature. Couple Questions: 1. Does anyone see any problems in this process (format conversations etc.)? 2. I notice the Java Signature is ASN.1 object with r s value, except they r value is 0x15 = 21 bytes ... The OpenSSL signature I have analyzed have 0x30 len 0x20 0x40, then start with RS Values 20 byte each What are the 0x20 and 0x40 tags of the ASN.1 notation from OpenSSL? Do I have to convert any of these since they are slightly 2 different signature types? 3. Is there any method to get any debug / error information from an invalid signature verify function? It would be great if I had a idea of where to begin? Regards, -- Kevin
Re: DSA Java (Sign Message) C OpenSSL (Verify Signature)
Couple updates... Command Line: OpenSSL generate DSA public and private keys using the command line interface (PEM Files) OpenSSL command line interface convert to DER format for Java Code: Load them into Java using PCKS#8 Reader Classes -Sign a Message (Use Java String.getbytes(UTF8)) Read about problems verify due to string encoding problems. -Base64 Encode the Signature -Transmit it over a Socket with Message Concatenated at end -Receive it over a Socket in C with OpenSSL Lob Base64 Decode it into unsigned char Array -Load Public Key from PEM files into OpenSSL use BIO Object -Call OpenSSL Verify and returns Invalid Signature. Testing: -Java Signature Validate fine within Java - OpenSSL generated signature validates fine within OpenSSL. They do not validate with each other though. Couple Questions: 1. Does anyone see any problems in this process (format conversations etc.)? 2. I notice the Java Signature is ASN.1 object with r s value, except they r value is 0x15 = 21 bytes ... The OpenSSL signature I have analyzed have 0x30 len 0x20 0x40, then start with RS Values 20 byte each What are the 0x20 and 0x40 tags of the ASN.1 notation from OpenSSL? Do I have to convert any of these since they are slightly 2 different signature types? I've reach on CodeProject about Cryptographic Interoperability and IEEE P1363, but both Java and OpenSSL are using DER encoded ASN.1 encoding. 3. Is there any method to get any debug / error information from an invalid signature verify function? It would be great if I had a idea of where to begin? 4. Is Endianess of the signature a possible problem? Both are win PC (x64) but cygwin gdb is probably (x86) Thanks for any suggestions! I'm pretty stumped at the minute. Regards, -- Kevin
