Re: Choice of CAs in SSL/TLS handshake
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 Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] -- 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 Description: S/MIME Cryptographic Signature
Re: Choice of CAs in SSL/TLS handshake
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 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 [EMAIL PROTECTED]
A daily view on Internet Attacks
https://www.ecsirt.net/sensornet
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
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 Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: Choice of CAs in SSL/TLS handshake
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 Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Choice of CAs in SSL/TLS handshake
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 Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] -- To verify the signature, see http://edelpki.edelweb.fr/ Cela vous permet de charger le certificat de l'autorite'; die Liste mit zuruckgerufenen Zertifikaten finden Sie da auch. smime.p7s Description: S/MIME Cryptographic Signature
Re: Choice of CAs in SSL/TLS handshake
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 Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Choice of CAs in SSL/TLS handshake
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 Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] -- 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 Description: S/MIME Cryptographic Signature
Re: Choice of CAs in SSL/TLS handshake
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 Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
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 [EMAIL PROTECTED] A daily view on Internet Attacks https://www.ecsirt.net/sensornet __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Choice of CAs in SSL/TLS handshake
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 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 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 [EMAIL PROTECTED] A daily view on Internet Attacks https://www.ecsirt.net/sensornet __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Choice of CAs in SSL/TLS handshake
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 [EMAIL PROTECTED] A daily view on Internet Attacks https://www.ecsirt.net/sensornet __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Choice of CAs in SSL/TLS handshake
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 PROTECTED] 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 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 [EMAIL PROTECTED] A daily view on Internet Attacks https://www.ecsirt.net/sensornet __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
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 [EMAIL PROTECTED] A daily view on Internet Attacks https://www.ecsirt.net/sensornet __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Choice of CAs in SSL/TLS handshake
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 [EMAIL PROTECTED] A daily view on Internet Attacks https://www.ecsirt.net/sensornet __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Choice of CAs in SSL/TLS handshake
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Olaf Gellert Sent: Tuesday, March 07, 2006 8:34 PM To: openssl-users@openssl.org 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 [EMAIL PROTECTED] A daily view on Internet Attacks https://www.ecsirt.net/sensornet __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
