Choice of CAs in SSL/TLS handshake

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Choice of CAs in SSL/TLS handshake

Olaf Gellert
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 in mod_ssl I can only specify
a list (as file or directory) of trusted CAs. These
are used for two purposes:

a) the server puts all of them in his certificate_request
   message during SSL connection establishment.
b) they have to contain the root certificate as trust
   anchor.

What I need is a way to specify the requested client
CAs WITHOUT the root certificate. Otherwise clients
(Mozilla/Firefox) think that both CAs are accepted
(because the root certificate is in the certificate
request message).

Any way to do this? Is this just a missing feature
or do I read the RFC wrong? This is what RFC 2246 says
about the request message (sec. 7.4.4):

  certificate_authorities
      A list of the distinguished names of acceptable certificate
      authorities. These distinguished names may specify a desired
      distinguished name for a root CA or for a subordinate CA;
      thus, this message can be used both to describe known roots
      and a desired authorization space.

So it should be possible to provide only the certificate
of User CA 1? (but then openssl s_server and mod_ssl do
not find a valid root certificate.)

Thanks for any help,

Olaf

--
Dipl.Inform. Olaf Gellert                  PRESECURE (R)
Senior Researcher,                       Consulting GmbH
Phone: (+49) 0700 / PRESECURE           [hidden email]

                        A daily view on Internet Attacks
                        https://www.ecsirt.net/sensornet

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Choice of CAs in SSL/TLS handshake

Gayathri Sundar-2
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: [hidden email]
[mailto:[hidden email]]On Behalf Of Olaf Gellert
Sent: Tuesday, March 07, 2006 5:26 PM
To: [hidden email]
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 certificates
from User CA 1 but not from User CA 2. But: In
openssl s_server AND in mod_ssl I can only specify
a list (as file or directory) of trusted CAs. These
are used for two purposes:

a) the server puts all of them in his certificate_request
   message during SSL connection establishment.
b) they have to contain the root certificate as trust
   anchor.

What I need is a way to specify the requested client
CAs WITHOUT the root certificate. Otherwise clients
(Mozilla/Firefox) think that both CAs are accepted
(because the root certificate is in the certificate
request message).

Any way to do this? Is this just a missing feature
or do I read the RFC wrong? This is what RFC 2246 says
about the request message (sec. 7.4.4):

  certificate_authorities
      A list of the distinguished names of acceptable certificate
      authorities. These distinguished names may specify a desired
      distinguished name for a root CA or for a subordinate CA;
      thus, this message can be used both to describe known roots
      and a desired authorization space.

So it should be possible to provide only the certificate
of User CA 1? (but then openssl s_server and mod_ssl do
not find a valid root certificate.)

Thanks for any help,

Olaf

--
Dipl.Inform. Olaf Gellert                  PRESECURE (R)
Senior Researcher,                       Consulting GmbH
Phone: (+49) 0700 / PRESECURE           [hidden email]

                        A daily view on Internet Attacks
                        https://www.ecsirt.net/sensornet

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Choice of CAs in SSL/TLS handshake

Olaf Gellert
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 group of users)
and a User CA 2 for another kind of service.
Both are under the same root CA.
When I setup Apache/Mod_SSL I am not able to
specify, that the Server should only request
client certificates from User CA 1. It will
always put the root certificate in the TLS
certificate request and so the client assumes
that it is ok to send a certificate from User
CA 2...

The only way to cope with this with Mozilla is
to setup "manual choice" for the certificate
(so whenever e certificate is necessary, the
browser asks you, which is very often and
annoying).

So I am looking for a way to configure what
the server sends in his client certificate
request... (Anyone who knows better how the
words in the RFC are meant, speak up now! :-))

Of course, thanks for your help,

Cheers, Olaf

--
Dipl.Inform. Olaf Gellert                  PRESECURE (R)
Senior Researcher,                       Consulting GmbH
Phone: (+49) 0700 / PRESECURE           [hidden email]

                        A daily view on Internet Attacks
                        https://www.ecsirt.net/sensornet

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Choice of CAs in SSL/TLS handshake

