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 sp
the original message.
Victor Duchovni <[EMAIL PROTECTED]>
Sent by:
[EMAIL PROTECTED]
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:
> Vict
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
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)?
> >
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
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-sig
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 roo
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 roo
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 clien
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 expire
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 ver
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
Travis,
> 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.
maybe th
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)
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
On Tue, Jan 23, 2007 at 08:47:26PM -0600, Travis H. wrote:
> This is not really typical of the traffic on this list, hence the OT.
It is much more typical of openssl-users, which is probably a better
bet for this question.
> Recently I had an issue where Google checkout would not accept an
> SSL
16 matches
Mail list logo
