You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by g f <gf...@gmail.com> on 2011/01/18 16:16:48 UTC
[users@httpd] SSL library error 1 in handshake
Hello all,
I have a debian os running Apache 2.2.16(debian) along with tomcat 6.0.29. I
use mod_jk as well as mod_auth_kerb module for apache. Apache and the
modules are debian repository packages.
I recently attempted to activate common access cards and if I just activate
them but do not force them it works great.
Once I force access cards, I get the following error and my web-apps break.
Force access cards via:
SSLVerifyClient require
SSLVerifyDepth 2
info level logging error.log:
[Tue Jan 18 14:47:07 2011] [info] [client 127.0.1.1] SSL library error 1 in
handshake (server myserver.xxx.xxx.xxx:443)
[Tue Jan 18 14:47:07 2011] [info] SSL Library Error: 336105671
error:140890C7:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return
a certificate No CAs known to server for verification?
The web-app that throws this message uses a python proxy to make an ajax
call to a different web context (we do this to avoid the cross site error).
I believe what is happening is that the python script [client 127.0.1.1] is
making the request to apache without valid client certs and hence is getting
denied.
I have a directive in apache2_home/sites-enabled/default-ssl conf file that
I had hoped would solve this issue(however it does not).
directive in default-ssl conf file
Allow from localhost
Allow from 127.0.1.1
Allow from 127.0.0.1
Is there a solution to this issue?
Perhaps a way to not require client cert from localhost?
Thanks for any advice, much appreciated!
Cheers,
G40
Re: [users@httpd] SSL library error 1 in handshake
Posted by g f <gf...@gmail.com>.
Martin,
very nice!
I will give that a shot.
I appreciate your effort on this as well as others that have posted.
Cheers!
G40
On Wed, Jan 19, 2011 at 1:50 AM, Martin Kuba <ma...@ics.muni.cz> wrote:
> Dne 18.1.2011 18:12, g f napsal(a):
>
> Hey Martin,
>> common access cards are smart cards that allow a user to authenticate to a
>> domain using just the card(inserted into the card reader) and a pin number.
>> The directive
>> */SSLVerifyClient require/*
>> requires all https access utilize a smart card. no smart card, no access.
>>
>
> Hi G40,
>
> to be precise, the "SSLVerifyClient require" does not requires that all
> https access utilizes a smart card,
> it requires that the HTTP client presents a certificate. The certificate
> may be stored in many ways
> on the computer with the HTTP client, for example directly in the browser
> (like in Firefox), in the MS-Windows
> system-wide certificate store, or in some PKCS11 device like your
> cryptographic smart card.
>
> So the "SSLVerifyClient require" is not enough to ensure that a smart card
> is used, but
> if a user has a smart card configured properly, it can be used. A user
> still have the option
> to provide the certificate from some other source than a smart card. This
> may or may not affect your security.
>
>
> */SSLVerifyClient optional
>>
>> /*this seems to fix my issue. It prompts for the smart card for access but
>> also allows the request (that comes from localhost) through.
>>
>
> Actually no, it does not fix the issue, it just hides it. "SSLVerifyClient
> optional" allows non-authenticated
> access, so anybody without a certificate can now access your application !
>
>
> The proxy resides in www/cgi-bin
>>
>> I am not a python person but I can better describe it in java terms
>> (recall we use mod_jk to hand off to tomcat6):
>>
>> user accesses /https://mydomain.com/*protected_app*/*_A*
>> protected_app requires data from some_other_protected_app using ajax and a
>> pseudo proxy servlet
>> /https://mydomain.com/*protected_app_A*/pseudo_proxy_Servlet/ makes a
>> URLConnection to (to avoid the javascript cross site scripting error) to
>> /https://mydomain.com/*protected_app_B*/web-service/
>> Apache attempts to authenticate this request coming from
>> /https://mydomain.com/*protected_app_A*/pseudo_proxy_Servlet/ . To
>> apache it appears as a request from localhost from user Java1.6(tomcat) and
>> so authentication fails since apache is asking the
>> servlet for a cert and it does not have the client cert.
>>
>
> I see, it is the situation that I have guessed.
>
>
> Setting
>> */SSLVerifyClient optional/*
>> seems to fix the problem since the request from localhost java1.6(tomcat)
>> is allowed since It no longer requires client certs.
>>
>
> It creates a security hole, because now clients without certificate can
> access the application, as I have written above.
>
> What you actually need to do it to make sure that clients coming from
> outside present a certificate,
> while internal calls from localhost do not.
>
> So configure two virtual web servers, one for localhost and one for
> mydomain.com,
> and use "SSLVerifyClient required" for mydomain.com and ""SSLVerifyClient
> none" for localhost. Something like
>
> <VirtualHost 127.0.0.1:443>
> ServerName localhost
> SSLEngine on
> SSLVerifyClient none
> ...
> </VirtualHost>
> <VirtualHost *:443>
> ServerName mydomain.com
> SSLEngine on
> SSLVerifyClient required
> ...
> </VirtualHost>
>
>
>
> As it is configured now, it works for me.
>> I realize that the ideal solution would be to set /*SSLVerifyClient
>> require*/ and configure apache to forward client certs to tomcat as well as
>> the python proxy, which I am currently researching.
>>
>
> You cannot forward certificates, because they do not work without their
> associated private keys.
>
> Cheers
>
> Martin
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Supercomputing Center Brno Martin Kuba
> Institute of Computer Science email: makub@ics.muni.cz
> Masaryk University http://www.ics.muni.cz/~makub/<http://www.ics.muni.cz/%7Emakub/>
> Botanicka 68a, 60200 Brno, CZ mobil: +420-603-533775
> --------------------------------------------------------------
>
>
Re: [users@httpd] SSL library error 1 in handshake
Posted by Martin Kuba <ma...@ics.muni.cz>.
Dne 18.1.2011 18:12, g f napsal(a):
> Hey Martin,
> common access cards are smart cards that allow a user to authenticate to a domain using just the card(inserted into the card reader) and a pin number.
> The directive
> */SSLVerifyClient require/*
> requires all https access utilize a smart card. no smart card, no access.
Hi G40,
to be precise, the "SSLVerifyClient require" does not requires that all https access utilizes a smart card,
it requires that the HTTP client presents a certificate. The certificate may be stored in many ways
on the computer with the HTTP client, for example directly in the browser (like in Firefox), in the MS-Windows
system-wide certificate store, or in some PKCS11 device like your cryptographic smart card.
So the "SSLVerifyClient require" is not enough to ensure that a smart card is used, but
if a user has a smart card configured properly, it can be used. A user still have the option
to provide the certificate from some other source than a smart card. This may or may not affect your security.
> */SSLVerifyClient optional
> /*this seems to fix my issue. It prompts for the smart card for access but also allows the request (that comes from localhost) through.
Actually no, it does not fix the issue, it just hides it. "SSLVerifyClient optional" allows non-authenticated
access, so anybody without a certificate can now access your application !
> The proxy resides in www/cgi-bin
>
> I am not a python person but I can better describe it in java terms (recall we use mod_jk to hand off to tomcat6):
>
> user accesses /https://mydomain.com/*protected_app*/*_A*
> protected_app requires data from some_other_protected_app using ajax and a pseudo proxy servlet
> /https://mydomain.com/*protected_app_A*/pseudo_proxy_Servlet/ makes a URLConnection to (to avoid the javascript cross site scripting error) to
> /https://mydomain.com/*protected_app_B*/web-service/
> Apache attempts to authenticate this request coming from
> /https://mydomain.com/*protected_app_A*/pseudo_proxy_Servlet/ . To apache it appears as a request from localhost from user Java1.6(tomcat) and so authentication fails since apache is asking the
> servlet for a cert and it does not have the client cert.
I see, it is the situation that I have guessed.
> Setting
> */SSLVerifyClient optional/*
> seems to fix the problem since the request from localhost java1.6(tomcat) is allowed since It no longer requires client certs.
It creates a security hole, because now clients without certificate can access the application, as I have written above.
What you actually need to do it to make sure that clients coming from outside present a certificate,
while internal calls from localhost do not.
So configure two virtual web servers, one for localhost and one for mydomain.com,
and use "SSLVerifyClient required" for mydomain.com and ""SSLVerifyClient none" for localhost. Something like
<VirtualHost 127.0.0.1:443>
ServerName localhost
SSLEngine on
SSLVerifyClient none
...
</VirtualHost>
<VirtualHost *:443>
ServerName mydomain.com
SSLEngine on
SSLVerifyClient required
...
</VirtualHost>
> As it is configured now, it works for me.
> I realize that the ideal solution would be to set /*SSLVerifyClient require*/ and configure apache to forward client certs to tomcat as well as the python proxy, which I am currently researching.
You cannot forward certificates, because they do not work without their associated private keys.
Cheers
Martin
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Supercomputing Center Brno Martin Kuba
Institute of Computer Science email: makub@ics.muni.cz
Masaryk University http://www.ics.muni.cz/~makub/
Botanicka 68a, 60200 Brno, CZ mobil: +420-603-533775
--------------------------------------------------------------
Re: [users@httpd] SSL library error 1 in handshake
Posted by g f <gf...@gmail.com>.
Hey Martin,
common access cards are smart cards that allow a user to authenticate to a
domain using just the card(inserted into the card reader) and a pin number.
The directive
*SSLVerifyClient require*
requires all https access utilize a smart card. no smart card, no access.
*SSLVerifyClient optional
*this seems to fix my issue. It prompts for the smart card for access but
also allows the request (that comes from localhost) through.
The proxy resides in www/cgi-bin
I am not a python person but I can better describe it in java terms (recall
we use mod_jk to hand off to tomcat6):
user accesses *https://mydomain.com/protected_app**_A*
protected_app requires data from some_other_protected_app using ajax and a
pseudo proxy servlet
*https://mydomain.com/protected_app_A/pseudo_proxy_Servlet* makes a
URLConnection to (to avoid the javascript cross site scripting error) to
*https://mydomain.com/protected_app_B/web-service*
Apache attempts to authenticate this request coming from
*https://mydomain.com/protected_app_A/pseudo_proxy_Servlet* . To apache it
appears as a request from localhost from user Java1.6(tomcat) and so
authentication fails since apache is asking the servlet for a cert and it
does not have the client cert.
Setting
*SSLVerifyClient optional*
seems to fix the problem since the request from localhost java1.6(tomcat) is
allowed since It no longer requires client certs.
This is my theory and I am open to corrections.
As it is configured now, it works for me.
I realize that the ideal solution would be to set *SSLVerifyClient
require*and configure apache to forward client certs to tomcat as well
as the python
proxy, which I am currently researching.
Thanks!
G40
On Tue, Jan 18, 2011 at 10:09 AM, Martin Kuba <ma...@ics.muni.cz> wrote:
> Hi G40,
>
> I am a bit confused from your description, I do not know what you mean
> by "common access cards" and what you mean by forcing them.
> Also I do not understand where is your python proxy, is it on the server or
> on the client ?
>
> I have a suspicion that you are mixing the client and the server.
>
> Is the configuration that you use a web browser with a certificate to
> access a URL
> on the server, the URL is served by a python script that makes another HTTP
> call
> to the same server ? If this is the case, it can't work, because the
> certificate
> cannot be delegated from the server-side script to another server-side
> script.
>
> The reason is that it is not the certificate alone what is needed to make
> an authentication to an SSL server, also the private key is needed.
>
> Cheers
>
> Martin
>
> Dne 18.1.2011 16:36, g f napsal(a):
>
>> Hello Martin,
>> thanks for the reply.
>> I have those directives already and it all works until I add:
>> /SSLVerifyClient *require*/
>>
>> I changed this directive to /*optional*/ and it seems to work now, though
>> I am not so confidant in this configuration.
>> I wonder if there is a way to pass the client cert through to the python
>> proxy?
>>
>> Thanks,
>> G40
>>
>> On Tue, Jan 18, 2011 at 9:30 AM, Martin Kuba <makub@ics.muni.cz <mailto:
>> makub@ics.muni.cz>> wrote:
>>
>> Hi G40,
>>
>> the "SSLVerifyClient require" requires that the client presents a
>> certificate.
>> You have to configure also the list of Certification Authorities that
>> the server accepts by the following directives:
>>
>> SSLCACertificatePath /etc/ssl/certs/
>> or
>> SSLCACertificateFile /etc/apache2/ssl.crt/ca-bundle.crt
>>
>> If the client certificate is not signed by a root CA, but by some
>> intermediate CA,
>> which may be in turn signed by another intermediate CA, etc., you need
>> also
>> to set the value for SSLVerifyDepth to the highest length of the
>> certificate chain
>> that the client may provide.
>>
>> The "Allow" directives play no role in this, because the error you have
>> got
>> happened during the SSL handshake, which is sooner than the Allow
>> directives are applied.
>>
>> Martin
>>
>> Dne 18.1.2011 16:16, g f napsal(a):
>>
>> Hello all,
>> I have a debian os running Apache 2.2.16(debian) along with tomcat
>> 6.0.29. I use mod_jk as well as mod_auth_kerb module for apache. Apache and
>> the modules are debian repository packages.
>>
>> I recently attempted to activate common access cards and if I just
>> activate them but do not force them it works great.
>> Once I force access cards, I get the following error and my
>> web-apps break.
>>
>> Force access cards via:
>> |SSLVerifyClient require
>> SSLVerifyDepth 2|
>>
>> info level logging error.log:
>> [Tue Jan 18 14:47:07 2011] [info] [client 127.0.1.1] SSL library
>> error 1 in handshake (server myserver.xxx.xxx.xxx:443)
>> [Tue Jan 18 14:47:07 2011] [info] SSL Library Error: 336105671
>> error:140890C7:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return
>> a certificate No CAs known to server for verification?
>>
>> The web-app that throws this message uses a python proxy to make an
>> ajax call to a different web context (we do this to avoid the cross site
>> error).
>> I believe what is happening is that the python script [client
>> 127.0.1.1] is making the request to apache without valid client certs and
>> hence is getting denied.
>> I have a directive in apache2_home/sites-enabled/default-ssl conf
>> file that I had hoped would solve this issue(however it does not).
>> directive in default-ssl conf file
>> |Allow from localhost
>> Allow from 127.0.1.1
>> Allow from 127.0.0.1
>>
>> |Is there a solution to this issue?
>> Perhaps a way to not require client cert from localhost?
>> Thanks for any advice, much appreciated!
>>
>> Cheers,
>> G40
>>
>>
>>
>> --
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> Supercomputing Center Brno Martin Kuba
>> Institute of Computer Science email: makub@ics.muni.cz <mailto:
>> makub@ics.muni.cz>
>> Masaryk University http://www.ics.muni.cz/~makub/<http://www.ics.muni.cz/%7Emakub/><
>> http://www.ics.muni.cz/%7Emakub/>
>>
>> Botanicka 68a, 60200 Brno, CZ mobil: +420-603-533775
>> --------------------------------------------------------------
>>
>>
>>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Supercomputing Center Brno Martin Kuba
> Institute of Computer Science email: makub@ics.muni.cz
> Masaryk University http://www.ics.muni.cz/~makub/<http://www.ics.muni.cz/%7Emakub/>
> Botanicka 68a, 60200 Brno, CZ mobil: +420-603-533775
> --------------------------------------------------------------
>
>
Re: [users@httpd] SSL library error 1 in handshake
Posted by Martin Kuba <ma...@ics.muni.cz>.
Hi G40,
I am a bit confused from your description, I do not know what you mean
by "common access cards" and what you mean by forcing them.
Also I do not understand where is your python proxy, is it on the server or on the client ?
I have a suspicion that you are mixing the client and the server.
Is the configuration that you use a web browser with a certificate to access a URL
on the server, the URL is served by a python script that makes another HTTP call
to the same server ? If this is the case, it can't work, because the certificate
cannot be delegated from the server-side script to another server-side script.
The reason is that it is not the certificate alone what is needed to make
an authentication to an SSL server, also the private key is needed.
Cheers
Martin
Dne 18.1.2011 16:36, g f napsal(a):
> Hello Martin,
> thanks for the reply.
> I have those directives already and it all works until I add:
> /SSLVerifyClient *require*/
>
> I changed this directive to /*optional*/ and it seems to work now, though I am not so confidant in this configuration.
> I wonder if there is a way to pass the client cert through to the python proxy?
>
> Thanks,
> G40
>
> On Tue, Jan 18, 2011 at 9:30 AM, Martin Kuba <makub@ics.muni.cz <ma...@ics.muni.cz>> wrote:
>
> Hi G40,
>
> the "SSLVerifyClient require" requires that the client presents a certificate.
> You have to configure also the list of Certification Authorities that
> the server accepts by the following directives:
>
> SSLCACertificatePath /etc/ssl/certs/
> or
> SSLCACertificateFile /etc/apache2/ssl.crt/ca-bundle.crt
>
> If the client certificate is not signed by a root CA, but by some intermediate CA,
> which may be in turn signed by another intermediate CA, etc., you need also
> to set the value for SSLVerifyDepth to the highest length of the certificate chain
> that the client may provide.
>
> The "Allow" directives play no role in this, because the error you have got
> happened during the SSL handshake, which is sooner than the Allow directives are applied.
>
> Martin
>
> Dne 18.1.2011 16:16, g f napsal(a):
>
> Hello all,
> I have a debian os running Apache 2.2.16(debian) along with tomcat 6.0.29. I use mod_jk as well as mod_auth_kerb module for apache. Apache and the modules are debian repository packages.
>
> I recently attempted to activate common access cards and if I just activate them but do not force them it works great.
> Once I force access cards, I get the following error and my web-apps break.
>
> Force access cards via:
> |SSLVerifyClient require
> SSLVerifyDepth 2|
>
> info level logging error.log:
> [Tue Jan 18 14:47:07 2011] [info] [client 127.0.1.1] SSL library error 1 in handshake (server myserver.xxx.xxx.xxx:443)
> [Tue Jan 18 14:47:07 2011] [info] SSL Library Error: 336105671 error:140890C7:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return a certificate No CAs known to server for verification?
>
> The web-app that throws this message uses a python proxy to make an ajax call to a different web context (we do this to avoid the cross site error).
> I believe what is happening is that the python script [client 127.0.1.1] is making the request to apache without valid client certs and hence is getting denied.
> I have a directive in apache2_home/sites-enabled/default-ssl conf file that I had hoped would solve this issue(however it does not).
> directive in default-ssl conf file
> |Allow from localhost
> Allow from 127.0.1.1
> Allow from 127.0.0.1
>
> |Is there a solution to this issue?
> Perhaps a way to not require client cert from localhost?
> Thanks for any advice, much appreciated!
>
> Cheers,
> G40
>
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Supercomputing Center Brno Martin Kuba
> Institute of Computer Science email: makub@ics.muni.cz <ma...@ics.muni.cz>
> Masaryk University http://www.ics.muni.cz/~makub/ <http://www.ics.muni.cz/%7Emakub/>
> Botanicka 68a, 60200 Brno, CZ mobil: +420-603-533775
> --------------------------------------------------------------
>
>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Supercomputing Center Brno Martin Kuba
Institute of Computer Science email: makub@ics.muni.cz
Masaryk University http://www.ics.muni.cz/~makub/
Botanicka 68a, 60200 Brno, CZ mobil: +420-603-533775
--------------------------------------------------------------
Re: [users@httpd] SSL library error 1 in handshake
Posted by Alan Brown <em...@blueyonder.co.uk>.
Not sure if this is the cause of your problem but the phrase 'works until I add: SSLVerifyClient require' reminds me of a similar problem I encountered recently with SSL client certificates. In Apache documentation on SSL (or in Apache Cookbook) it doesn't mention that a client certificate must contain a private key as well as the actual cert itself.
Thus a composite file in a standard format called PKCS#12 (.p12 file extension) is needed, which you can create with the OpenSSL command :-
openssl pkcs12 -export -out client_a.p12 -in client_a.crt -inkey client_a.key
where client_a.crt is the client cert and client_a.key is the private key file.
This file can then be imported to a browser as a 'Personal Certificate'.
Without the private key on the client side SSL Handshake will not work.
HTH.
----- Original Message -----
From: g f
To: users@httpd.apache.org
Sent: Tuesday, January 18, 2011 3:36 PM
Subject: Re: [users@httpd] SSL library error 1 in handshake
Hello Martin,
thanks for the reply.
I have those directives already and it all works until I add:
SSLVerifyClient require
I changed this directive to optional and it seems to work now, though I am not so confidant in this configuration.
I wonder if there is a way to pass the client cert through to the python proxy?
Thanks,
G40
On Tue, Jan 18, 2011 at 9:30 AM, Martin Kuba <ma...@ics.muni.cz> wrote:
Hi G40,
the "SSLVerifyClient require" requires that the client presents a certificate.
You have to configure also the list of Certification Authorities that
the server accepts by the following directives:
SSLCACertificatePath /etc/ssl/certs/
or
SSLCACertificateFile /etc/apache2/ssl.crt/ca-bundle.crt
If the client certificate is not signed by a root CA, but by some intermediate CA,
which may be in turn signed by another intermediate CA, etc., you need also
to set the value for SSLVerifyDepth to the highest length of the certificate chain
that the client may provide.
The "Allow" directives play no role in this, because the error you have got
happened during the SSL handshake, which is sooner than the Allow directives are applied.
Martin
Dne 18.1.2011 16:16, g f napsal(a):
Hello all,
I have a debian os running Apache 2.2.16(debian) along with tomcat 6.0.29. I use mod_jk as well as mod_auth_kerb module for apache. Apache and the modules are debian repository packages.
I recently attempted to activate common access cards and if I just activate them but do not force them it works great.
Once I force access cards, I get the following error and my web-apps break.
Force access cards via:
|SSLVerifyClient require
SSLVerifyDepth 2|
info level logging error.log:
[Tue Jan 18 14:47:07 2011] [info] [client 127.0.1.1] SSL library error 1 in handshake (server myserver.xxx.xxx.xxx:443)
[Tue Jan 18 14:47:07 2011] [info] SSL Library Error: 336105671 error:140890C7:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return a certificate No CAs known to server for verification?
The web-app that throws this message uses a python proxy to make an ajax call to a different web context (we do this to avoid the cross site error).
I believe what is happening is that the python script [client 127.0.1.1] is making the request to apache without valid client certs and hence is getting denied.
I have a directive in apache2_home/sites-enabled/default-ssl conf file that I had hoped would solve this issue(however it does not).
directive in default-ssl conf file
|Allow from localhost
Allow from 127.0.1.1
Allow from 127.0.0.1
|Is there a solution to this issue?
Perhaps a way to not require client cert from localhost?
Thanks for any advice, much appreciated!
Cheers,
G40
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Supercomputing Center Brno Martin Kuba
Institute of Computer Science email: makub@ics.muni.cz
Masaryk University http://www.ics.muni.cz/~makub/
Botanicka 68a, 60200 Brno, CZ mobil: +420-603-533775
--------------------------------------------------------------
Re: [users@httpd] SSL library error 1 in handshake
Posted by g f <gf...@gmail.com>.
Hello Martin,
thanks for the reply.
I have those directives already and it all works until I add:
*SSLVerifyClient require*
I changed this directive to *optional* and it seems to work now, though I am
not so confidant in this configuration.
I wonder if there is a way to pass the client cert through to the python
proxy?
Thanks,
G40
On Tue, Jan 18, 2011 at 9:30 AM, Martin Kuba <ma...@ics.muni.cz> wrote:
> Hi G40,
>
> the "SSLVerifyClient require" requires that the client presents a
> certificate.
> You have to configure also the list of Certification Authorities that
> the server accepts by the following directives:
>
> SSLCACertificatePath /etc/ssl/certs/
> or
> SSLCACertificateFile /etc/apache2/ssl.crt/ca-bundle.crt
>
> If the client certificate is not signed by a root CA, but by some
> intermediate CA,
> which may be in turn signed by another intermediate CA, etc., you need also
> to set the value for SSLVerifyDepth to the highest length of the
> certificate chain
> that the client may provide.
>
> The "Allow" directives play no role in this, because the error you have got
> happened during the SSL handshake, which is sooner than the Allow
> directives are applied.
>
> Martin
>
> Dne 18.1.2011 16:16, g f napsal(a):
>
> Hello all,
>> I have a debian os running Apache 2.2.16(debian) along with tomcat 6.0.29.
>> I use mod_jk as well as mod_auth_kerb module for apache. Apache and the
>> modules are debian repository packages.
>>
>> I recently attempted to activate common access cards and if I just
>> activate them but do not force them it works great.
>> Once I force access cards, I get the following error and my web-apps
>> break.
>>
>> Force access cards via:
>> |SSLVerifyClient require
>> SSLVerifyDepth 2|
>>
>> info level logging error.log:
>> [Tue Jan 18 14:47:07 2011] [info] [client 127.0.1.1] SSL library error 1
>> in handshake (server myserver.xxx.xxx.xxx:443)
>> [Tue Jan 18 14:47:07 2011] [info] SSL Library Error: 336105671
>> error:140890C7:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return
>> a certificate No CAs known to server for verification?
>>
>> The web-app that throws this message uses a python proxy to make an ajax
>> call to a different web context (we do this to avoid the cross site error).
>> I believe what is happening is that the python script [client 127.0.1.1]
>> is making the request to apache without valid client certs and hence is
>> getting denied.
>> I have a directive in apache2_home/sites-enabled/default-ssl conf file
>> that I had hoped would solve this issue(however it does not).
>> directive in default-ssl conf file
>> |Allow from localhost
>> Allow from 127.0.1.1
>> Allow from 127.0.0.1
>>
>> |Is there a solution to this issue?
>> Perhaps a way to not require client cert from localhost?
>> Thanks for any advice, much appreciated!
>>
>> Cheers,
>> G40
>>
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Supercomputing Center Brno Martin Kuba
> Institute of Computer Science email: makub@ics.muni.cz
> Masaryk University http://www.ics.muni.cz/~makub/<http://www.ics.muni.cz/%7Emakub/>
> Botanicka 68a, 60200 Brno, CZ mobil: +420-603-533775
> --------------------------------------------------------------
>
>
Re: [users@httpd] SSL library error 1 in handshake
Posted by Martin Kuba <ma...@ics.muni.cz>.
Hi G40,
the "SSLVerifyClient require" requires that the client presents a certificate.
You have to configure also the list of Certification Authorities that
the server accepts by the following directives:
SSLCACertificatePath /etc/ssl/certs/
or
SSLCACertificateFile /etc/apache2/ssl.crt/ca-bundle.crt
If the client certificate is not signed by a root CA, but by some intermediate CA,
which may be in turn signed by another intermediate CA, etc., you need also
to set the value for SSLVerifyDepth to the highest length of the certificate chain
that the client may provide.
The "Allow" directives play no role in this, because the error you have got
happened during the SSL handshake, which is sooner than the Allow directives are applied.
Martin
Dne 18.1.2011 16:16, g f napsal(a):
> Hello all,
> I have a debian os running Apache 2.2.16(debian) along with tomcat 6.0.29. I use mod_jk as well as mod_auth_kerb module for apache. Apache and the modules are debian repository packages.
>
> I recently attempted to activate common access cards and if I just activate them but do not force them it works great.
> Once I force access cards, I get the following error and my web-apps break.
>
> Force access cards via:
> |SSLVerifyClient require
> SSLVerifyDepth 2|
>
> info level logging error.log:
> [Tue Jan 18 14:47:07 2011] [info] [client 127.0.1.1] SSL library error 1 in handshake (server myserver.xxx.xxx.xxx:443)
> [Tue Jan 18 14:47:07 2011] [info] SSL Library Error: 336105671 error:140890C7:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return a certificate No CAs known to server for verification?
>
> The web-app that throws this message uses a python proxy to make an ajax call to a different web context (we do this to avoid the cross site error).
> I believe what is happening is that the python script [client 127.0.1.1] is making the request to apache without valid client certs and hence is getting denied.
> I have a directive in apache2_home/sites-enabled/default-ssl conf file that I had hoped would solve this issue(however it does not).
> directive in default-ssl conf file
> |Allow from localhost
> Allow from 127.0.1.1
> Allow from 127.0.0.1
>
> |Is there a solution to this issue?
> Perhaps a way to not require client cert from localhost?
> Thanks for any advice, much appreciated!
>
> Cheers,
> G40
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Supercomputing Center Brno Martin Kuba
Institute of Computer Science email: makub@ics.muni.cz
Masaryk University http://www.ics.muni.cz/~makub/
Botanicka 68a, 60200 Brno, CZ mobil: +420-603-533775
--------------------------------------------------------------
Re: [users@httpd] SSL library error 1 in handshake
Posted by Joost de Heer <jo...@sanguis.xs4all.nl>.
On Tue, January 18, 2011 16:16, g f wrote:
> Hello all,
> I have a debian os running Apache 2.2.16(debian) along with tomcat 6.0.29.
> I
> use mod_jk as well as mod_auth_kerb module for apache. Apache and the
> modules are debian repository packages.
>
> I recently attempted to activate common access cards and if I just
> activate
> them but do not force them it works great.
> Once I force access cards, I get the following error and my web-apps
> break.
[...]
> Is there a solution to this issue?
> Perhaps a way to not require client cert from localhost?
> Thanks for any advice, much appreciated!
An example that looks somewhat like what you want can be found at
http://httpd.apache.org/docs/2.2/ssl/ssl_howto.html#intranet
Joost
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org