Samy Thiyagarajan
In reply to this post by Olaf Gellert

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 <[hidden email]>

Sent by:
[hidden email]

07.03.2006 12:56

Please respond to
[hidden email]

To
[hidden email]
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 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 in mod_ssl I can only specify
a list (as file or directory) of trusted CAs. These
are used for two purposes:

a) the server puts all of them in his certificate_request
  message during SSL connection establishment.
b) they have to contain the root certificate as trust
  anchor.

What I need is a way to specify the requested client
CAs WITHOUT the root certificate. Otherwise clients
(Mozilla/Firefox) think that both CAs are accepted
(because the root certificate is in the certificate
request message).

Any way to do this? Is this just a missing feature
or do I read the RFC wrong? This is what RFC 2246 says
about the request message (sec. 7.4.4):

 certificate_authorities
     A list of the distinguished names of acceptable certificate
     authorities. These distinguished names may specify a desired
     distinguished name for a root CA or for a subordinate CA;
     thus, this message can be used both to describe known roots
     and a desired authorization space.

So it should be possible to provide only the certificate
of User CA 1? (but then openssl s_server and mod_ssl do
not find a valid root certificate.)

Thanks for any help,

Olaf

--
Dipl.Inform. Olaf Gellert                  PRESECURE (R)
Senior Researcher,                       Consulting GmbH
Phone: (+49) 0700 / PRESECURE           [hidden email]

                       A daily view on Internet Attacks
                       https://www.ecsirt.net/sensornet

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Choice of CAs in SSL/TLS handshake

Olaf Gellert
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 unfortunately it does not work out. I removed the
root-certificate from the SSLCACertificateFile. The Server now only
allows the user CA 1 (otherwise it still offers the root CA as
valid CA). And I shortened the verifyDepth to one. But the server
denies access saying:

[Tue Mar 07 15:56:34 2006] [error] Certificate Verification: Error (20): unable
to get local issuer certificate

Seems that "verifyDepth" still requires a self-signed root
certificate (so the chain has to reach the toplevel in the
given number of steps).

Hm... Any other proposals? :-)

Cheers, Olaf

--
Dipl.Inform. Olaf Gellert                  PRESECURE (R)
Senior Researcher,                       Consulting GmbH
Phone: (+49) 0700 / PRESECURE           [hidden email]

                        A daily view on Internet Attacks
                        https://www.ecsirt.net/sensornet

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Choice of CAs in SSL/TLS handshake

Randy Turner

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, 2006, at 7:03 AM, 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 sure. this is just an idea.
>
> Good idea. But unfortunately it does not work out. I removed the
> root-certificate from the SSLCACertificateFile. The Server now only
> allows the user CA 1 (otherwise it still offers the root CA as
> valid CA). And I shortened the verifyDepth to one. But the server
> denies access saying:
>
> [Tue Mar 07 15:56:34 2006] [error] Certificate Verification: Error  
> (20): unable
> to get local issuer certificate
>
> Seems that "verifyDepth" still requires a self-signed root
> certificate (so the chain has to reach the toplevel in the
> given number of steps).
>
> Hm... Any other proposals? :-)
>
> Cheers, Olaf
>
> --
> Dipl.Inform. Olaf Gellert                  PRESECURE (R)
> Senior Researcher,                       Consulting GmbH
> Phone: (+49) 0700 / PRESECURE           [hidden email]
>
>                         A daily view on Internet Attacks
>                         https://www.ecsirt.net/sensornet
>
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    [hidden email]
> Automated List Manager                           [hidden email]

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Choice of CAs in SSL/TLS handshake

Gayathri Sundar-2
In reply to this post by Olaf Gellert
I think verify depth of 1 will work only for self signed certificates,
in this case it wont work, you should override the default certificate
checking functions by registering ur own callback for this function
pointer in ssl_st.

int (*verify_callback)(int ok,X509_STORE_CTX *ctx)

as you already know CA2 issuername and common name, you can reject
that certificate if presented.

Hope this helps.

Thanks
--Gayathri

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]]On Behalf Of Olaf Gellert
Sent: Tuesday, March 07, 2006 8:34 PM
To: [hidden email]
Subject: Re: 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. this is just an idea.

