RE: Can't recognize intermediate CA
Giang Nguyen
> I used openssl with the intermediate CA to sign a separate cert=2C which
> had a AKID keyid but no issuer=2C 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=2C 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=2C X509_get_issuer_name(issuer)))
return X509_V_ERR_AKID_ISSUER_SERIAL_MISMATCH=3B
nm is the DirName thing in the subject cert's AKID=2C ie "/O=3DWatchGuard_T=
echnologies/OU=3DFireware/CN=3DResigning_CA"
and "issuer" is the intermediate CA cert=2C so its "X509_get_issuer_name(is=
suer)" will be name of root CA.
so the comparsion will fail=2C and you get the error.
looks like it should be "X509_get_subject_name(issuer)"
_________________________________________________________________
Windows Live=99 Groups: Create an online spot for your favorite groups to m=
eet.
http://windowslive.com/online/groups?ocid=3DTXT_TAGLM_WL_groups_032009=
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openss...@openssl.org
Automated List Manager majo...@openssl.org
Giang Nguyen
>> I used openssl with the intermediate CA to sign a separate cert=2C which
>> had a AKID keyid but no issuer=2C 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=2C 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=2C X509_get_issuer_name(issuer)))
> return X509_V_ERR_AKID_ISSUER_SERIAL_MISMATCH=3B
>
_Technologies/OU=3DFireware/CN=3DResigning_CA"
> and "issuer" is the intermediate CA cert=2C so its "X509_get_issuer_name(=
issuer)" will be name of root CA.
> so the comparsion will fail=2C 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=3DUS/ST=3DCalifornia/L=3DSanta Clara/O=3DYahoo! Inc./OU=3DYah=
oo/CN=3Dlogin.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=2C Inc.
License GPLv3+: GNU GPL version 3 or later=20
This is free software: you are free to change and redistribute it.
There is NO WARRANTY=2C 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=2C line 630.
(gdb) b v3_purp.c:651
Breakpoint 2 at 0x812d186: file v3_purp.c=2C line 651.
(gdb) r
Starting program: ./openssl verify -CApath cas yahoo.pem
Breakpoint 2=2C X509_check_issued (issuer=3D0x8204e68=2C subject=3D0x820476=
0) at v3_purp.c:651
651 return X509_V_ERR_AKID_ISSUER_SERIA=
L_MISMATCH=3B
(gdb) p nm
$1 =3D (X509_NAME *) 0x820bf18
(gdb) p X509_NAME_oneline(nm=2C0=2C0)
$2 =3D 0x820c0f8 "/O=3DWatchGuard_Technologies/OU=3DFireware/CN=3DResigning=
_CA"
(gdb) p issuer
$3 =3D (X509 *) 0x8204e68
(gdb) set nm=3DX509_get_issuer_name(issuer)
(gdb) p nm
$4 =3D (X509_NAME *) 0x8206310
(gdb) p X509_NAME_oneline(nm=2C0=2C0)
$5 =3D 0x820c208 "/C=3DUS/ST=3DWashington/O=3DFoobar/OU=3Dfoobar/CN=3DFoo B=
. Ar/emailAddress=3D...@bar.com"
(gdb) set nm=3DX509_get_subject_name(issuer)
(gdb) p nm
$6 =3D (X509_NAME *) 0x82083b0
(gdb) p X509_NAME_oneline(nm=2C0=2C0)
$7 =3D 0x820c318 "/O=3DWatchGuard_Technologies/OU=3DFireware/CN=3DResigning=
_CA"
(gdb)
_________________________________________________________________
Windows Live=99: Life without walls.
http://windowslive.com/explore?ocid=3DTXT_TAGLM_WL_allup_1a_explore_032009=
Rene Hollan
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.
=20
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-ope...@openssl.org
[mailto:owner-ope...@openssl.org] On Behalf Of Giang Nguyen
Sent: Thursday, March 12, 2009 4:56 PM
To: openss...@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=20
> 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=3DWatchGuard_Technologies/OU=3DFireware/CN=3DResigning_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=3DTXT_TAGLM_WL_groups_032009___=
_
Dr. Stephen Henson
> 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
Giang Nguyen
Sincerely=2C
Giang Nguyen
----------------------------------------
> Date: Fri=2C 13 Mar 2009 00:22:56 +0100
> From: st...@openssl.org
> To: openss...@openssl.org
> Subject: Re: Can't recognize intermediate CA
>
> On Thu=2C Mar 12=2C 2009=2C Rene Hollan wrote:
>
>> Yeah=2C I just noticed that.
>>
>> I've been comparing how my intermediate CA resigned an existing cert
>> (it's part of a proxy that decrypts=2C examines=2C 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=2C along with the issuer serial number.
>> When the issuer is a root ca=2C it is it's own issuer=2C so the issuer
>> (which is what my resigning code was using)=2C and issuer's issuer are t=
he
>> same. But=2C when the issuer is an intermediate CA=2C they are different=
.
>>
>> So=2C either I'm doing it wrong=2C or OpenSSL ca ... Is doing it wrong (=
but
>> consistent with how OpenSSL verify ... checks).
>>
>> At this point=2C I think the error is mine. At least browsers accept the
>> cert when OpenSSL signs it with an intermediate CA=2C and not when I do.
>>
>> Think about it: the purpose of the AKID is to identify the public key of
>> the signer=2C either by matching the SKID of the signer=2C or some other
>> means of identifying the signer. Well=2C the signer's serial number is
>> unique within those issued by IT'S signer=2C 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=2C but the combination of issuer's
>> issuer DN=2C and issuer's serial number within the issuer's issuer's DN
>> are statistically more so. (Without SKID/AKID=2C one would have to verif=
y
>> a prospective issuer by unhashing the signature with the issuer's public
>> key=2C which is arguably more computationally expensive that comparing
>> SKID and AKID. One should still do this anyway=2C but the SKID/AKID chec=
k
>> preemptively eliminates the wrong issuer).
>>
>> Sigh. X500 looks like a royal "designed by non-technical committee"
>> mess.
>>
>> Thanks for the help=2C now excuse me while I make a code change.
>>
>
> If it's any consolation you aren't alone with that=2C it gets commented o=
n quite
> often so much so in fact that it has an FAQ entry:
>
> http://www.openssl.org/support/faq.html#USER15
doh=2C that makes sense! thanks.
_________________________________________________________________
Hotmail=AE is up to 70% faster. Now good news travels really fast.=20
http://windowslive.com/online/hotmail?ocid=3DTXT_TAGLM_WL_HM_70faster_03200=
9=
Rene Hollan
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-ope...@openssl.org
[mailto:owner-ope...@openssl.org] On Behalf Of Dr. Stephen Henson
Sent: Thursday, March 12, 2009 4:23 PM
To: openss...@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
Rene Hollan
doesn't have a SKID, AKID issuer/serial takes the place of an AKID
keyid.
-----Original Message-----
From: owner-ope...@openssl.org
[mailto:owner-ope...@openssl.org] On Behalf Of Dr. Stephen Henson
Sent: Thursday, March 12, 2009 4:23 PM
To: openss...@openssl.org
Subject: Re: Can't recognize intermediate CA
Rene Hollan
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. :-(
=20
-----Original Message-----
From: Rene Hollan=20
Sent: Thursday, March 12, 2009 5:39 PM
To: 'openss...@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-ope...@openssl.org
[mailto:owner-ope...@openssl.org] On Behalf Of Dr. Stephen Henson
Sent: Thursday, March 12, 2009 4:23 PM
To: openss...@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
Rene Hollan
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).
Kyle Hamilton
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=3D1
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....@watchguard.com> w=
rote:
> =C2=A0Yup. 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-ope...@openssl.org
> [mailto:owner-ope...@openssl.org] On Behalf Of Dr. Stephen Henson
> Sent: Thursday, March 12, 2009 4:23 PM
> To: openss...@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 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.openssl.=
org
> User Support Mailing List =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0opens...@openssl.org
> Automated List Manager =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 majo...@openssl.org
> ______________________________________________________________________
> OpenSSL Project =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.openssl.=
org
> User Support Mailing List =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0opens...@openssl.org
> Automated List Manager =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 majo...@openssl.org
Kyle Hamilton
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....@watchguard.com> w=
rote:
> 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: 'openss...@openssl.org'
> Subject: RE: Can't recognize intermediate CA
>
> =C2=A0Sigh.
>
> 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: 'openss...@openssl.org'
Dr. Stephen Henson
> 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
______________________________________________________________________
Dr. Stephen Henson
> 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.