Re: OT: SSL certificate chain problems

2007-02-05 Thread Peter Gutmann
Victor Duchovni [EMAIL PROTECTED] writes:
On Wed, Jan 31, 2007 at 01:57:04PM +1300, Peter Gutmann wrote:
 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.

So this is a special trick to extend root CA lifetimes. How widely is this
logic implemented, and is extending root CA key lifetime in this manner
standard practice? 

Like a lot of PKI, it's total pot-luck (crapshoot in the US I guess) as to
what a particular implementation does when it encounters this situation.  It
may work, it may not work, it may work under some circumstances, or it may do
anything in between.

(I've seen some implementations that require a system rebuild (meaning
reinstall all your PKI software with the new roots) to roll over roots, all
the way through to ones that handle the situation automatically.  There really
is no way to tell what a particular implemenation will do, apart from trying
it out and seeing what happens).

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: OT: SSL certificate chain problems

2007-02-04 Thread Victor Duchovni
On Wed, Jan 31, 2007 at 01:57:04PM +1300, Peter Gutmann wrote:

 Victor Duchovni [EMAIL PROTECTED] 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 MAILMorgan Stanley   confidentiality or privilege,
   and use is prohibited.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: OT: SSL certificate chain problems

2007-02-03 Thread Peter Gutmann
Victor Duchovni [EMAIL PROTECTED] 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.

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: OT: SSL certificate chain problems

2007-02-03 Thread Victor Duchovni
On Wed, Jan 31, 2007 at 01:57:04PM +1300, Peter Gutmann wrote:

 Victor Duchovni [EMAIL PROTECTED] 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.

So this is a special trick to extend root CA lifetimes. How widely is
this logic implemented, and is extending root CA key lifetime in this
manner standard practice? I may have to revise the Postfix documentation
to advise users to send the root cert.

My most recent experience is ironically in the opposite direction:

Peer finally upgrades from Windows Server 2000 to Windows Server 2003,
and replaces unexpired Verisign CA certs (updated at some point in
the past in the working Windows 2000) with now expired CA certs that
were good way back, when the Windows 2003 CDs were burned :-)

-- 

 /\ ASCII RIBBON  NOTICE: If received in error,
 \ / CAMPAIGN Victor Duchovni  please destroy and notify
  X AGAINST   IT Security, sender. Sender does not waive
 / \ HTML MAILMorgan Stanley   confidentiality or privilege,
   and use is prohibited.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


RE: OT: SSL certificate chain problems

2007-02-03 Thread Geoffrey Hird

Victor Duchovni wrote:
 On Sun, Jan 28, 2007 at 12:47:18PM -0500, Thor Lancelot Simon wrote:

  That doesn't make sense to me -- the end-of-chain (server or client)
  certificate won't be signed by _both_ the old and new root, 
 I wouldn't
  think (does x.509 even make this possible)?
 
  Or do I misunderstand?
 
 The key extra information is that old and new roots share the same
issuer
 and subject DNs and public key, only the start/expiration dates
differ,
 so in the overlap when both are valid, they are interchangeable, both
 verify the same (singly-signed) certs.

To expand on what Duchovni said, you might want to look into
the concept of cross-certificates (which are heavily used with
bridges).  The surprising thing, at first, is that you can issue
any certificate after it was originally issued.  I can issue
the leaf cert you got from Verisign last year.  Tomorrow, I
could create my own SS Root CA, and issue a cert for the
Verisign Intermediate CA, by putting myself as the Issuer,
the Verisign Intermediate CA as the Subject, and putting the
Verisign ICA public key in it.  Your leaf cert will now chain
happily up to either the Verisign SS Root, or my new SS Root.
So this is not just a thing that works for renewing self-signed
roots.

 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.

I shouldn't speak for Gutmann, but I assumed that he meant
that the server should send the new root *before* the old root
expires, so that the client can prepare in advance for the expiry.

As an aside, there are some funny issues around having a
signature done before the signer cert expired, but deciding
*after* the cert has expired, whether to trust it.  It was
ok yesterday, but maybe it's not ok today -- what has changed...?

Geoffrey

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: OT: SSL certificate chain problems

2007-01-30 Thread Peter Gutmann
Victor Duchovni [EMAIL PROTECTED] writes:

Wouldn't the old root also (until it actually expires) verify any
certificates signed by the new root? If so, why does a server need to send
the new root?

Because the client may not have the new root yet, and when they try and verify
using the expired root the verification will fail.

