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: ma...@ics.muni.cz Masaryk University http://www.ics.muni.cz/~makub/ Botanicka 68a, 60200 Brno, CZ mobil: +420-603-533775 --------------------------------------------------------------
smime.p7s
Description: S/MIME Cryptographic Signature
