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
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
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
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
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
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
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
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
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
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
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
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
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
13 matches
Mail list logo
