httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From VP <>
Subject Re: [users@httpd] Re: Client certificate authentication issues
Date Tue, 09 Oct 2012 15:19:53 GMT
Dear Mark,

Thank you so much for your email.

Yes, I have 'SSLVerifyClient require' set in 'Location' block. I also
believe this is the root cause of the problem but this occurs only for
few IE clients and not all. I also noticed that it happens for few
users who use Windows 7. Perhaps, there is some service pack on the
client workstation which could be causing this. I am unable to
reproduce no matter what setting I tweak in IE.

I also cannot move SSLVerifyClient to VH level because it would break
my web application. I would look into your suggestion about creating
another VH and SSL redirecting traffic to it. Any other ideas are
definitely welcome!

Thanks once again,

On Tue, Oct 9, 2012 at 5:50 PM, Mark Montague <> wrote:
> On October 9, 2012 7:18 , VP <> wrote:
>> We have noticed that for few users, client
>> certificate authentication fails – i.e. browser prompts for client
>> certificate in a popup window and after I choose the appropriate
>> personal certificate and submit, it then immediately shows me IE’s
>> “Page cannot be found” error. This happened both for IE7 and IE8 on
>> Windows 7 but it is not consistent – meaning this error comes only to
>> specific end users. For most of them it seems to work but not few.
>> This is a public site with proper certificates installed which were
>> procured from VeriSign.
>> In the ssl error log, I see this error:
>> [Mon Sep 10 17:42:08 2012] [error] [client xx.xx.xx.xx] Re-negotiation
>> handshake failed: Not accepted by client!?, referer:
> It seems like the web browser is rejecting the server's attempt at SSL
> renegotiation.  I suggest trying to avoid this problem by configuring the
> web server so that it does not request SSL renegotiation.
> Apache HTTP Server will request SSL renegotiation any time an SSL session is
> already established but a request is made for a per-location context which
> requires different security -- for example, if you have the SSLVerifyClient
> directive in a Directory or Location block.
> If you determine this to be the problem, a solution is to move the
> SSLVerifyClient directive "up" so that it is in the VirtualHost context and
> applies to the entire vhost.  This way, the client certificate will be
> verified for all connections, regardless of what URI path the client
> requests, and SSL renegotiation will not be triggered for some client
> requests.
> I encountered this problem with a server I had, but it was not feasible to
> have SSLVerifyClient apply for the entire vhost; it would have broken the
> web application in question.  So what I did was create a separate SSL vhost
> on port 444 that handled only the URI paths for which client certificate
> verification was necessary. The original SSL vhost on port 443 was
> configured to redirect these paths to https://servername:444/   This was an
> awkward solution, but it worked.
> Another thing to check:  make sure that you do not use "SSLVerifyClient
> optional", only use "SSLVerifyClient require". I've seen "SSLVerifyClient
> optional" cause problems with several web browsers (in particular, with
> recent versions of Safari).
> Good luck.  I hope this helps.
> --
>   Mark Montague

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message