[78924] in cryptography@c2.net mail archive
Re: OT: SSL certificate chain problems
daemon@ATHENA.MIT.EDU (Arun Varghese)
Mon Feb 5 16:42:49 2007
In-Reply-To: <20070204071530.GE7807@piias899.ms.com>
To: Victor Duchovni <Victor.Duchovni@MorganStanley.com>
Cc: cryptography@metzdowd.com,
owner-cryptography@metzdowd.com
From: Arun Varghese <arun.varghese@nxp.com>
Date: Mon, 5 Feb 2007 11:45:45 +0530
This is a multipart message in MIME format.
--=_alternative 0021E8A065257279_=
Content-Type: text/plain; charset="US-ASCII"
Hi all,
I am looking for some information related to PKCS #15, especially the
"HOWTO" of setting up the file structures and security data management (on
IC Cards or "smart cards").
Any relevant pointers towards this please share here, thanks!
Best Regards,
Arun Varghese,
NXP Software, Block C, 4th Floor
MFAR Manyata Tech Park
Nagavara, Bangalore-560045
Tel : +91 80 4026 7000 Extn: 7817
Fax : +91 80 4026 7855
E-mail:arun.varghese@nxp.com,
www.software.nxp.com
The information contained in this message is confidential and may be
legally privileged. The message is intended solely for the addressee(s).
If you are not the intended recipient, you are hereby notified that any
use, dissemination, or reproduction is strictly prohibited and may be
unlawful. If you are not the intended recipient, please contact the sender
by return e-mail and destroy all copies of the original message.
Victor Duchovni <Victor.Duchovni@MorganStanley.com>
Sent by:
owner-cryptography@metzdowd.com
2007-02-04 12:45 PM
To
cryptography@metzdowd.com
cc
Subject
Re: OT: SSL certificate chain problems
Classification
On Wed, Jan 31, 2007 at 01:57:04PM +1300, Peter Gutmann wrote:
> Victor Duchovni <Victor.Duchovni@MorganStanley.com> writes:
>
> >What I don't understand is how the old (finally expired) root helps to
> >validate the new unexpired root, when a verifier has the old root and
the
> >server presents the new root in its trust chain.
>
> You use the key in the old root to validate the self-signature in the
new
> root. Since they're the same key, you know that the new root supersedes
the
> expired one.
Does this actually work with OpenSSL and v3 CA certs that have "X509v3
Authority Key Identifier" extensions? With these extensions present
(default when OpenSSL constructs CA certs, ...), certs whose serial number
does not match the "serial" field in the extension are not considered
to be root CA certs (not self-signed), and CA certs sharing the same
keys and DN, but carrying different serials, simply don't match.
If I roll-back the serial numbers and issue a cert with all the details
(including serial number, ...) the same, but just the start/end dates
changed to start before the expiration of the verifier's expired CA,
and end after today's date, the verifier ends up with a trust chain that
starts with the expired cert and fails, regardless of whether the server
sends the new root CA cert or not.
CA0.pem:
--------
serial=C27B874157E381C0
issuer= <fixed-ca-dn>
subject= <fixed-ca-dn>
notBefore=Jan 1 00:00:00 2007 GMT
notAfter=Jan 31 00:00:00 2007 GMT
...
X509v3 Authority Key Identifier:
keyid:CB:C0:45:68:F9:B0:DF:8B:A9:E9:EA:A0:F1:93:A1:C1:6B:7C:96:E4
DirName:<fixed-ca-dn>
serial:C2:7B:87:41:57:E3:81:C0
CA1.pem:
--------
serial=C27B874157E381C0
issuer= <fixed-ca-dn>
subject= <fixed-ca-dn>
notBefore=Jan 15 00:00:00 2007 GMT
notAfter=Feb 28 00:00:00 2007 GMT
...
X509v3 Authority Key Identifier:
keyid:CB:C0:45:68:F9:B0:DF:8B:A9:E9:EA:A0:F1:93:A1:C1:6B:7C:96:E4
DirName:<fixed-ca-dn>
serial:C2:7B:87:41:57:E3:81:C0
SRV.pem:
---------
serial=C27B874157E381C1
issuer= <fixed-ca-dn>
subject= <server-dn>
notBefore=Jan 15 00:00:00 2007 GMT
notAfter=Feb 28 00:00:00 2007 GMT
...
X509v3 Authority Key Identifier:
keyid:CB:C0:45:68:F9:B0:DF:8B:A9:E9:EA:A0:F1:93:A1:C1:6B:7C:96:E4
DirName:<fixed-ca-dn>
serial:C2:7B:87:41:57:E3:81:C0
A client with CAfile containing just "CA0.pem" fails to verify a server
configured to send the SRV,CA1 trust chain. My verification callback is
called three times and produces:
Trace: certificate verification depth=1 verify=0 subject=<fixed-ca-dn>
Error: CA certificate verification failed for <peer> certificate has
expired
Trace: certificate verification depth=1 verify=1 subject=<fixed-ca-dn>
Trace: certificate verification depth=0 verify=1 subject=<server-dn>
If the verifier trusts the "CA1.pem" cert, I see instead:
Trace: certificate verification depth=1 verify=1 subject=<fixed-ca-dn>
Trace: certificate verification depth=0 verify=1
subject=<fixed-server-dn>
How does one construct a working (re-issued root CA) example with OpenSSL?
Am I setting this up incorrectly, or does OpenSSL not in fact support
establishing trust in re-issued root CA via now expired root CAs?
I have not tried to do this without the "issuer key identifier" extension,
but don't really expect to find anything different...
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security, sender. Sender does not waive
/ \ HTML MAIL Morgan Stanley confidentiality or privilege,
and use is prohibited.
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to
majordomo@metzdowd.com
--=_alternative 0021E8A065257279_=
Content-Type: text/html; charset="US-ASCII"
<br><font size=2 face="sans-serif">Hi all,</font>
<br>
<br><font size=2 face="sans-serif">I am looking for some information related
to PKCS #15, especially the "HOWTO" of setting up the file structures
and security data management (on IC Cards or "smart cards").
</font>
<br><font size=2 face="sans-serif">Any relevant pointers towards this please
share here, thanks!</font>
<br>
<br>
<br><font size=2 face="sans-serif"><br>
Best Regards,<br>
<br>
Arun Varghese,<br>
NXP Software, Block C, 4th Floor<br>
MFAR Manyata Tech Park<br>
Nagavara, Bangalore-560045<br>
Tel : +91 80 4026 7000 Extn: 7817<br>
Fax : +91 80 4026 7855<br>
E-mail:arun.varghese@nxp.com, <br>
www.software.nxp.com<br>
<br>
The information contained in this message is confidential and may be legally
privileged. The message is intended solely for the addressee(s). If you
are not the intended recipient, you are hereby notified that any use, dissemination,
or reproduction is strictly prohibited and may be unlawful. If you are
not the intended recipient, please contact the sender by return e-mail
and destroy all copies of the original message. <br>
</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=33%>
<br>
<br>
<br>
<br>
<br><font size=1 face="sans-serif"><b>Victor Duchovni <Victor.Duchovni@MorganStanley.com></b>
</font>
<p><font size=1 face="sans-serif">Sent by:</font>
<br><font size=1 face="sans-serif">owner-cryptography@metzdowd.com</font>
<p><font size=1 face="sans-serif">2007-02-04 12:45 PM</font>
<td width=66%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif">cryptography@metzdowd.com</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">Re: OT: SSL certificate chain problems</font>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">Classification</font></div>
<td></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<div align=right>
<br></div></table>
<br>
<br>
<br><font size=2><tt>On Wed, Jan 31, 2007 at 01:57:04PM +1300, Peter Gutmann
wrote:<br>
<br>
> Victor Duchovni <Victor.Duchovni@MorganStanley.com> writes:<br>
> <br>
> >What I don't understand is how the old (finally expired) root
helps to<br>
> >validate the new unexpired root, when a verifier has the old root
and the<br>
> >server presents the new root in its trust chain.<br>
> <br>
> You use the key in the old root to validate the self-signature in
the new<br>
> root. Since they're the same key, you know that the new root
supersedes the<br>
> expired one.<br>
<br>
Does this actually work with OpenSSL and v3 CA certs that have "X509v3<br>
Authority Key Identifier" extensions? With these extensions present<br>
(default when OpenSSL constructs CA certs, ...), certs whose serial number<br>
does not match the "serial" field in the extension are not considered<br>
to be root CA certs (not self-signed), and CA certs sharing the same<br>
keys and DN, but carrying different serials, simply don't match.<br>
<br>
If I roll-back the serial numbers and issue a cert with all the details<br>
(including serial number, ...) the same, but just the start/end dates<br>
changed to start before the expiration of the verifier's expired CA,<br>
and end after today's date, the verifier ends up with a trust chain that<br>
starts with the expired cert and fails, regardless of whether the server<br>
sends the new root CA cert or not.<br>
<br>
CA0.pem:<br>
--------<br>
serial=C27B874157E381C0<br>
issuer= <fixed-ca-dn><br>
subject= <fixed-ca-dn><br>
notBefore=Jan 1 00:00:00 2007 GMT<br>
notAfter=Jan 31 00:00:00 2007 GMT<br>
...<br>
X509v3 Authority Key Identifier:<br>
keyid:CB:C0:45:68:F9:B0:DF:8B:A9:E9:EA:A0:F1:93:A1:C1:6B:7C:96:E4<br>
DirName:<fixed-ca-dn><br>
serial:C2:7B:87:41:57:E3:81:C0<br>
<br>
CA1.pem:<br>
--------<br>
serial=C27B874157E381C0<br>
issuer= <fixed-ca-dn><br>
subject= <fixed-ca-dn><br>
notBefore=Jan 15 00:00:00 2007 GMT<br>
notAfter=Feb 28 00:00:00 2007 GMT<br>
...<br>
X509v3 Authority Key Identifier:<br>
keyid:CB:C0:45:68:F9:B0:DF:8B:A9:E9:EA:A0:F1:93:A1:C1:6B:7C:96:E4<br>
DirName:<fixed-ca-dn><br>
serial:C2:7B:87:41:57:E3:81:C0<br>
<br>
SRV.pem:<br>
---------<br>
serial=C27B874157E381C1<br>
issuer= <fixed-ca-dn><br>
subject= <server-dn><br>
notBefore=Jan 15 00:00:00 2007 GMT<br>
notAfter=Feb 28 00:00:00 2007 GMT<br>
...<br>
X509v3 Authority Key Identifier:<br>
keyid:CB:C0:45:68:F9:B0:DF:8B:A9:E9:EA:A0:F1:93:A1:C1:6B:7C:96:E4<br>
DirName:<fixed-ca-dn><br>
serial:C2:7B:87:41:57:E3:81:C0<br>
<br>
A client with CAfile containing just "CA0.pem" fails to verify
a server<br>
configured to send the SRV,CA1 trust chain. My verification callback is<br>
called three times and produces:<br>
<br>
Trace: certificate verification depth=1 verify=0 subject=<fixed-ca-dn><br>
Error: CA certificate verification failed for <peer> certificate
has expired<br>
<br>
Trace: certificate verification depth=1 verify=1 subject=<fixed-ca-dn><br>
<br>
Trace: certificate verification depth=0 verify=1 subject=<server-dn><br>
<br>
If the verifier trusts the "CA1.pem" cert, I see instead:<br>
<br>
Trace: certificate verification depth=1 verify=1 subject=<fixed-ca-dn><br>
<br>
Trace: certificate verification depth=0 verify=1 subject=<fixed-server-dn><br>
<br>
How does one construct a working (re-issued root CA) example with OpenSSL?<br>
Am I setting this up incorrectly, or does OpenSSL not in fact support<br>
establishing trust in re-issued root CA via now expired root CAs?<br>
<br>
I have not tried to do this without the "issuer key identifier"
extension,<br>
but don't really expect to find anything different...<br>
<br>
-- <br>
<br>
/"\ ASCII RIBBON
NOTICE: If received in error,<br>
\ / CAMPAIGN Victor Duchovni please destroy and notify<br>
X AGAINST IT Security, sender.
Sender does not waive<br>
/ \ HTML MAIL Morgan Stanley confidentiality or privilege,<br>
and use is prohibited.<br>
<br>
---------------------------------------------------------------------<br>
The Cryptography Mailing List<br>
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com<br>
</tt></font>
<br>
--=_alternative 0021E8A065257279_=--
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