Good idea. But unfortunately it does not work out. I removed the
root-certificate from the SSLCACertificateFile. The Server now only
allows the user CA 1 (otherwise it still offers the root CA as
valid CA). And I shortened the verifyDepth to one. But the server
denies access saying:

[Tue Mar 07 15:56:34 2006] [error] Certificate Verification: Error (20):
unable
to get local issuer certificate

Seems that "verifyDepth" still requires a self-signed root
certificate (so the chain has to reach the toplevel in the
given number of steps).

Hm... Any other proposals? :-)

Cheers, Olaf

--
Dipl.Inform. Olaf Gellert                  PRESECURE (R)
Senior Researcher,                       Consulting GmbH
Phone: (+49) 0700 / PRESECURE           [hidden email]

                        A daily view on Internet Attacks
                        https://www.ecsirt.net/sensornet

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Choice of CAs in SSL/TLS handshake

Nicolas Margaine
In reply to this post by Olaf Gellert
On 3/7/06, Olaf Gellert <[hidden email]> 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 sure. this is just an idea.
>
> Good idea. But unfortunately it does not work out. I removed the
> root-certificate from the SSLCACertificateFile. The Server now only
> allows the user CA 1 (otherwise it still offers the root CA as
> valid CA). And I shortened the verifyDepth to one. But the server
> denies access saying:
>
> [Tue Mar 07 15:56:34 2006] [error] Certificate Verification: Error (20): unable
> to get local issuer certificate
>
> Seems that "verifyDepth" still requires a self-signed root
> certificate (so the chain has to reach the toplevel in the
> given number of steps).
>
> Hm... Any other proposals? :-)
>
> Cheers, Olaf
>
> --
> Dipl.Inform. Olaf Gellert                  PRESECURE (R)
> Senior Researcher,                       Consulting GmbH
> Phone: (+49) 0700 / PRESECURE           [hidden email]
>
>                         A daily view on Internet Attacks
>                         https://www.ecsirt.net/sensornet
>
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    [hidden email]
> Automated List Manager                           [hidden email]
>

Hi Olaf,

 I think you can use the mod_ssl SSLRequire directive.

 This directive specifies a general access requirement which has to be
fulfilled in order to allow access. It's a very powerful directive
because the requirement specification is an arbitrarily complex
boolean expression containing any number of access checks.

Example that should work for you:
SSLRequire %{SSL_CLIENT_I_DN} eq "/C=foo/O=bar/CN=CA1"

cf http://www.modssl.org/docs/2.8/ssl_reference.html#ToC23

Regards

--
Nicolas Margaine
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Choice of CAs in SSL/TLS handshake

Dr. Stephen Henson
In reply to this post by Olaf Gellert
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 sure. this is just an idea.
>
> Good idea. But unfortunately it does not work out. I removed the
> root-certificate from the SSLCACertificateFile. The Server now only
> allows the user CA 1 (otherwise it still offers the root CA as
> valid CA). And I shortened the verifyDepth to one. But the server
> denies access saying:
>
> [Tue Mar 07 15:56:34 2006] [error] Certificate Verification: Error (20): unable
> to get local issuer certificate
>
> Seems that "verifyDepth" still requires a self-signed root
> certificate (so the chain has to reach the toplevel in the
> given number of steps).
>
> Hm... Any other proposals? :-)
>

There are several options. One is to turn off chain verification. That
would mean that the verify function no longer uses untrusted CAs from the peer
and you place the rest of the chain in the trusted store.

Unfortunately there isn't a verify flag to do that directly so you'd have to
override the standard verify function and replace it with exactly the same
code *except* it would pass a NULL for the set of unstrusted certificates.

A second option is to add a purpose setting which rejects any and all cas
while keeping the standard behaviour for non-CAs.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://www.drh-consultancy.demon.co.uk
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Choice of CAs in SSL/TLS handshake

