Re: Can't recognize intermediate CA
The NSS developers (NSS being the library that Firefox uses) have discussed the concept of OpenSSL's overspecified Authority Key Identifier numerous times. Most recently, http://groups.google.com/group/mozilla.dev.tech.crypto/msg/2ac539b4447c58cd?pli=1 has the main NSS developer's (Nelson Bolyard) thoughts on the matter. -Kyle H On Thu, Mar 12, 2009 at 5:39 PM, Rene Hollan rene.hol...@watchguard.com wrote: Yup. That fixed it.. At least as far as openssl verify -CAfile cacert.pem -untrusted intcert2.pem yahoo-x.pem goes. Oddly, firefox still rejects the end cert, even though both cacert.pem and intcert2.pem are in it's trust store. Is it possible that browsers actually ignore intermediate CA certs in their trust store and expect servers to provide them? That's the next thing for me to try (if only I can remember how to do that with openssl... :-)). -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dr. Stephen Henson Sent: Thursday, March 12, 2009 4:23 PM To: openssl-users@openssl.org Subject: Re: Can't recognize intermediate CA 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 You can just leave out the issuer+serial number combination from AKID too. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-us...@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-us...@openssl.org Automated List Manager majord...@openssl.org __ 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
Actually, in addition to the last link I gave, http://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/31fe9768dcb00b2c/7fab610c48b40a9c?#7fab610c48b40a9c has a link to the entire thread (which includes a couple more questions and answers). http://is.gd/n9o4 is a short redirect to that URL. -Kyle H On Thu, Mar 12, 2009 at 7:31 PM, Rene Hollan rene.hol...@watchguard.com wrote: Great, just great. My changes worked for IE, but not for Firefox. Apparently, Firefox does more stringent checking that IE, and indeed, than OpenSSL s_client ... (which gives a nice cert chain). -Original Message- From: Rene Hollan Sent: Thursday, March 12, 2009 6:34 PM To: 'openssl-users@openssl.org' Subject: RE: Can't recognize intermediate CA Sigh. Well, I added the intermediate CA to the cert chain sent by my proxy (and verified this with wireshark). OpenSSL s_client -CAfile cacert.pem -host login.yahoo.com -port 443 works and shows the trust chain. But, Firefox, with cacert.pem loaded into it's trust store still complains. :-( -Original Message- From: Rene Hollan Sent: Thursday, March 12, 2009 5:39 PM To: 'openssl-users@openssl.org' Subject: RE: Can't recognize intermediate CA Yup. That fixed it.. At least as far as openssl verify -CAfile cacert.pem -untrusted intcert2.pem yahoo-x.pem goes. Oddly, firefox still rejects the end cert, even though both cacert.pem and intcert2.pem are in it's trust store. Is it possible that browsers actually ignore intermediate CA certs in their trust store and expect servers to provide them? That's the next thing for me to try (if only I can remember how to do that with openssl... :-)). -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dr. Stephen Henson Sent: Thursday, March 12, 2009 4:23 PM To: openssl-users@openssl.org Subject: Re: Can't recognize intermediate CA 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 You can just leave out the issuer+serial number combination from AKID too. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-us...@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-us...@openssl.org Automated List Manager majord...@openssl.org __ 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
On Thu, Mar 12, 2009, Rene Hollan wrote: Yup. That fixed it.. At least as far as openssl verify -CAfile cacert.pem -untrusted intcert2.pem yahoo-x.pem goes. Oddly, firefox still rejects the end cert, even though both cacert.pem and intcert2.pem are in it's trust store. Is it possible that browsers actually ignore intermediate CA certs in their trust store and expect servers to provide them? That's the next thing for me to try (if only I can remember how to do that with openssl... :-)). Well if you had to add intermediate CAs to browser trust stores they would be of limimted use. The whole idea is that you only need to add the root CA and the browser will automatically trust intermediate CAs it hasn't seen before. The SSL/TLS standards also require sending of the certificate chain (but the root can be excluded). Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Homepage: http://www.drh-consultancy.demon.co.uk __ 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
On Thu, Mar 12, 2009, Rene Hollan wrote: True, but (a) it doesn't hurt to have both, and (b) if the issuer doesn't have a SKID, AKID issuer/serial takes the place of an AKID keyid. The disadvantage is that if you want to support more than one intermediate CA (cross certification for example) and you have issuer+serial in AKID then you'll get a mismatch with any new CA. This has caused issues when some people had an intermediate CA expire before the EE cert. Technically AKID/SKID should just be a hint as to the correct issuer certificate which can be ignored but some software (including OpenSSL currently) requires a match. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Homepage: http://www.drh-consultancy.demon.co.uk __ 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
Yeah, I realized that. I changed things to include an AKID if the issuer has a SKID, and the issuer's issuer's subject DN and issuer's serial number if not. Got it all working finally, once I had the proxy chain it's intermediate CA. (When it wasn't doing this, I thought to try to add it to the trusted store of the browser, realizing that defeated the purpose of an intermediate CA, but wanted to test. That didn't work, but likely because I forgot the tell the browser what the trust chain rooted at the root CA was FOR.) -Original Message- From: owner-openssl-us...@openssl.org on behalf of Dr. Stephen Henson Sent: Fri 3/13/2009 5:14 AM To: openssl-users@openssl.org Subject: Re: Can't recognize intermediate CA On Thu, Mar 12, 2009, Rene Hollan wrote: True, but (a) it doesn't hurt to have both, and (b) if the issuer doesn't have a SKID, AKID issuer/serial takes the place of an AKID keyid. The disadvantage is that if you want to support more than one intermediate CA (cross certification for example) and you have issuer+serial in AKID then you'll get a mismatch with any new CA. This has caused issues when some people had an intermediate CA expire before the EE cert. Technically AKID/SKID should just be a hint as to the correct issuer certificate which can be ignored but some software (including OpenSSL currently) requires a match. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org winmail.dat
RE: Can't recognize intermediate CA
Corrected 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 MRUwEwYDVQQDFgxSZXNpZ25pbmdfQ0GCCQCLda47dCCwQDANBgkqhkiG9w0BAQUF AAOCAQEAMS8EfpQrc/5ymRU4bMH8zg/ADJ2mAk8+BsHMBIaWBMDycVHMJUImmnfD PXFOS7+XnDLE7fVwgiNcY/k7223s6BMI/AMmtBg8qm7sR9V+7fv9Jq7BGWgmUPdG BkqWYmfsd2uVei/rZchAvGiFc4hEVbt7s6pazASAFYN/RectfQtx8LBdJVC78SfF DuO+l/hclIGJec5uzlpCenVydGVgToddvpV7Qg4Z+Rap2xiXx63KugGSRjA/1tnR sQ2OcZejF/Kjh7SHmM/NHIfSuraWJcayb4njNt8vKRYazfiFF8G2O7cOOe674KM9 TpMPay5Ei0HMRb1uQjRaFmxVd1RoKw== -END CERTIFICATE- -Original Message- From: Rene Hollan Sent: Thursday, March 12, 2009 3:01 PM To: 'openssl-users@openssl.org' Subject: Can't recognize intermediate CA 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
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 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). -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 NQxsY8NqwWswXHtRLLWJgAzZKWeN1PYMGgRmmGaH2lPYGT0xcpRuZfhTE5HlJ9VC B3hV3JMD+VzPTzzcFm3gCCyR+dgNI0FmpoxtJzlirVj4BjHqTl+v4uhaX/wCgBvz QcAWftj4GiemnficByogBS3QdbDwQGephQX2qySXzv0o8+qOV+RNMdPHH1T4o/tN mjwXr099i5XcIvlfR9v677Q= -END CERTIFICATE- Yahoo.pem: -BEGIN CERTIFICATE- MIIDojCCAoqgAwIBAgIYANIyCa0j0xQjIXTkDX+dYhOXhmM6BaBMMA0GCSqGSIb3
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
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. -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Giang Nguyen Sent: Thursday, March 12, 2009 4:56 PM To: openssl-users@openssl.org Subject: 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(tm) 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 __ 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
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 You can just leave out the issuer+serial number combination from AKID too. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Homepage: http://www.drh-consultancy.demon.co.uk __ 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: Can't recognize intermediate CA
Yup. That fixed it.. At least as far as openssl verify -CAfile cacert.pem -untrusted intcert2.pem yahoo-x.pem goes. Oddly, firefox still rejects the end cert, even though both cacert.pem and intcert2.pem are in it's trust store. Is it possible that browsers actually ignore intermediate CA certs in their trust store and expect servers to provide them? That's the next thing for me to try (if only I can remember how to do that with openssl... :-)). -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dr. Stephen Henson Sent: Thursday, March 12, 2009 4:23 PM To: openssl-users@openssl.org Subject: Re: Can't recognize intermediate CA 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 You can just leave out the issuer+serial number combination from AKID too. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ 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
True, but (a) it doesn't hurt to have both, and (b) if the issuer doesn't have a SKID, AKID issuer/serial takes the place of an AKID keyid. -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dr. Stephen Henson Sent: Thursday, March 12, 2009 4:23 PM To: openssl-users@openssl.org Subject: Re: Can't recognize intermediate CA You can just leave out the issuer+serial number combination from AKID too. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ 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
Sigh. Well, I added the intermediate CA to the cert chain sent by my proxy (and verified this with wireshark). OpenSSL s_client -CAfile cacert.pem -host login.yahoo.com -port 443 works and shows the trust chain. But, Firefox, with cacert.pem loaded into it's trust store still complains. :-( -Original Message- From: Rene Hollan Sent: Thursday, March 12, 2009 5:39 PM To: 'openssl-users@openssl.org' Subject: RE: Can't recognize intermediate CA Yup. That fixed it.. At least as far as openssl verify -CAfile cacert.pem -untrusted intcert2.pem yahoo-x.pem goes. Oddly, firefox still rejects the end cert, even though both cacert.pem and intcert2.pem are in it's trust store. Is it possible that browsers actually ignore intermediate CA certs in their trust store and expect servers to provide them? That's the next thing for me to try (if only I can remember how to do that with openssl... :-)). -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dr. Stephen Henson Sent: Thursday, March 12, 2009 4:23 PM To: openssl-users@openssl.org Subject: Re: Can't recognize intermediate CA 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 You can just leave out the issuer+serial number combination from AKID too. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ 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
Great, just great. My changes worked for IE, but not for Firefox. Apparently, Firefox does more stringent checking that IE, and indeed, than OpenSSL s_client ... (which gives a nice cert chain). -Original Message- From: Rene Hollan Sent: Thursday, March 12, 2009 6:34 PM To: 'openssl-users@openssl.org' Subject: RE: Can't recognize intermediate CA Sigh. Well, I added the intermediate CA to the cert chain sent by my proxy (and verified this with wireshark). OpenSSL s_client -CAfile cacert.pem -host login.yahoo.com -port 443 works and shows the trust chain. But, Firefox, with cacert.pem loaded into it's trust store still complains. :-( -Original Message- From: Rene Hollan Sent: Thursday, March 12, 2009 5:39 PM To: 'openssl-users@openssl.org' Subject: RE: Can't recognize intermediate CA Yup. That fixed it.. At least as far as openssl verify -CAfile cacert.pem -untrusted intcert2.pem yahoo-x.pem goes. Oddly, firefox still rejects the end cert, even though both cacert.pem and intcert2.pem are in it's trust store. Is it possible that browsers actually ignore intermediate CA certs in their trust store and expect servers to provide them? That's the next thing for me to try (if only I can remember how to do that with openssl... :-)). -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dr. Stephen Henson Sent: Thursday, March 12, 2009 4:23 PM To: openssl-users@openssl.org Subject: Re: Can't recognize intermediate CA 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 You can just leave out the issuer+serial number combination from AKID too. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
