I think you are right about the current behaviour
When filling up the intermediate stack, the x609 verify cert break when the
verifydepth is reached as far as I see from the code, but it seems that
the ssl library doesn't set a verify depth?
But in this case the verifydepth would work I
On 3/7/06, Olaf Gellert [EMAIL PROTECTED] wrote:
Samy Thiyagarajan wrote:
Hi,
May be changing the verification of the depth level solve this issue. (
I mean check the chain only upto User CA 1 and not upto the Root CA )
In this case it should not report about missing valid root.
Im
On Tue, Mar 07, 2006, Olaf Gellert wrote:
Samy Thiyagarajan wrote:
Hi,
May be changing the verification of the depth level solve this issue. (
I mean check the chain only upto User CA 1 and not upto the Root CA )
In this case it should not report about missing valid root.
Im not
Another easy way is to use self signed certs of the acceptable CAs.
Dr. Stephen Henson wrote:
On Tue, Mar 07, 2006, Olaf Gellert wrote:
Samy Thiyagarajan wrote:
Hi,
May be changing the verification of the depth level solve this issue. (
I mean check the chain only upto User CA 1 and
On Wed, Mar 08, 2006, Peter Sylvester wrote:
Another easy way is to use self signed certs of the acceptable CAs.
I'm not sure that would work because the path building algorithm first tries to
construct as much of the path as possible from the set of unstrusted CAs with
the exception of the
Dr. Stephen Henson wrote:
On Wed, Mar 08, 2006, Peter Sylvester wrote:
Another easy way is to use self signed certs of the acceptable CAs.
I'm not sure that would work because the path building algorithm first tries to
construct as much of the path as possible from the set of
On Wed, Mar 08, 2006, Peter Sylvester wrote:
Dr. Stephen Henson wrote:
On Wed, Mar 08, 2006, Peter Sylvester wrote:
Another easy way is to use self signed certs of the acceptable CAs.
I'm not sure that would work because the path building algorithm first
tries to
construct
Hi,
I came across the following problem: I do have
two user CAs under the same root CA:
Root CA
|- User CA 1 - User Certificate 1
|- User CA 2 - User Certificate 2
I want to tell a webserver to accept certificates
from User CA 1 but not from User CA 2. But: In
openssl s_server AND
To: openssl-users@openssl.org
Subject: Choice of CAs in SSL/TLS handshake
Hi,
I came across the following problem: I do have
two user CAs under the same root CA:
Root CA
|- User CA 1 - User Certificate 1
|- User CA 2 - User Certificate 2
I want to tell a webserver to accept
Gayathri Sundar wrote:
you can put CA2 as part of the revocation list?
if CA2 is part of the client's CRL, then it will automatically
be rejected..is this what you want?
Nothing about revocation, both CAs are valid
and should stay valid. I do have a User CA 1
for one type of service (or one
]
Sent by:
[EMAIL PROTECTED]
07.03.2006 12:56
Please respond to
openssl-users@openssl.org
To
openssl-users@openssl.org
cc
Subject
Choice of CAs in SSL/TLS handshake
Classification
Hi,
I came across the following problem: I do have
two user CAs under the same root CA:
Root
Samy Thiyagarajan wrote:
Hi,
May be changing the verification of the depth level solve this issue. (
I mean check the chain only upto User CA 1 and not upto the Root CA )
In this case it should not report about missing valid root.
Im not sure. this is just an idea.
Good idea. But
When you want to operate in this special CA filtering mode, you
could hook the OpenSSL certificate validation logic. Your callback
could then implement it's only validation logic and return a reject
when you see a certificate you want to deny (even though it's valid).
Randy
On Mar 7,
: Choice of CAs in SSL/TLS handshake
Samy Thiyagarajan wrote:
Hi,
May be changing the verification of the depth level solve this issue. (
I mean check the chain only upto User CA 1 and not upto the Root CA )
In this case it should not report about missing valid root.
Im not sure
14 matches
Mail list logo