Peter Sylvester-3
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 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 unfortunately it does not work out. I removed the
>> root-certificate from the SSLCACertificateFile. The Server now only
>> allows the user CA 1 (otherwise it still offers the root CA as
>> valid CA). And I shortened the verifyDepth to one. But the server
>> denies access saying:
>>
>> [Tue Mar 07 15:56:34 2006] [error] Certificate Verification: Error (20): unable
>> to get local issuer certificate
>>
>> Seems that "verifyDepth" still requires a self-signed root
>> certificate (so the chain has to reach the toplevel in the
>> given number of steps).
>>
>> Hm... Any other proposals? :-)
>>
>>    
>
> There are several options. One is to turn off chain verification. That
> would mean that the verify function no longer uses untrusted CAs from the peer
> and you place the rest of the chain in the trusted store.
>
> Unfortunately there isn't a verify flag to do that directly so you'd have to
> override the standard verify function and replace it with exactly the same
> code *except* it would pass a NULL for the set of unstrusted certificates.
>
> A second option is to add a purpose setting which rejects any and all cas
> while keeping the standard behaviour for non-CAs.
>
> Steve.
> --
> Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
> OpenSSL project core developer and freelance consultant.
> Funding needed! Details on homepage.
> Homepage: http://www.drh-consultancy.demon.co.uk
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    [hidden email]
> Automated List Manager                           [hidden email]
>
>
>  

--
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autorite';
die Liste mit zuru"ckgerufenen Zertifikaten finden Sie da auch.


smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Choice of CAs in SSL/TLS handshake

Dr. Stephen Henson
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 root.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://www.drh-consultancy.demon.co.uk
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Choice of CAs in SSL/TLS handshake

Peter Sylvester-3
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 unstrusted CAs with
> the exception of the root.
>  
But the self signed certs of the CAs are the roots in this case, aren't
they.

We are talking about how to configure an, Apache mod_ssl for client certs?
The so called "root" in the example would not even be visible.
As far as I understood, the real CA hierarchy was

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



All what has to be set in mod_ssl or in s_server is a self signed cert
of CA 1

Unless one also want to allow certs for the root. So you set the root
and the self signed cert for CA 1.
In this case a client could indeed send an CA 2 cert together with the
CA 2 intermediate.

But in this case the verifydepth would work I think.

> Steve.
> --
> Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
> OpenSSL project core developer and freelance consultant.
> Funding needed! Details on homepage.
> Homepage: http://www.drh-consultancy.demon.co.uk
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    [hidden email]
> Automated List Manager                           [hidden email]
>
>
>  

--
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autorité;
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch.


smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Choice of CAs in SSL/TLS handshake

Dr. Stephen Henson
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 as much of the path as possible from the set of unstrusted CAs
> >with
> >the exception of the root.
> >  
> But the self signed certs of the CAs are the roots in this case, aren't
> they.
>
> We are talking about how to configure an, Apache mod_ssl for client certs?
> The so called "root" in the example would not even be visible.
> As far as I understood, the real CA hierarchy was
>
> 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
>
>
>
> All what has to be set in mod_ssl or in s_server is a self signed cert
> of CA 1
>
> Unless one also want to allow certs for the root. So you set the root
> and the self signed cert for CA 1.
> In this case a client could indeed send an CA 2 cert together with the
> CA 2 intermediate.
>
> But in this case the verifydepth would work I think.
>

Yes but the client will still send the user certificate, one intermediate
CA and optionally the root CA. OpenSSL will use those to build as much of the
path as possible and try to complete it using the trusted store. When it
can't find the root CA in that store it will fail.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://www.drh-consultancy.demon.co.uk
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Choice of CAs in SSL/TLS handshake

Peter Sylvester-3

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.
>>
>>    
>
> Yes but the client will still send the user certificate, one intermediate
> CA and optionally the root CA. OpenSSL will use those to build as much of the
> path as possible and try to complete it using the trusted store. When it
> can't find the root CA in that store it will fail.
>
> Steve.
> --
> Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
> OpenSSL project core developer and freelance consultant.
> Funding needed! Details on homepage.
> Homepage: http://www.drh-consultancy.demon.co.uk
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    [hidden email]
> Automated List Manager                           [hidden email]
>
>
>  

--
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autorité;
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch.


smime.p7s (6K) Download Attachment