On October 9, 2012 7:18 , VP <rpeyy...@gmail.com> 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:
https://xxx.xxx.com/LoginForms/login.jsp

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
  m...@catseye.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Reply via email to