httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From g f <gfo...@gmail.com>
Subject Re: [users@httpd] SSL library error 1 in handshake
Date Tue, 18 Jan 2011 17:12:46 GMT
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 <makub@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
> --------------------------------------------------------------
>
>

Mime
View raw message