RE: Can't recognize intermediate CA
the cacert has pathlen:1 in its X509v3 Basic Constraints Subject: Can't recognize intermediate CA Date: Thu, 12 Mar 2009 15:00:47 -0700 From: rene.hol...@watchguard.com To: openssl-users@openssl.org I'm tearing my hair out trying to get an intermediate CA to be recognized. I have cacert.pem signing intcert.pem signing (well, resigning), yahoo.pem Openssl verify verifiies intcert.pem against cacert.pem, but won't verify yahoo.pem against intcert.pem. Subject/issuer match. AKID dirname and issuer subject match, AKID serial number and issuer serial number match. AKID and issuer SKID match. Basic Constraints CA:TRUE, pathlen:1 on both root and intermediate (for good measure) cert. Key usage CertSign and CRLSign on both root and intermediate cert. Can anyone see what is wrong? I'm including PEM versions of these certs. Cacert.pem: -BEGIN CERTIFICATE- MIIEVTCCAz2gAwIBAgIJAIt1rjt0ILA+MA0GCSqGSIb3DQEBBQUAMHQxCzAJBgNV BAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMQ8wDQYDVQQKEwZGb29iYXIxDzAN BgNVBAsTBmZvb2JhcjESMBAGA1UEAxMJRm9vIEIuIEFyMRowGAYJKoZIhvcNAQkB Fgtmb29AYmFyLmNvbTAeFw0wOTAzMTIyMTM3MDNaFw0xMjAzMTEyMTM3MDNaMHQx CzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMQ8wDQYDVQQKEwZGb29i YXIxDzANBgNVBAsTBmZvb2JhcjESMBAGA1UEAxMJRm9vIEIuIEFyMRowGAYJKoZI hvcNAQkBFgtmb29AYmFyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALiK8GZlT0zZJkfGpwXfiQhO++76F6PJGczjeKXv+b7SdIhBIKlMZvNHlM1z 96QQI8rrSnlZpKi7MXwZZaSVNUF8cas1OrfkOJ2Epb2/HmgbqXMKCIDVxvN/kHcP AFgPwlWx7gzYCPzmUcHl1t+8BesiFuMR8gvjB1CuKTbOgM3YgI08pOmon+zXkbz2 Jr8GhBgTMuCowL7GbrF9zUOKVUeNemc1zRYtIvlaKpk4ieCPcvSdXu4I6kPOkUlM eBkKU+yEHkAzeLlzryOlbx+dbl+yUexNdUXXXfTa+3OEzFS+4m+UJxS/czHvtb4P iOO8CAspuvVKoSm4vFMr09TKP7kCAwEAAaOB6TCB5jAdBgNVHQ4EFgQUGkDcZzhR mtzShXaKRqteehN6ZFswgaYGA1UdIwSBnjCBm4AUGkDcZzhRmtzShXaKRqteehN6 ZFuheKR2MHQxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMQ8wDQYD VQQKEwZGb29iYXIxDzANBgNVBAsTBmZvb2JhcjESMBAGA1UEAxMJRm9vIEIuIEFy MRowGAYJKoZIhvcNAQkBFgtmb29AYmFyLmNvbYIJAIt1rjt0ILA+MA8GA1UdEwQI MAYBAf8CAQEwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQBhmhGBn+fI RtociIKU8DsUgs8LGrM7pNt+ST2L2qIxemVACO1eXTGqrvKzh6B3M5P+q9rN2QeR dGYh+JqXGo6nYkaTGZPW3oVfcXjcV/ewpkWgR15uGKpZqfNgj4NUDTnk5IOlYn6C FCnwR8ZQ9R8zGpT8ihYWcIfqQmix+t76KmxE6nQ5RyYO1qOYzHWGHZ0oQCU3/15v bcJqqgCUjC8b3sHE4AduYB92Dfh1b2YjfB8Em0eP5wyzwPVVq+RI89pg6RqMj5ue r0MPfMcp1E98zibSFeBYVjV0yyxPpg7IRDZmaI3HveBYfV1fDwg0fHeNrBn7dy3I AvScpmyMe2Mb -END CERTIFICATE- Intcert.pem: -BEGIN CERTIFICATE- MIIELTCCAxWgAwIBAgIJAIt1rjt0ILBAMA0GCSqGSIb3DQEBBQUAMHQxCzAJBgNV BAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMQ8wDQYDVQQKEwZGb29iYXIxDzAN BgNVBAsTBmZvb2JhcjESMBAGA1UEAxMJRm9vIEIuIEFyMRowGAYJKoZIhvcNAQkB Fgtmb29AYmFyLmNvbTAeFw0wOTAzMTIyMTQxNDVaFw0xMDAzMTIyMTQxNDVaMEwx IDAeBgNVBAoWF1dhdGNoR3VhcmRfVGVjaG5vbG9naWVzMREwDwYDVQQLEwhGaXJl d2FyZTEVMBMGA1UEAxYMUmVzaWduaW5nX0NBMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEA8zXi919osAnB6xIjSfvzvXJe6a+0p6RreKZ2kt3gr7rrlUZN wYg92+PpBx7ufNxZWZYaDYnXttZUx9hFJognz5iOkIGf4Iq0rZOc2EPYH+NiCtP/ COd++s8LSX+P258EHiTkPP3spANTttfn7pltdjoysJDWXrUIlBhmMeB/zpSRBIXX qeXjZ5qvp5IGGDMfg9whv7Ct+awiuf1E98bCoYEfbpywFO7os67lYtWQvxRBd2yc NUvNFssNGFmYj2JEixqdCpcPWXxwMNYRbmwkPiB9rQnaykOrzzWJ03PXTwT+iM6T yk60Y+bN5hSmM3z0dQF0HS4WZ2uZUUWp5ZrwmQIDAQABo4HpMIHmMB0GA1UdDgQW BBSEEcoe9bZDB56/eMMA5AEZnu0bRzCBpgYDVR0jBIGeMIGbgBQaQNxnOFGa3NKF dopGq156E3pkW6F4pHYwdDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCldhc2hpbmd0 b24xDzANBgNVBAoTBkZvb2JhcjEPMA0GA1UECxMGZm9vYmFyMRIwEAYDVQQDEwlG b28gQi4gQXIxGjAYBgkqhkiG9w0BCQEWC2Zvb0BiYXIuY29tggkAi3WuO3QgsD4w DwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggEB ABxzGFfezOPSQUZW4BkgCKlTM8heLIP48bXL8PHR+4ZW/C3FoaPwb8oCI2EMJAEq kPHDr2NTtZ++Nx+1tVFpkSxfSBuC/gHjAlewk3owPbLmwDpIf7MPMX0iKgfUeC+m NQxsY8NqwWswXHtRLLWJgAzZKWeN1PYMGgRmmGaH2lPYGT0xcpRuZfhTE5HlJ9VC B3hV3JMD+VzPTzzcFm3gCCyR+dgNI0FmpoxtJzlirVj4BjHqTl+v4uhaX/wCgBvz QcAWftj4GiemnficByogBS3QdbDwQGephQX2qySXzv0o8+qOV+RNMdPHH1T4o/tN mjwXr099i5XcIvlfR9v677Q= -END CERTIFICATE- Yahoo.pem: -BEGIN CERTIFICATE- MIIDojCCAoqgAwIBAgIYANIyCa0j0xQjIXTkDX+dYhOXhmM6BaBMMA0GCSqGSIb3 DQEBBQUAMEwxIDAeBgNVBAoWF1dhdGNoR3VhcmRfVGVjaG5vbG9naWVzMREwDwYD VQQLEwhGaXJld2FyZTEVMBMGA1UEAxYMUmVzaWduaW5nX0NBMB4XDTA2MDEwNDE3 MDkwNloXDTExMDEwNDE3MDkwNloweDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNh bGlmb3JuaWExFDASBgNVBAcTC1NhbnRhIENsYXJhMRQwEgYDVQQKFAtZYWhvbyEg SW5jLjEOMAwGA1UECxMFWWFob28xGDAWBgNVBAMTD2xvZ2luLnlhaG9vLmNvbTCB nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA484iMII/1qq0eEs8UQ1B4HHWD9Qj ZVS1z9BfCtfJBK3L5+xH+ZJayxiZW9zhRgMPhLhqDg8zyK3ah18A3JmbMHRu1QOg 1OHrG+NI66pQE4A3+2uTpVuX+IauLDtfEg8SDvnJLOItIhvj/pBky0lP0zQwpDbz DDxauMfmQj2QhGcCAwEAAaOBzzCBzDAOBgNVHQ8BAf8EBAMCBPAwHQYDVR0lBBYw FAYIKwYBBQUHAwEGCCsGAQUFBwMCMB0GA1UdDgQWBBSbi+W7qyiacBd5dbiLIySj 9WC0YDB8BgNVHSMEdTBzgBSEEcoe9bZDB56/eMMA5AEZnu0bR6FQpE4wTDEgMB4G A1UEChYXV2F0Y2hHdWFyZF9UZWNobm9sb2dpZXMxETAPBgNVBAsTCEZpcmV3YXJl
RE: Can't recognize intermediate CA
I tried it with no (i.e. infinite) pathlen specified in cacert.pem. Same effect. Am I wrong in understanding that pathlen:0 implies no intermediate CAs and pathlen:1 implies at most one intermediate CA (as is the case here)? i believe you're right: the pathlen isnt the problem. (i just read http://www.openssl.org/docs/apps/x509v3_config.html#Basic_Constraints_ again.) I used openssl with the intermediate CA to sign a separate cert, which had a AKID keyid but no issuer, and that chain recongizes fine. Could the problem be the fact that yahoo.pem has an AKID keyid AND issuer? (onr or the other is sufficient, but I could find nothing that said that both were illegal). using -verbose and -issuer_checks showed, along with error 29: error 31 at 0 depth lookup:authority and issuer serial number mismatch so i compared the serial numbers and the key id's. they looked ok to me. so at this point, i dont have any ideas. -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Giang Nguyen Sent: Thursday, March 12, 2009 3:49 PM To: openssl-users@openssl.org Subject: RE: Can't recognize intermediate CA the cacert has pathlen:1 in its X509v3 Basic Constraints Subject: Can't recognize intermediate CA Date: Thu, 12 Mar 2009 15:00:47 -0700 From: rene.hol...@watchguard.com To: openssl-users@openssl.org I'm tearing my hair out trying to get an intermediate CA to be recognized. I have cacert.pem signing intcert.pem signing (well, resigning), yahoo.pem Openssl verify verifiies intcert.pem against cacert.pem, but won't verify yahoo.pem against intcert.pem. Subject/issuer match. AKID dirname and issuer subject match, AKID serial number and issuer serial number match. AKID and issuer SKID match. Basic Constraints CA:TRUE, pathlen:1 on both root and intermediate (for good measure) cert. Key usage CertSign and CRLSign on both root and intermediate cert. Can anyone see what is wrong? I'm including PEM versions of these certs. Cacert.pem: -BEGIN CERTIFICATE- MIIEVTCCAz2gAwIBAgIJAIt1rjt0ILA+MA0GCSqGSIb3DQEBBQUAMHQxCzAJBgNV BAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMQ8wDQYDVQQKEwZGb29iYXIxDzAN BgNVBAsTBmZvb2JhcjESMBAGA1UEAxMJRm9vIEIuIEFyMRowGAYJKoZIhvcNAQkB Fgtmb29AYmFyLmNvbTAeFw0wOTAzMTIyMTM3MDNaFw0xMjAzMTEyMTM3MDNaMHQx CzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMQ8wDQYDVQQKEwZGb29i YXIxDzANBgNVBAsTBmZvb2JhcjESMBAGA1UEAxMJRm9vIEIuIEFyMRowGAYJKoZI hvcNAQkBFgtmb29AYmFyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALiK8GZlT0zZJkfGpwXfiQhO++76F6PJGczjeKXv+b7SdIhBIKlMZvNHlM1z 96QQI8rrSnlZpKi7MXwZZaSVNUF8cas1OrfkOJ2Epb2/HmgbqXMKCIDVxvN/kHcP AFgPwlWx7gzYCPzmUcHl1t+8BesiFuMR8gvjB1CuKTbOgM3YgI08pOmon+zXkbz2 Jr8GhBgTMuCowL7GbrF9zUOKVUeNemc1zRYtIvlaKpk4ieCPcvSdXu4I6kPOkUlM eBkKU+yEHkAzeLlzryOlbx+dbl+yUexNdUXXXfTa+3OEzFS+4m+UJxS/czHvtb4P iOO8CAspuvVKoSm4vFMr09TKP7kCAwEAAaOB6TCB5jAdBgNVHQ4EFgQUGkDcZzhR mtzShXaKRqteehN6ZFswgaYGA1UdIwSBnjCBm4AUGkDcZzhRmtzShXaKRqteehN6 ZFuheKR2MHQxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMQ8wDQYD VQQKEwZGb29iYXIxDzANBgNVBAsTBmZvb2JhcjESMBAGA1UEAxMJRm9vIEIuIEFy MRowGAYJKoZIhvcNAQkBFgtmb29AYmFyLmNvbYIJAIt1rjt0ILA+MA8GA1UdEwQI MAYBAf8CAQEwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQBhmhGBn+fI RtociIKU8DsUgs8LGrM7pNt+ST2L2qIxemVACO1eXTGqrvKzh6B3M5P+q9rN2QeR dGYh+JqXGo6nYkaTGZPW3oVfcXjcV/ewpkWgR15uGKpZqfNgj4NUDTnk5IOlYn6C FCnwR8ZQ9R8zGpT8ihYWcIfqQmix+t76KmxE6nQ5RyYO1qOYzHWGHZ0oQCU3/15v bcJqqgCUjC8b3sHE4AduYB92Dfh1b2YjfB8Em0eP5wyzwPVVq+RI89pg6RqMj5ue r0MPfMcp1E98zibSFeBYVjV0yyxPpg7IRDZmaI3HveBYfV1fDwg0fHeNrBn7dy3I AvScpmyMe2Mb -END CERTIFICATE- Intcert.pem: -BEGIN CERTIFICATE- MIIELTCCAxWgAwIBAgIJAIt1rjt0ILBAMA0GCSqGSIb3DQEBBQUAMHQxCzAJBgNV BAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMQ8wDQYDVQQKEwZGb29iYXIxDzAN BgNVBAsTBmZvb2JhcjESMBAGA1UEAxMJRm9vIEIuIEFyMRowGAYJKoZIhvcNAQkB Fgtmb29AYmFyLmNvbTAeFw0wOTAzMTIyMTQxNDVaFw0xMDAzMTIyMTQxNDVaMEwx IDAeBgNVBAoWF1dhdGNoR3VhcmRfVGVjaG5vbG9naWVzMREwDwYDVQQLEwhGaXJl d2FyZTEVMBMGA1UEAxYMUmVzaWduaW5nX0NBMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEA8zXi919osAnB6xIjSfvzvXJe6a+0p6RreKZ2kt3gr7rrlUZN wYg92+PpBx7ufNxZWZYaDYnXttZUx9hFJognz5iOkIGf4Iq0rZOc2EPYH+NiCtP/ COd++s8LSX+P258EHiTkPP3spANTttfn7pltdjoysJDWXrUIlBhmMeB/zpSRBIXX qeXjZ5qvp5IGGDMfg9whv7Ct+awiuf1E98bCoYEfbpywFO7os67lYtWQvxRBd2yc NUvNFssNGFmYj2JEixqdCpcPWXxwMNYRbmwkPiB9rQnaykOrzzWJ03PXTwT+iM6T yk60Y+bN5hSmM3z0dQF0HS4WZ2uZUUWp5ZrwmQIDAQABo4HpMIHmMB0GA1UdDgQW BBSEEcoe9bZDB56/eMMA5AEZnu0bRzCBpgYDVR0jBIGeMIGbgBQaQNxnOFGa3NKF dopGq156E3pkW6F4pHYwdDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCldhc2hpbmd0 b24xDzANBgNVBAoTBkZvb2JhcjEPMA0GA1UECxMGZm9vYmFyMRIwEAYDVQQDEwlG b28gQi4gQXIxGjAYBgkqhkiG9w0BCQEWC2Zvb0BiYXIuY29tggkAi3WuO3QgsD4w DwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggEB ABxzGFfezOPSQUZW4BkgCKlTM8heLIP48bXL8PHR+4ZW/C3FoaPwb8oCI2EMJAEq kPHDr2NTtZ++Nx+1tVFpkSxfSBuC/gHjAlewk3owPbLmwDpIf7MPMX0iKgfUeC+m
RE: Can't recognize intermediate CA
I used openssl with the intermediate CA to sign a separate cert, which had a AKID keyid but no issuer, and that chain recongizes fine. Could the problem be the fact that yahoo.pem has an AKID keyid AND issuer? (onr or the other is sufficient, but I could find nothing that said that both were illegal). it might be a bug in openssl X509_check_issued() function. im using openssl 0.9.8i. line 650 in v3_purp.c: if(nm X509_NAME_cmp(nm, X509_get_issuer_name(issuer))) return X509_V_ERR_AKID_ISSUER_SERIAL_MISMATCH; nm is the DirName thing in the subject cert's AKID, ie /O=WatchGuard_Technologies/OU=Fireware/CN=Resigning_CA and issuer is the intermediate CA cert, so its X509_get_issuer_name(issuer) will be name of root CA. so the comparsion will fail, and you get the error. looks like it should be X509_get_subject_name(issuer) _ Windows Live™ Groups: Create an online spot for your favorite groups to meet. http://windowslive.com/online/groups?ocid=TXT_TAGLM_WL_groups_032009__ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Can't recognize intermediate CA
I used openssl with the intermediate CA to sign a separate cert, which had a AKID keyid but no issuer, and that chain recongizes fine. Could the problem be the fact that yahoo.pem has an AKID keyid AND issuer? (onr or the other is sufficient, but I could find nothing that said that both were illegal). it might be a bug in openssl X509_check_issued() function. im using openssl 0.9.8i. line 650 in v3_purp.c: if(nm X509_NAME_cmp(nm, X509_get_issuer_name(issuer))) return X509_V_ERR_AKID_ISSUER_SERIAL_MISMATCH; nm is the DirName thing in the subject cert's AKID, ie /O=WatchGuard_Technologies/OU=Fireware/CN=Resigning_CA and issuer is the intermediate CA cert, so its X509_get_issuer_name(issuer) will be name of root CA. so the comparsion will fail, and you get the error. looks like it should be X509_get_subject_name(issuer) $ ./openssl version OpenSSL 0.9.8i 15 Sep 2008 $ $ ./openssl verify -CApath cas cas/int.pem cas/int.pem: OK $ $ ./openssl verify -CApath cas yahoo.pem yahoo.pem: /C=US/ST=California/L=Santa Clara/O=Yahoo! Inc./OU=Yahoo/CN=login.yahoo.com error 20 at 0 depth lookup:unable to get local issuer certificate $ $ $ gdb --args ./openssl verify -CApath cas yahoo.pem GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i486-linux-gnu... (gdb) (gdb) b v3_purp.c:630 Breakpoint 1 at 0x812d0e7: file v3_purp.c, line 630. (gdb) b v3_purp.c:651 Breakpoint 2 at 0x812d186: file v3_purp.c, line 651. (gdb) r Starting program: ./openssl verify -CApath cas yahoo.pem Breakpoint 2, X509_check_issued (issuer=0x8204e68, subject=0x8204760) at v3_purp.c:651 651 return X509_V_ERR_AKID_ISSUER_SERIAL_MISMATCH; (gdb) p nm $1 = (X509_NAME *) 0x820bf18 (gdb) p X509_NAME_oneline(nm,0,0) $2 = 0x820c0f8 /O=WatchGuard_Technologies/OU=Fireware/CN=Resigning_CA (gdb) p issuer $3 = (X509 *) 0x8204e68 (gdb) set nm=X509_get_issuer_name(issuer) (gdb) p nm $4 = (X509_NAME *) 0x8206310 (gdb) p X509_NAME_oneline(nm,0,0) $5 = 0x820c208 /C=US/ST=Washington/O=Foobar/OU=foobar/CN=Foo B. Ar/emailaddress=...@bar.com (gdb) set nm=X509_get_subject_name(issuer) (gdb) p nm $6 = (X509_NAME *) 0x82083b0 (gdb) p X509_NAME_oneline(nm,0,0) $7 = 0x820c318 /O=WatchGuard_Technologies/OU=Fireware/CN=Resigning_CA (gdb) _ Windows Live™: Life without walls. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_allup_1a_explore_032009__ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Can't recognize intermediate CA
Sincerely, Giang Nguyen Date: Fri, 13 Mar 2009 00:22:56 +0100 From: st...@openssl.org To: openssl-users@openssl.org Subject: Re: Can't recognize intermediate CA On Thu, Mar 12, 2009, Rene Hollan wrote: Yeah, I just noticed that. I've been comparing how my intermediate CA resigned an existing cert (it's part of a proxy that decrypts, examines, and reencrypts -- the downstream client sharing a trust hierarchy with the intermediate resigning CA) with what OpenSSL ca ... does. OpenSSL ca ... actually puts the issuer of the issuer into the AKID issuer field of the signed cert, along with the issuer serial number. When the issuer is a root ca, it is it's own issuer, so the issuer (which is what my resigning code was using), and issuer's issuer are the same. But, when the issuer is an intermediate CA, they are different. So, either I'm doing it wrong, or OpenSSL ca ... Is doing it wrong (but consistent with how OpenSSL verify ... checks). At this point, I think the error is mine. At least browsers accept the cert when OpenSSL signs it with an intermediate CA, and not when I do. Think about it: the purpose of the AKID is to identify the public key of the signer, either by matching the SKID of the signer, or some other means of identifying the signer. Well, the signer's serial number is unique within those issued by IT'S signer, so the combination of IT's signer and IT's serial number should be probabilistically unique. This whole SKID/AKID mess comes about because issuer and subject DNs are not guaranteed to be globally unique, but the combination of issuer's issuer DN, and issuer's serial number within the issuer's issuer's DN are statistically more so. (Without SKID/AKID, one would have to verify a prospective issuer by unhashing the signature with the issuer's public key, which is arguably more computationally expensive that comparing SKID and AKID. One should still do this anyway, but the SKID/AKID check preemptively eliminates the wrong issuer). Sigh. X500 looks like a royal designed by non-technical committee mess. Thanks for the help, now excuse me while I make a code change. If it's any consolation you aren't alone with that, it gets commented on quite often so much so in fact that it has an FAQ entry: http://www.openssl.org/support/faq.html#USER15 doh, that makes sense! thanks. _ Hotmail® is up to 70% faster. Now good news travels really fast. http://windowslive.com/online/hotmail?ocid=TXT_TAGLM_WL_HM_70faster_032009__ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Verifying private certificate before SSL connection
what do you mean private certificate? you mean the server wants to verify its own certificate before accepting connections? or the client wants to verify its own certificate before initiating connections? (i guess it doesn't matter either way, though.) assuming you have the CA certs and the CRLs, the openssl verify command verifies a particular certificate (doesnt matter if it's the client's or server's certificate). you should be able to model your code after that program. any case i mention what i have done: X509_STORE *cert_ctx = NULL; X509_LOOKUP *lookup = NULL; /* free lookup - crash burn */ X509_STORE_CTX *cert_store_ctx = NULL; X509 *cert = NULL; /* some how, load into cert the certificate you want to verify */ cert_ctx = X509_STORE_new(); // check result /* because i have the CA certs maintained by c_rehash in a directory, i do these next two calls: */ lookup = X509_STORE_add_lookup(cert_ctx, X509_LOOKUP_hash_dir()); // check result result = X509_LOOKUP_add_dir(lookup, ca_dir, X509_FILETYPE_PEM); // check result cert_store_ctx = X509_STORE_CTX_new(); // check result result = X509_STORE_CTX_init(cert_store_ctx, cert_ctx, cert, NULL); // check result result = X509_verify_cert(cert_store_ctx); // if result == 0, then verification failed. otherwise, verification passed. Date: Sat, 7 Mar 2009 20:29:36 -0500 From: lizv...@sisconet.com To: openssl-users@openssl.org Subject: Verifying private certificate before SSL connection Hello, I need to implement new requirement to verify private certificate before it is used for SSL/TLS connection. Basically I should not use certificate that is expired or revoked. I am working with OpenSSL 0.9.8i. I made function similar to what we are using to verify peer certificate but I am experiencing crashes in X509_verify_cert function. I wonder if anybody is verifying private certificate used for SSL/TLS connection? Any tip would be greatly appreciated. Liz I prepared ssl_ctx by loading CA, CRL, ciphers and private certificate. He is code fragment showing the major steps. SSL *ssl; X509 *x509 = NULL; X509_STORE_CTX *ctx; X509_STORE *cert_store = NULL; ssl = SSL_new(ssl_ctx); x509 = SSL_get_certificate (ssl); /* x509 = SSL_get_peer_certificate (ssl); */ cert_store = SSL_CTX_get_cert_store(ssl_ctx); X509_STORE_set_verify_cb_func(cert_store, _verifyCertificateCallback); ctx = X509_STORE_CTX_new(); X509_STORE_CTX_init(ctx, cert_store, x509, NULL); X509_verify_cert(ctx); __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org _ Windows Live™ Contacts: Organize your contact list. http://windowslive.com/connect/post/marcusatmicrosoft.spaces.live.com-Blog-cns!503D1D86EBB2B53C!2285.entry?ocid=TXT_TAGLM_WL_UGC_Contacts_032009__ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: get public Key from a certificate
if you have a certificate in a X509 object, the x509.h header mentions the function: EVP_PKEY *X509_get_pubkey(X509 *x); From: binome_...@hotmail.com To: openssl-users@openssl.org Subject: get public Key from a certificate Date: Tue, 24 Feb 2009 10:29:42 + hello how can i get the public Key from a certificate ? ( please give me just the name of the function, for example i use to get a public key from a private key : PrivKey = RSA_generate_key(512, RSA_F4, NULL, NULL); PubKey = RSAPublicKey_dup(PrivKey); ) if i send a certificate , i'm not oblige to send a public key , i deduce it from a a certificate (am i wrong ???!) ) best regards _ Windows Live™ Hotmail®…more than just e-mail. http://windowslive.com/howitworks?ocid=TXT_TAGLM_WL_t2_hm_justgotbetter_howitworks_022009__ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: IE could not connect to a chaine-cert's ssl server
i think it's because your my-cacert.pem is not considered a CA: it has CA:FALSE arch [temp]$ openssl x509 -in my-cacert.pem -BEGIN CERTIFICATE- MIIC9jCCAl+gAwIBAgIBADANBgkqhkiG9w0BAQUFADB4MQswCQYDVQQGEwJDQTET MBEGA1UECBMKU29tZS1TdGF0ZTEhMB8GA1UEChMYSW50ZXJuZXQgV2lkZ2l0cyBQ dHkgTHRkMRAwDgYDVQQDEwdteS1yb290MR8wHQYJKoZIhvcNAQkBFhByb290QHdp ZGdpdHMuY29tMB4XDTA5MDIwNDAxNTA1MloXDTEyMDIwNDAxNTA1MloweDELMAkG A1UEBhMCQ0ExEzARBgNVBAgTClNvbWUtU3RhdGUxITAfBgNVBAoTGEludGVybmV0 IFdpZGdpdHMgUHR5IEx0ZDEQMA4GA1UEAxMHbXktcm9vdDEfMB0GCSqGSIb3DQEJ ARYQcm9vdEB3aWRnaXRzLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA sFZr5Htj5VUc69iYiFaRGGCQvsgrCw6kJFo9DZVRkMvmDYwpZ8vVg6H/l1xL+mWA Ur2T/z32JvLKPEH7DyXzQehdVFjVxS2zmfdIOI8P7CMH3pOuhiko8vPc+xhS5a4q 6Khvryx0n88RB1xj58WKtW9Op9FsG0ASE33Kh4oRhtMCAwEAAaOBjzCBjDAJBgNV HRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIEsDAsBglghkgBhvhCAQ0EHxYdT3BlblNT TCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFDKh9W+fw4bPij+S9LXC m/RIl2xEMB8GA1UdIwQYMBaAFDKh9W+fw4bPij+S9LXCm/RIl2xEMA0GCSqGSIb3 DQEBBQUAA4GBAKt7JnTmCzTQTw+bKtgkpR50Dw2wpQwL2pjYtVfRXX4eBcvgvLtY BAktaD03TN1ZKurZX6dWY0n9GP2nwUIQfkkQdXVlkOE//EiObPj6A0knzn2Rc/Cl nVgkYYWsQ122359RC8/1N+piN0XZrxM9JIfl9wcij71HZAeueddl3olF -END CERTIFICATE- arch [temp]$ arch [temp]$ openssl x509 -in my-cacert.pem -text | grep -A1 Constra X509v3 Basic Constraints: CA:FALSE arch [temp]$ the openssl verify command succeeds, but i think it's because it's more lenient (http://openssl.org/docs/apps/verify.html#) _ Windows Live™: E-mail. Chat. Share. Get more ways to connect. http://windowslive.com/howitworks?ocid=TXT_TAGLM_WL_t2_allup_howitworks_022009__ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Multiple CRL with same issuer
I was under the impression that openssl allows loading multiple CRLs for the same issuer. But, this does not seem to be the case as is proved by using openssl verify. $ ls -l ./ca/ total 24 lrwxrwxrwx 1 pshah users 10 Jan 28 21:56 ba4bb3b6.0 - cacert.pem - the CA cert lrwxrwxrwx 1 pshah users 14 Jan 28 21:56 ba4bb3b6.r0 - revoked_48.pem revokes only cert48.pem lrwxrwxrwx 1 pshah users 14 Jan 28 21:56 ba4bb3b6.r1 - revoked_49.pem - revokes only cert49.pem -rw-r--r-- 1 pshah users 1233 Jan 28 17:09 cacert.pem -rw-r--r-- 1 pshah users 560 Jan 28 17:10 revoked_48.pem -rw-r--r-- 1 pshah users 560 Jan 28 17:10 revoked_49.pem $ openssl verify -CApath ./ca/ -crl_check -verbose cert49.pem cert49.pem: OK $ openssl verify -CApath ./ca/ -crl_check -verbose cert48.pem cert48.pem: /C=--/ST=California/L=San Francisco/O=Riverbed Technology, Inc./OU=Steelhead/CN=hw1-sh18/emailaddress=fakeem...@example.com mailto:fakeem...@example.com error 23 at 0 depth lookup:certificate revoked 29615:error:0B07D065:x509 certificate routines:X509_STORE_add_crl:cert already in hash table:x509_lu.c:418: A CRL ( Certificat revocation list) is the list of ALL the revoked certificates at the time it is issued So if at time t1 a certificate 48 is revoked then all the subsequent CRLs MUST indicate that the certificate 48 as revoked If later at time t2 the certificate 49 is revoked hen all the subsequent CRLs MUST indicate that both certificate 48 and certificate 49 arte revoked Thus only the lasT CRL has to considered . Since the delivery times of the CRLs are close together it is not easy to check into the example which is ithe last CRL i think you misunderstood the question. the issue at hand is not about older and latest copies of a particular (certificate revocation) list, but it is about two *distinct* simultaneously valid and active (certificate revocation) lists that are issued/maintained by the same issuer. http://tools.ietf.org/html/rfc5280#section-5 Each CRL has a particular scope. The CRL scope is the set of certificates that could appear on a given CRL. For example, the scope could be all certificates issued by CA X, all CA certificates issued by CA X, all certificates issued by CA X that have been revoked for reasons of key compromise and CA compromise, or a set of certificates based on arbitrary local information, such as all certificates issued to the NIST employees located in Boulder. _ Hotmail® goes where you go. On a PC, on the Web, on your phone. http://www.windowslive-hotmail.com/learnmore/versatility.aspx#mobile?ocid=TXT_TAGHM_WL_HM_versatility_121208
RE: Multiple CRL with same issuer
thanks, kyle, for pointing that out about the issuing distribution point. http://tools.ietf.org/html/rfc5280#section-5.2.5 so if i read that section correctly, the issuing distribution point extension is THE way to specify scope as you mentioned. so two distinct CRLs from the same issuer can be simultaneously valid/active (as long as they have different issuing distribution point extensions). that's what you were saying right? so no, in our case, the two CRLs do NOT have the issuing distribution point extensions. i notice they also happen to be v1. any way, dr henson has said 0.9.9-dev includes support for loading multiple CRLs with the same issuer name. thanks. Date: Thu, 29 Jan 2009 02:12:29 -0800 Subject: Re: Multiple CRL with same issuer From: aerow...@gmail.com To: openssl-users@openssl.org (First: I'm sorry. I misunderstood something I read in the OpenSSL documentation. CRLs are always V2 according to RFC5280.) I have not heard of the ability to specify or process multiple scopes in OpenSSL; however, have you verified that the CRL Extension Issuing Distribution Point is different between the two CRLs? This is where different scopes are specified (section 5.2.5 of RFC 5280). -Kyle H 2009/1/29 Kyle Hamilton : I think you're trying to assume something that cannot be assumed: you assume that ALL unexpired CRLs are considered. This is not the case. As Dominiqué said, only the CRL that has the latest signature time is considered. This is evident in the name of the file type: Certificate Revocation *List*. It is legal to issue a CRL that revokes a certificate (possibly with an type of onhold, for V3 CRLs) with an expiration time of 2 years in the future, and the next hour the to remove the revocation status. If all simultaneously-valid CRLs are considered, then the intended consequence of unrevoking the certificate would be impossible. This is why the CRL must contain the *complete* list of *all* revoked certificates which have not yet expired. There is a PKIX extension, delta CRLs, which defines for V3 CRLs a way to allow for adding to the list of the most-recently-issued full CRL. In order to support unrevocation, there is a special status type (called remove_from_crl) for the delta CRL which is to be interpreted as removing the certificate from the revocation list; however, in a full V3 CRL, that status type is illegal. And in V2 CRLs (the default, since many implementations do not handle V3 CRLs) there is no means of specifying the extension that contains a status type regardless. This is specified in PKIX (currently RFC 5280); in order to maintain standards-conformance OpenSSL cannot change this behavior. (Nor can it even offer an option to change it, since its job is to maintain security-system interoperability, not capriciously make it less secure.) -Kyle H 2009/1/29 Giang Nguyen : I was under the impression that openssl allows loading multiple CRLs for the same issuer. But, this does not seem to be the case as is proved by using openssl verify. $ ls -l ./ca/ total 24 lrwxrwxrwx 1 pshah users 10 Jan 28 21:56 ba4bb3b6.0 - cacert.pem - the CA cert lrwxrwxrwx 1 pshah users 14 Jan 28 21:56 ba4bb3b6.r0 - revoked_48.pem revokes only cert48.pem lrwxrwxrwx 1 pshah users 14 Jan 28 21:56 ba4bb3b6.r1 - revoked_49.pem - revokes only cert49.pem -rw-r--r-- 1 pshah users 1233 Jan 28 17:09 cacert.pem -rw-r--r-- 1 pshah users 560 Jan 28 17:10 revoked_48.pem -rw-r--r-- 1 pshah users 560 Jan 28 17:10 revoked_49.pem $ openssl verify -CApath ./ca/ -crl_check -verbose cert49.pem cert49.pem: OK $ openssl verify -CApath ./ca/ -crl_check -verbose cert48.pem cert48.pem: /C=--/ST=California/L=San Francisco/O=Riverbed Technology, Inc./OU=Steelhead/CN=hw1-sh18/emailaddress=fakeem...@example.com error 23 at 0 depth lookup:certificate revoked 29615:error:0B07D065:x509 certificate routines:X509_STORE_add_crl:cert already in hash table:x509_lu.c:418: A CRL ( Certificat revocation list) is the list of ALL the revoked certificates at the time it is issued So if at time t1 a certificate 48 is revoked then all the subsequent CRLs MUST indicate that the certificate 48 as revoked If later at time t2 the certificate 49 is revoked hen all the subsequent CRLs MUST indicate that both certificate 48 and certificate 49 arte revoked Thus only the lasT CRL has to considered . Since the delivery times of the CRLs are close together it is not easy to check into the example which is ithe last CRL i think you misunderstood the question. the issue at hand is not about older and latest copies of a particular (certificate revocation) list, but it is about two *distinct* simultaneously valid and active (certificate revocation) lists that are issued/maintained by the same issuer. http://tools.ietf.org/html/rfc5280#section-5 Each CRL has a particular scope. The CRL scope is the set
RE: seeding PRNG
you should try http://openssl.org/docs/crypto/RAND_add.html# _ Windows Live™: E-mail. Chat. Share. Get more ways to connect. http://windowslive.com/howitworks?ocid=TXT_TAGLM_WL_t2_allup_howitworks_012009__ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Passing parameters to openssl for CSR
the req man page mentions: -subj arg sets subject name for new request or supersedes the subject name when processing a request. The arg must be formatted as /type0=value0/type1=value1/type2=..., charac- ters may be escaped by \ (backslash), no spaces are skipped. Date: Wed, 28 Jan 2009 01:57:54 + From: jagintesven...@googlemail.com To: openssl-users@openssl.org Subject: Passing parameters to openssl for CSR Hi guys, I'm wondering if its possible to pass parameters to openssl when creating a CSR, specifically the country name, state name, locality name, organization name, common name etc? The reason being, I ideally would like to automate the process of creating a CSR and have it not require user input (other variables would be passed to it by default from an outside source). Something like... openssl req -days 3650 -nodes -new -keyout user.key -out user.csr -config -countryname SE -commonname user ... Any help would be appreciated, Thanks. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org _ Hotmail® goes where you go. On a PC, on the Web, on your phone. http://www.windowslive-hotmail.com/learnmore/versatility.aspx#mobile?ocid=TXT_TAGHM_WL_HM_versatility_121208 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: How to detect dead peers with DTLS?
I think I will go for the hack that misuses re-negotiation as a kind of heartbeat, keep alive or echo request. I tried to avoid this hack at first because it is a computational burden. AFAIK re-negotiation means restarting from scratch which means that expensive public key operations have to be performed. to avoid expensive full handshakes, what about using sessions? from what i read at http://tools.ietf.org/html/rfc4347#section-3, To the greatest extent possible, DTLS is identical to TLS. and from what i read at http://tools.ietf.org/html/rfc5238 section 3.4: multiple DTLS connections can be resumed from the same DTLS session, each running over its own DCCP connection. so my assumption here is that DTLS supports abbreviated handshakes for session resumptions. _ Windows Live™ Hotmail®: Chat. Store. Share. Do more with mail. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_hm_justgotbetter_explore_012009__ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: How to detect dead peers with DTLS?
I think Robin tested it, so yes it works... But you need the bugfixes he sent to the list... Robin: Am I right? actually i referred to session resumptions with abbreviated handshakes. i think the bugs/patches comment was in the context of renegotiations with full handshakes. Btw, does OpenSSL support renegotiation when using DTLS? It failed when I tried it with s_client and s_server. I learned from some forum that there's a bug regarding an incorrect message sequence number. Robin Seggelmann provided a patch which has not been merged into the upstream version. Is this still the current status? As far as I know yes. Robin has tested renegotiations with DTLS/UDP. We have a couple of patches for DTLS/UDP. However, they have not been integrated. The patches for DTLS/SCTP require the DTLS/UDP patches... _ Windows Live™: Keep your life in sync. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_allup_explore_012009__ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Extract public key from certificate
if you have the X509 * object (in your code), then you can try X509_set_pubkey() (in x509.h) to obtain the EVP_PKEY * object, then you can use the various PEM_write_..._RSAPublicKey() (in pem.h). _ Windows Live™ Hotmail®: Chat. Store. Share. Do more with mail. http://windowslive.com/howitworks?ocid=TXT_TAGLM_WL_t1_hm_justgotbetter_howitworks_012009__ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Extract public key from certificate
then you can try X509_set_pubkey() (in x509.h) to obtain the EVP_PKEY * object of course i meant X509_get_pubkey(). _ Windows Live™: Keep your life in sync. http://windowslive.com/howitworks?ocid=TXT_TAGLM_WL_t1_allup_howitworks_012009__ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: OpenSSL Security Advisory
Does the release of 0.9.8j also include the FIPS module support? do you mean anything other than this? http://www.mail-archive.com/openssl-users@openssl.org/msg55535.html This is the first full release of OpenSSL that can link against the validated FIPS module version 1.2 _ Windows LiveTM: Keep your life in sync. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_allup_explore_012009__ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: challengePassword attribute in CSR is a sequence?
This actually addresses both the questions. In the distant past some applications encoded certificate requests incorrectly and/or required an incorrect encoding. That is there to tolerate and/or generate such stuff. thanks. _ Windows LiveTM Hotmail®: Chat. Store. Share. Do more with mail. http://windowslive.com/howitworks?ocid=TXT_TAGLM_WL_t1_hm_justgotbetter_howitworks_012009__ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
challengePassword attribute in CSR is a sequence?
First, background (questions at the end):
Version 2 of the pkcs 9 spec at
http://www.rsa.com/rsalabs/node.asp?id=2131 (PDF:
ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-9-v2/pkcs-9.pdf) says in
section 5.4.1:
A challenge-password attribute must have a single attribute value.
At first I expected that to mean single in X509_ATTRIBUTE would be
1, but then I noticed (through gdb) that in an actual CSR it was
actually 0, which was confirmed by asn1parse below:
arch [apps]$ ./openssl version
Electric Fence 2.2.0 Copyright (C) 1987-1999 Bruce Perens
OpenSSL 0.9.8g 19 Oct 2007
arch [apps]$
arch [apps]$ ls csr
ls: csr: No such file or directory
arch [apps]$
arch [apps]$ ./openssl req -new -out csr -nodes /dev/null 21
test password!!!
optional company name
arch [apps]$
arch [apps]$ ./openssl asn1parse -in csr
Electric Fence 2.2.0 Copyright (C) 1987-1999 Bruce Perens
0:d=0 hl=4 l= 460 cons: SEQUENCE
4:d=1 hl=4 l= 309 cons: SEQUENCE
8:d=2 hl=2 l= 1 prim: INTEGER :00
11:d=2 hl=2 l= 69 cons: SEQUENCE
13:d=3 hl=2 l= 11 cons: SET
15:d=4 hl=2 l= 9 cons: SEQUENCE
17:d=5 hl=2 l= 3 prim: OBJECT:countryName
22:d=5 hl=2 l= 2 prim: PRINTABLESTRING :AU
26:d=3 hl=2 l= 19 cons: SET
28:d=4 hl=2 l= 17 cons: SEQUENCE
30:d=5 hl=2 l= 3 prim: OBJECT:stateOrProvinceName
35:d=5 hl=2 l= 10 prim: PRINTABLESTRING :Some-State
47:d=3 hl=2 l= 33 cons: SET
49:d=4 hl=2 l= 31 cons: SEQUENCE
51:d=5 hl=2 l= 3 prim: OBJECT:organizationName
56:d=5 hl=2 l= 24 prim: PRINTABLESTRING :Internet Widgits Pty Ltd
82:d=2 hl=3 l= 159 cons: SEQUENCE
85:d=3 hl=2 l= 13 cons: SEQUENCE
87:d=4 hl=2 l= 9 prim: OBJECT:rsaEncryption
98:d=4 hl=2 l= 0 prim: NULL
100:d=3 hl=3 l= 141 prim: BIT STRING
244:d=2 hl=2 l= 71 cons: cont [ 0 ]
246:d=3 hl=2 l= 31 cons: SEQUENCE
248:d=4 hl=2 l= 9 prim: OBJECT:challengePassword
259:d=4 hl=2 l= 18 cons: SET
261:d=5 hl=2 l= 16 prim: IA5STRING :test password!!!
279:d=3 hl=2 l= 36 cons: SEQUENCE
281:d=4 hl=2 l= 9 prim: OBJECT:unstructuredName
292:d=4 hl=2 l= 23 cons: SET
294:d=5 hl=2 l= 21 prim: PRINTABLESTRING :optional company name
317:d=1 hl=2 l= 13 cons: SEQUENCE
319:d=2 hl=2 l= 9 prim: OBJECT:sha1WithRSAEncryption
330:d=2 hl=2 l= 0 prim: NULL
332:d=1 hl=3 l= 129 prim: BIT STRING
arch [apps]$
So am I misinterpreting the RSA PKCS 9 spec, and that it actually
means that the challenge password must be a sequence of one object?
If that's the case, then the stack STACK_OF(ASN1_TYPE) *set in
X509_ATTRIBUTE should always have one element right?
A side question: what exactly does this which is wrong comment
mean? :)
typedef struct x509_attributes_st
...
int single; /* 0 for a set, 1 for a single item (which is wrong) */
union {
...
} X509_ATTRIBUTE;
Thanks.
_
It’s the same Hotmail®. If by “same” you mean up to 70% faster.
http://windowslive.com/online/hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_broad1_122008__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
signature failure when certificate contains no serial number (ie, not one that equals zero)?
i was messing around with (self-signed) certificate creation/signing and ran into this. the following two certificates are the same except for the serial number: with_serial has a serial number that is zero, and no_serial does not have any serial number. the with_serial certificate verifies ok, but the no_serial one fails verification with certificate signature failure. is this expected? if not, i thought the signing is applied to the entire blob of data, so with or without the serial number, the signing code wouldn't know or care to know, so it's probably not a signing problem. then is it a verification problem then? not that this is causing problems for me. just curious. thanks. arch [apps]$ ./openssl version OpenSSL 0.9.8g 19 Oct 2007 arch [apps]$ arch [apps]$ ./openssl verify -CAfile /tmp/with_serial.pem /tmp/with_serial.pem /tmp/with_serial.pem: OK arch [apps]$ arch [apps]$ ./openssl verify -CAfile /tmp/no_serial.pem /tmp/no_serial.pem /tmp/no_serial.pem: /CN=test error 7 at 0 depth lookup:certificate signature failure 15143:error:04077068:rsa routines:RSA_verify:bad signature:rsa_sign.c:235: 15143:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:168: arch [apps]$ arch [apps]$ ./openssl asn1parse -in /tmp/with_serial.pem 0:d=0 hl=4 l= 268 cons: SEQUENCE 4:d=1 hl=3 l= 183 cons: SEQUENCE 7:d=2 hl=2 l= 3 cons: cont [ 0 ] 9:d=3 hl=2 l= 1 prim: INTEGER :02 12:d=2 hl=2 l= 1 prim: INTEGER :00 15:d=2 hl=2 l= 13 cons: SEQUENCE 17:d=3 hl=2 l= 9 prim: OBJECT:sha1WithRSAEncryption 28:d=3 hl=2 l= 0 prim: NULL 30:d=2 hl=2 l= 15 cons: SEQUENCE 32:d=3 hl=2 l= 13 cons: SET 34:d=4 hl=2 l= 11 cons: SEQUENCE 36:d=5 hl=2 l= 3 prim: OBJECT:commonName 41:d=5 hl=2 l= 4 prim: PRINTABLESTRING :test 47:d=2 hl=2 l= 30 cons: SEQUENCE 49:d=3 hl=2 l= 13 prim: UTCTIME :040722175719Z 64:d=3 hl=2 l= 13 prim: UTCTIME :130123152135Z 79:d=2 hl=2 l= 15 cons: SEQUENCE 81:d=3 hl=2 l= 13 cons: SET 83:d=4 hl=2 l= 11 cons: SEQUENCE 85:d=5 hl=2 l= 3 prim: OBJECT:commonName 90:d=5 hl=2 l= 4 prim: PRINTABLESTRING :test 96:d=2 hl=2 l= 92 cons: SEQUENCE 98:d=3 hl=2 l= 13 cons: SEQUENCE 100:d=4 hl=2 l= 9 prim: OBJECT:rsaEncryption 111:d=4 hl=2 l= 0 prim: NULL 113:d=3 hl=2 l= 75 prim: BIT STRING 190:d=1 hl=2 l= 13 cons: SEQUENCE 192:d=2 hl=2 l= 9 prim: OBJECT:sha1WithRSAEncryption 203:d=2 hl=2 l= 0 prim: NULL 205:d=1 hl=2 l= 65 prim: BIT STRING arch [apps]$ arch [apps]$ ./openssl asn1parse -in /tmp/no_serial.pem 0:d=0 hl=4 l= 267 cons: SEQUENCE 4:d=1 hl=3 l= 182 cons: SEQUENCE 7:d=2 hl=2 l= 3 cons: cont [ 0 ] 9:d=3 hl=2 l= 1 prim: INTEGER :02 12:d=2 hl=2 l= 0 prim: INTEGER :00 14:d=2 hl=2 l= 13 cons: SEQUENCE 16:d=3 hl=2 l= 9 prim: OBJECT:sha1WithRSAEncryption 27:d=3 hl=2 l= 0 prim: NULL 29:d=2 hl=2 l= 15 cons: SEQUENCE 31:d=3 hl=2 l= 13 cons: SET 33:d=4 hl=2 l= 11 cons: SEQUENCE 35:d=5 hl=2 l= 3 prim: OBJECT:commonName 40:d=5 hl=2 l= 4 prim: PRINTABLESTRING :test 46:d=2 hl=2 l= 30 cons: SEQUENCE 48:d=3 hl=2 l= 13 prim: UTCTIME :040722175719Z 63:d=3 hl=2 l= 13 prim: UTCTIME :130123152135Z 78:d=2 hl=2 l= 15 cons: SEQUENCE 80:d=3 hl=2 l= 13 cons: SET 82:d=4 hl=2 l= 11 cons: SEQUENCE 84:d=5 hl=2 l= 3 prim: OBJECT:commonName 89:d=5 hl=2 l= 4 prim: PRINTABLESTRING :test 95:d=2 hl=2 l= 92 cons: SEQUENCE 97:d=3 hl=2 l= 13 cons: SEQUENCE 99:d=4 hl=2 l= 9 prim: OBJECT:rsaEncryption 110:d=4 hl=2 l= 0 prim: NULL 112:d=3 hl=2 l= 75 prim: BIT STRING 189:d=1 hl=2 l= 13 cons: SEQUENCE 191:d=2 hl=2 l= 9 prim: OBJECT:sha1WithRSAEncryption 202:d=2 hl=2 l= 0 prim: NULL 204:d=1 hl=2 l= 65 prim: BIT STRING arch [apps]$ arch [apps]$ cat /tmp/with_serial.pem -BEGIN CERTIFICATE- MIIBDDCBt6ADAgECAgEAMA0GCSqGSIb3DQEBBQUAMA8xDTALBgNVBAMTBHRlc3Qw HhcNMDQwNzIyMTc1NzE5WhcNMTMwMTIzMTUyMTM1WjAPMQ0wCwYDVQQDEwR0ZXN0 MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBALFAze8BSQUyQvvwbWw86Jh7wwOsTAMa cc8uKQ3ZCgR9CnsvMgsSfHR9XPLzcGkXwuUIDGQ8QWPqNp9g76xqy/kCAwEAATAN BgkqhkiG9w0BAQUFAANBAHtxTN9bC7jCJDs9iKBE7O2U4jMlLievUR3YgWsrfxVJ k1v/vXdL4H8/+QndErV8Bl8AavnsjQjFgfPiOs3pi70= -END CERTIFICATE- arch [apps]$ arch [apps]$ cat /tmp/no_serial.pem -BEGIN CERTIFICATE- MIIBCzCBtqADAgECAgAwDQYJKoZIhvcNAQEFBQAwDzENMAsGA1UEAxMEdGVzdDAe Fw0wNDA3MjIxNzU3MTlaFw0xMzAxMjMxNTIxMzVaMA8xDTALBgNVBAMTBHRlc3Qw XDANBgkqhkiG9w0BAQEFAANLADBIAkEAsUDN7wFJBTJC+/BtbDzomHvDA6xMAxpx zy4pDdkKBH0Key8yCxJ8dH1c8vNwaRfC5QgMZDxBY+o2n2DvrGrL+QIDAQABMA0G CSqGSIb3DQEBBQUAA0EAiWk2QM5lxijnjQE/D/tsoWf0LZvPIuPC7laTUFUrAIKr JbkAQ9rrf33pf+7JIhiJIgFxVVgOv2PXYKPWC7duUA== -END
RE: signature failure when certificate contains no serial number (ie, not one that equals zero)?
sorry please ignore; this had been asked before: http://www.mail-archive.com/openssl-users@openssl.org/msg41502.html From: [EMAIL PROTECTED] To: openssl-users@openssl.org Subject: signature failure when certificate contains no serial number (ie, not one that equals zero)? Date: Sat, 29 Dec 2007 21:05:02 + i was messing around with (self-signed) certificate creation/signing and ran into this. the following two certificates are the same except for the serial number: with_serial has a serial number that is zero, and no_serial does not have any serial number. the with_serial certificate verifies ok, but the no_serial one fails verification with certificate signature failure. is this expected? if not, i thought the signing is applied to the entire blob of data, so with or without the serial number, the signing code wouldn't know or care to know, so it's probably not a signing problem. then is it a verification problem then? not that this is causing problems for me. just curious. thanks. arch [apps]$ ./openssl version OpenSSL 0.9.8g 19 Oct 2007 arch [apps]$ arch [apps]$ ./openssl verify -CAfile /tmp/with_serial.pem /tmp/with_serial.pem /tmp/with_serial.pem: OK arch [apps]$ arch [apps]$ ./openssl verify -CAfile /tmp/no_serial.pem /tmp/no_serial.pem /tmp/no_serial.pem: /CN=test error 7 at 0 depth lookup:certificate signature failure 15143:error:04077068:rsa routines:RSA_verify:bad signature:rsa_sign.c:235: 15143:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:168: arch [apps]$ arch [apps]$ ./openssl asn1parse -in /tmp/with_serial.pem 0:d=0 hl=4 l= 268 cons: SEQUENCE 4:d=1 hl=3 l= 183 cons: SEQUENCE 7:d=2 hl=2 l= 3 cons: cont [ 0 ] 9:d=3 hl=2 l= 1 prim: INTEGER :02 12:d=2 hl=2 l= 1 prim: INTEGER :00 15:d=2 hl=2 l= 13 cons: SEQUENCE 17:d=3 hl=2 l= 9 prim: OBJECT :sha1WithRSAEncryption 28:d=3 hl=2 l= 0 prim: NULL 30:d=2 hl=2 l= 15 cons: SEQUENCE 32:d=3 hl=2 l= 13 cons: SET 34:d=4 hl=2 l= 11 cons: SEQUENCE 36:d=5 hl=2 l= 3 prim: OBJECT :commonName 41:d=5 hl=2 l= 4 prim: PRINTABLESTRING :test 47:d=2 hl=2 l= 30 cons: SEQUENCE 49:d=3 hl=2 l= 13 prim: UTCTIME :040722175719Z 64:d=3 hl=2 l= 13 prim: UTCTIME :130123152135Z 79:d=2 hl=2 l= 15 cons: SEQUENCE 81:d=3 hl=2 l= 13 cons: SET 83:d=4 hl=2 l= 11 cons: SEQUENCE 85:d=5 hl=2 l= 3 prim: OBJECT :commonName 90:d=5 hl=2 l= 4 prim: PRINTABLESTRING :test 96:d=2 hl=2 l= 92 cons: SEQUENCE 98:d=3 hl=2 l= 13 cons: SEQUENCE 100:d=4 hl=2 l= 9 prim: OBJECT :rsaEncryption 111:d=4 hl=2 l= 0 prim: NULL 113:d=3 hl=2 l= 75 prim: BIT STRING 190:d=1 hl=2 l= 13 cons: SEQUENCE 192:d=2 hl=2 l= 9 prim: OBJECT :sha1WithRSAEncryption 203:d=2 hl=2 l= 0 prim: NULL 205:d=1 hl=2 l= 65 prim: BIT STRING arch [apps]$ arch [apps]$ ./openssl asn1parse -in /tmp/no_serial.pem 0:d=0 hl=4 l= 267 cons: SEQUENCE 4:d=1 hl=3 l= 182 cons: SEQUENCE 7:d=2 hl=2 l= 3 cons: cont [ 0 ] 9:d=3 hl=2 l= 1 prim: INTEGER :02 12:d=2 hl=2 l= 0 prim: INTEGER :00 14:d=2 hl=2 l= 13 cons: SEQUENCE 16:d=3 hl=2 l= 9 prim: OBJECT :sha1WithRSAEncryption 27:d=3 hl=2 l= 0 prim: NULL 29:d=2 hl=2 l= 15 cons: SEQUENCE 31:d=3 hl=2 l= 13 cons: SET 33:d=4 hl=2 l= 11 cons: SEQUENCE 35:d=5 hl=2 l= 3 prim: OBJECT :commonName 40:d=5 hl=2 l= 4 prim: PRINTABLESTRING :test 46:d=2 hl=2 l= 30 cons: SEQUENCE 48:d=3 hl=2 l= 13 prim: UTCTIME :040722175719Z 63:d=3 hl=2 l= 13 prim: UTCTIME :130123152135Z 78:d=2 hl=2 l= 15 cons: SEQUENCE 80:d=3 hl=2 l= 13 cons: SET 82:d=4 hl=2 l= 11 cons: SEQUENCE 84:d=5 hl=2 l= 3 prim: OBJECT :commonName 89:d=5 hl=2 l= 4 prim: PRINTABLESTRING :test 95:d=2 hl=2 l= 92 cons: SEQUENCE 97:d=3 hl=2 l= 13 cons: SEQUENCE 99:d=4 hl=2 l= 9 prim: OBJECT :rsaEncryption 110:d=4 hl=2 l= 0 prim: NULL 112:d=3 hl=2 l= 75 prim: BIT STRING 189:d=1 hl=2 l= 13 cons: SEQUENCE 191:d=2 hl=2 l= 9 prim: OBJECT :sha1WithRSAEncryption 202:d=2 hl=2 l= 0 prim: NULL 204:d=1 hl=2 l= 65 prim: BIT STRING arch [apps]$ arch [apps]$ cat /tmp/with_serial.pem -BEGIN CERTIFICATE- MIIBDDCBt6ADAgECAgEAMA0GCSqGSIb3DQEBBQUAMA8xDTALBgNVBAMTBHRlc3Qw HhcNMDQwNzIyMTc1NzE5WhcNMTMwMTIzMTUyMTM1WjAPMQ0wCwYDVQQDEwR0ZXN0 MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBALFAze8BSQUyQvvwbWw86Jh7wwOsTAMa cc8uKQ3ZCgR9CnsvMgsSfHR9XPLzcGkXwuUIDGQ8QWPqNp9g76xqy/kCAwEAATAN BgkqhkiG9w0BAQUFAANBAHtxTN9bC7jCJDs9iKBE7O2U4jMlLievUR3YgWsrfxVJ k1v/vXdL4H8/+QndErV8Bl8AavnsjQjFgfPiOs3pi70= -END CERTIFICATE- arch [apps]$ arch [apps]$ cat /tmp/no_serial.pem -BEGIN CERTIFICATE- MIIBCzCBtqADAgECAgAwDQYJKoZIhvcNAQEFBQAwDzENMAsGA1UEAxMEdGVzdDAe Fw0wNDA3MjIxNzU3MTlaFw0xMzAxMjMxNTIxMzVaMA8xDTALBgNVBAMTBHRlc3Qw XDANBgkqhkiG9w0BAQEFAANLADBIAkEAsUDN7wFJBTJC+/BtbDzomHvDA6xMAxpx zy4pDdkKBH0Key8yCxJ8dH1c8vNwaRfC5QgMZDxBY+o2n2DvrGrL+QIDAQABMA0G CSqGSIb3DQEBBQUAA0EAiWk2QM5lxijnjQE/D/tsoWf0LZvPIuPC7laTUFUrAIKr JbkAQ9rrf33pf+7JIhiJIgFxVVgOv2PXYKPWC7duUA== -END CERTIFICATE- arch [apps]$ arch [apps]$ ./openssl x509 -noout -fingerprint -in
Re: CA generation/certificate serial number
nils
Frédéric Donnat wrote:
Hi,
Sorry for the mistake (nothing to deal with openssl.cnf file). I was just
looking for ca.txt file.
Is it normal behavior of openssl to be able to view a certificate without
serial number using (without any error mentioned):
openssl x509 -in some_cert_without_sn.pem -text
But to be unable to verify it using:
openssl verify -CAfile some_cert_without_sn.pem some_cert_without_sn.pem
Sample: (attached self-sign cert name pipo-bad.pem)
hmm, the attached certificate as has a serial number it's 0x0
actually the attachment
http://www.mail-archive.com/openssl-users@openssl.org/msg41447/pipo-bad.pem
does not have a serial number; that field is has lenght of zero:
0:d=0 hl=4 l= 546 cons: SEQUENCE
4:d=1 hl=4 l= 395 cons: SEQUENCE
8:d=2 hl=2 l= 3 cons: cont [ 0 ]
10:d=3 hl=2 l= 1 prim: INTEGER :02
13:d=2 hl=2 l= 0 prim: INTEGER :00
15:d=2 hl=2 l= 13 cons: SEQUENCE
17:d=3 hl=2 l= 9 prim: OBJECT:md5WithRSAEncryption
similar to the certificate i posted in the signature failure when certificate
contains no serial number (ie, not one that equals zero)? thread:
arch [apps]$ cat /tmp/no_serial.pem
-BEGIN CERTIFICATE-
MIIBCzCBtqADAgECAgAwDQYJKoZIhvcNAQEFBQAwDzENMAsGA1UEAxMEdGVzdDAe
Fw0wNDA3MjIxNzU3MTlaFw0xMzAxMjMxNTIxMzVaMA8xDTALBgNVBAMTBHRlc3Qw
XDANBgkqhkiG9w0BAQEFAANLADBIAkEAsUDN7wFJBTJC+/BtbDzomHvDA6xMAxpx
zy4pDdkKBH0Key8yCxJ8dH1c8vNwaRfC5QgMZDxBY+o2n2DvrGrL+QIDAQABMA0G
CSqGSIb3DQEBBQUAA0EAiWk2QM5lxijnjQE/D/tsoWf0LZvPIuPC7laTUFUrAIKr
JbkAQ9rrf33pf+7JIhiJIgFxVVgOv2PXYKPWC7duUA==
-END CERTIFICATE-
0:d=0 hl=4 l= 267 cons: SEQUENCE
4:d=1 hl=3 l= 182 cons: SEQUENCE
7:d=2 hl=2 l= 3 cons: cont [ 0 ]
9:d=3 hl=2 l= 1 prim: INTEGER :02
12:d=2 hl=2 l= 0 prim: INTEGER :00
14:d=2 hl=2 l= 13 cons: SEQUENCE
16:d=3 hl=2 l= 9 prim: OBJECT:sha1WithRSAEncryption
[EMAIL PROTECTED] simple]$ LD_LIBRARY_PATH=/usr/local/ossl-0.9.8/lib
/usr/local/ossl-0.9.8/bin/openssl verify -verbose -CAfile pipo-bad.pem
pipo-bad.pem
pipo-bad.pem: /C=UK/CN=OpenSSL Group
error 7 at 0 depth lookup:certificate signature failure
18588:error:04077068:rsa routines:RSA_verify:bad signature:rsa_sign.c:218:
18588:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP
lib:a_verify.c:168:
well the signature really seems to be wrong. How did you create
the certificate ?
as to how i generated the certificate with no serial number, i simply commented
out the code and ran ./openssl req without specifying -set_serial:
arch [apps]$ diff -u req.c.BAK req.c
--- req.c.BAK 2007-12-29 12:26:41.0 -0800
+++ req.c 2007-12-29 12:39:11.0 -0800
@@ -937,16 +937,18 @@
{
if (!X509_set_serialNumber(x509ss, serial))
goto end;
}
- else
- {
- if (!rand_serial(NULL,
- X509_get_serialNumber(x509ss)))
- goto end;
- }
if (!X509_set_issuer_name(x509ss,
X509_REQ_get_subject_name(req))) goto end;
again, this is not causing any problems for me, just curious.
thanks.
Cheers,
Nils
_
The best games are on Xbox 360. Click here for a special offer on an Xbox 360
Console.
http://www.xbox.com/en-US/hardware/wheretobuy/__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
