Hi Mark, I am still continuing my search to find other solutions to fix my issue. I have a question. Lets say even if my SSLVerifyClient in is Location block called "secure". Would the SSL Renegotiation still trigger if the user types in direct URL the very first time? Like calling:
https://www.something.com/secure Instead of: https://www.something.com and then clicking on hyperlink on the homepage which will take the user to https://www.something.com/secure Regards, VP On Tue, Oct 9, 2012 at 8:49 PM, VP <rpeyy...@gmail.com> wrote: > 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, > VP > > > On Tue, Oct 9, 2012 at 5:50 PM, Mark Montague <m...@catseye.org> wrote: >> 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
