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 think
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
>
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 unstrus
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
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 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.
>
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
: 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.
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
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
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.
Regards,
Samy
Olaf Gellert <[EMAIL PROTECTE
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
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?
Thanks
--G3
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Olaf Gellert
Sent: Tuesday, March 07, 2006 5:26 PM
13 matches
Mail list logo
