httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Kuba <>
Subject Re: [users@httpd] SSL library error 1 in handshake
Date Wed, 19 Jan 2011 07:50:31 GMT
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
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 /*protected_app*/*_A*
> protected_app requires data from some_other_protected_app using ajax and a pseudo proxy
> /*protected_app_A*/pseudo_proxy_Servlet/ makes a URLConnection to
(to avoid the javascript cross site scripting error) to
> /*protected_app_B*/web-service/
> Apache attempts to authenticate this request coming from
> /*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,
and use "SSLVerifyClient required" for and ""SSLVerifyClient none" for localhost.
Something like

   ServerName localhost
   SSLEngine on
   SSLVerifyClient none
<VirtualHost *:443>
   SSLEngine on
   SSLVerifyClient required

> 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

You cannot forward certificates, because they do not work without their associated private


Supercomputing Center Brno             Martin Kuba
Institute of Computer Science    email:
Masaryk University   
Botanicka 68a, 60200 Brno, CZ     mobil: +420-603-533775

View raw message