(There's a lot of potential further complications in there that I'm going to
 spare people the exposure to, but that's the basic idea).

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: OT: SSL certificate chain problems

2007-01-30 Thread Victor Duchovni
On Sat, Jan 27, 2007 at 02:12:34PM +1300, Peter Gutmann wrote:

 Victor Duchovni [EMAIL PROTECTED] writes:
 
 Wouldn't the old root also (until it actually expires) verify any
 certificates signed by the new root? If so, why does a server need to send
 the new root?
 
 Because the client may not have the new root yet, and when they try and verify
 using the expired root the verification will fail.

I am curious how the expired trusted old root helps to verify the as
yet untrusted new root... Is there a special-case behaviour when the
old and new root share the same DN and public key? Is such special-case
behaviour standard for trust chain verification implementations (allowing
the lifetime of root CAs to be indefinitely extended by issuing new certs
with the same keys)?

-- 
Viktor.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: OT: SSL certificate chain problems

2007-01-30 Thread Thor Lancelot Simon
On Fri, Jan 26, 2007 at 11:42:58AM -0500, Victor Duchovni wrote:
 On Fri, Jan 26, 2007 at 07:06:00PM +1300, Peter Gutmann wrote:
 
  In some cases it may be useful to send the entire chain, one such being 
  when a
  CA re-issues its root with a new expiry date, as Verisign did when its roots
  expired in December 1999.  The old root can be used to verify the new root.
 
 Wouldn't the old root also (until it actually expires) verify any
 certificates signed by the new root? If so, why does a server need to
 send the new root? So long as the recipient has either the new or the
 old root, the chain will be valid.

That doesn't make sense to me -- the end-of-chain (server or client)
certificate won't be signed by _both_ the old and new root, I wouldn't
think (does x.509 even make this possible)?

That means that for a party trying to validate a certificate signed by
the new root, but who has only the old root, the new root's certificate
will be a necessary intermediate step in the chain to the old root, which
that party trusts (assuming the new root is signed by the old root, that
is).

Or do I misunderstand?

Thor

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: OT: SSL certificate chain problems

2007-01-30 Thread Victor Duchovni
On Sun, Jan 28, 2007 at 12:47:18PM -0500, Thor Lancelot Simon wrote:

  Wouldn't the old root also (until it actually expires) verify any
  certificates signed by the new root? If so, why does a server need to
  send the new root? So long as the recipient has either the new or the
  old root, the chain will be valid.
 
 That doesn't make sense to me -- the end-of-chain (server or client)
 certificate won't be signed by _both_ the old and new root, I wouldn't
 think (does x.509 even make this possible)?

 Or do I misunderstand?

The key extra information is that old and new roots share the same issuer
and subject DNs and public key, only the start/expiration dates differ,
so in the overlap when both are valid, they are interchangeable, both
verify the same (singly-signed) certs. 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.

-- 

 /\ ASCII RIBBON  NOTICE: If received in error,
 \ / CAMPAIGN Victor Duchovni  please destroy and notify
  X AGAINST   IT Security, sender. Sender does not waive
 / \ HTML MAILMorgan Stanley   confidentiality or privilege,
   and use is prohibited.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: OT: SSL certificate chain problems

2007-01-26 Thread Peter Gutmann
Victor Duchovni [EMAIL PROTECTED] writes:

Generally it is enough for a TLS server or client to present its own
certificate and all *intermediate* CA certificates, sending the root CA cert
is optional, because if the verifying system trusts the root CA in question,
it has a local copy of that root CA cert. 

In some cases it may be useful to send the entire chain, one such being when a
CA re-issues its root with a new expiry date, as Verisign did when its roots
expired in December 1999.  The old root can be used to verify the new root.

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: OT: SSL certificate chain problems

2007-01-26 Thread Victor Duchovni
On Fri, Jan 26, 2007 at 07:06:00PM +1300, Peter Gutmann wrote:

 Victor Duchovni [EMAIL PROTECTED] writes:
 
 Generally it is enough for a TLS server or client to present its own
 certificate and all *intermediate* CA certificates, sending the root CA cert
 is optional, because if the verifying system trusts the root CA in question,
 it has a local copy of that root CA cert. 
 
 In some cases it may be useful to send the entire chain, one such being when a
 CA re-issues its root with a new expiry date, as Verisign did when its roots
 expired in December 1999.  The old root can be used to verify the new root.

Wouldn't the old root also (until it actually expires) verify any
certificates signed by the new root? If so, why does a server need to
send the new root? So long as the recipient has either the new or the
old root, the chain will be valid. Is the problem case when the verifier
has both roots, and the older of the two has expired?

-- 

 /\ ASCII RIBBON  NOTICE: If received in error,
 \ / CAMPAIGN Victor Duchovni  please destroy and notify
  X AGAINST   IT Security, sender. Sender does not waive
 / \ HTML MAILMorgan Stanley   confidentiality or privilege,
   and use is prohibited.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: OT: SSL certificate chain problems

2007-01-25 Thread Erik Tews
Am Dienstag, den 23.01.2007, 20:47 -0600 schrieb Travis H.:
 Verify return code: 21 (unable to verify the first certificate)
 ---
 DONE
 
 I can't seem to get that certificate chain to have any contents other
 than what you see above, no matter what I do, and hence can't get rid
 of the Verify return code: 21... does anyone have any advice on what
 to do next?  URLs or references to other mailing lists welcome.

Did you try -CAfile, with this command you can give s_client a file with
CAs you trust. If the Thawte Consulting certificate is in this file, you
should have no problems with verifying.


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil


Re: OT: SSL certificate chain problems

2007-01-25 Thread Massimiliano Pala

Hi,

you should provide the whole chain starting from the CA that issued the server
cert. Be careful, though, because you should *NOT* provide the root cert
in the chain as well.

Moreover you should use the:

SSLCertificateChainFile

not the SSLCACertificateFile (which is for client auth).

Cheers,
Max.

Travis H. wrote:

Hi,

This is not really typical of the traffic on this list, hence the OT.

I send it because I think this is one of the few places where I'll
find some people with deep understanding of SSL certs.

Recently I had an issue where Google checkout would not accept an
SSL certificate because Apache didn't present the entire hierarchy,
just the site certificate itself.  The CA was Thawte.  What Google
said was that many browsers supply missing certs as needed, but
apparently their software did not.

The fix would seem to be easy; just put the right CA root cert in the
SSLCACertFile directive. or point to the directory with SSLCACertPath.
However, I've tried over and over with various root CA certs
downloaded from Thawte, and with one intermediate CA cert, and various
combinations thereof, but with no sucess.



--

Best Regards,

Massimiliano Pala

--o
Massimiliano Pala [OpenCA Project Manager][EMAIL PROTECTED]
 [EMAIL PROTECTED]

Dartmouth Computer Science Dept   Home Phone: +1 (603) 397-3883
PKI/Trust - Office 063Work Phone: +1 (603) 646-9179
--o


smime.p7s
Description: S/MIME Cryptographic Signature