Re: SSL library error 1 in handshake

[g f <gforty@xxxxxxxxx>]

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@xxxxxxxxxxx> 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@xxxxxxxxxxx <mailto:makub@xxxxxxxxxxx>> 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@xxxxxxxxxxx <mailto:makub@xxxxxxxxxxx>
 Â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@xxxxxxxxxxx
Masaryk University       http://www.ics.muni.cz/~makub/
Botanicka 68a, 60200 Brno, CZ Â Â mobil: +420-603-533775
--------------------------------------------------------------