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 <ma...@ics.muni.cz <mailto: >> 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: ma...@ics.muni.cz <mailto: >> ma...@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: 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 > -------------------------------------------------------------- > >
