You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by VP <rp...@gmail.com> on 2012/10/09 13:18:17 UTC
[users@httpd] Re: Client certificate authentication issues
Any pointers or help please?
On Tue, Oct 9, 2012 at 11:38 AM, VP <rp...@gmail.com> wrote:
> Dear All,
>
> I have been facing this particular issue for quite sometime now and
> don’t know what exactly is causing this. The issue is with client
> certificate authentication. 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
> [Mon Sep 10 17:42:08 2012] [error] [client xx.xx.xx.xx] Re-negotiation
> request failed, referer: https://xxx.xx.com/LoginForms/login.jsp
> [Mon Sep 10 17:42:08 2012] [error] SSL Library Error: 336126196
> error:1408E0F4:SSL routines:SSL3_GET_MESSAGE:unexpected message
>
> I tried to search on the internet but was unsuccessful. Any ideas or
> pointers on where this issue could be? We tried to duplicate this on
> our TEST environment, but we couldn’t reproduce it. The environment is
> same across TEST and PROD.
>
> Our environment:
> OS:
> RHEL 6.3
>
> Apache:
> Server version: Apache/2.2.15 (Unix)
> Server built: Feb 7 2012 09:50:11
>
> Mod_SSL:
> Mod SSL - 2.2.15-15.el6_2.1.i686
>
> OpenSSL:
> OpenSSL 1.0.0-fips 29 Mar 2010
>
> Thank you in advance,
>
> VP
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Re: Client certificate authentication issues
Posted by VP <rp...@gmail.com>.
Thank you Toomas. I will also try these settings and see what I get. I
am currently running OpenSSL 1.0.0 version with Apache 2.2.15.
Regards,
VP
On Tue, Oct 16, 2012 at 3:58 PM, Toomas Aas <to...@raad.tartu.ee> wrote:
> I have had my share of trouble with client certificate authentication / SSL
> renegotiation. It is difficult to troubleshoot. In addition to what Mark
> already suggested, here are some other things that may help:
>
> 1. Try to reduce the possible amount of SSL protocols and ciphers that
> client and server are going to negotiate about. I have following settings in
> use now:
>
> SSLProtocol -All +SSLv3 +TLSv1
> SSLCipherSuite !DH:HIGH
>
> 2. Reduce the amount of possible renegotiation attempts. Inside the
> <Location> block where you have "SSLVerifyClient require", add "SSLOptions
> +OptRenegotiate". The manual does not recommend to turn it on for global
> configuration or entire vhost but restrict it to some specific <Location> or
> <Directory> only.
>
> 3. For compatibility with older browsers, you may need to turn on
> SSLInsecureRenegotiation. Be aware that this opens your SSL sessions to
> possible man-in-the-middle attack (CVE-3555), but in some cases the only
> other option is that clients won't be able to access your site at all - you
> can't unfortunately always tell everyone to upgrade their browser.
>
> 4. Make sure you are not using some very old version of OpenSSL.
>
> --
> Toomas Aas
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Re: Client certificate authentication issues
Posted by Toomas Aas <to...@raad.tartu.ee>.
I have had my share of trouble with client certificate authentication
/ SSL renegotiation. It is difficult to troubleshoot. In addition to
what Mark already suggested, here are some other things that may help:
1. Try to reduce the possible amount of SSL protocols and ciphers that
client and server are going to negotiate about. I have following
settings in use now:
SSLProtocol -All +SSLv3 +TLSv1
SSLCipherSuite !DH:HIGH
2. Reduce the amount of possible renegotiation attempts. Inside the
<Location> block where you have "SSLVerifyClient require", add
"SSLOptions +OptRenegotiate". The manual does not recommend to turn it
on for global configuration or entire vhost but restrict it to some
specific <Location> or <Directory> only.
3. For compatibility with older browsers, you may need to turn on
SSLInsecureRenegotiation. Be aware that this opens your SSL sessions
to possible man-in-the-middle attack (CVE-3555), but in some cases the
only other option is that clients won't be able to access your site at
all - you can't unfortunately always tell everyone to upgrade their
browser.
4. Make sure you are not using some very old version of OpenSSL.
--
Toomas Aas
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Re: Client certificate authentication issues
Posted by Mark Montague <ma...@catseye.org>.
On October 15, 2012 6:11 , VP <rp...@gmail.com> wrote:
> 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
I am not an expert, but according to what I understand: yes, in the
scenario you describe, renegotiation would still be triggered. The
reason is that when the client establishes the initial SSL connection,
it has not yet sent the HTTP request. The server does not know what URI
path the client will be accessing, it only knows that there are some URI
paths for which certificates are required and some for which
certificates are not required, so it negotiates the connection without
client side certificates. (Keep in mind that "SSLVerifyClient" does not
work reliably with all clients -- so I'm assuming you have
"SSLVerifyClient require" set for the /secure Location). After the SSL
session is established, the client sends the HTTP GET request for
/secure. The server sees that a client certificate is required, that no
client certificate was previously provided (because the SSL session was
established with "SSLVerifyClient none"), and the server triggers
renegotiation.
The only sure way around this problem that I know about is to specify
"SSLVerifyClient require" in the virtual host context or global server
context so that it applies to al URI and filesystem paths. The server
will then require a client certificate in the initial SSL negotiation
for all connections, and renegotiation should never be triggered.
--
Mark Montague
mark@catseye.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Re: Client certificate authentication issues
Posted by VP <rp...@gmail.com>.
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 <rp...@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 <ma...@catseye.org> wrote:
>> On October 9, 2012 7:18 , VP <rp...@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
>> mark@catseye.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Re: Client certificate authentication issues
Posted by VP <rp...@gmail.com>.
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 <ma...@catseye.org> wrote:
> On October 9, 2012 7:18 , VP <rp...@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
> mark@catseye.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Re: Client certificate authentication issues
Posted by Mark Montague <ma...@catseye.org>.
On October 9, 2012 7:18 , VP <rp...@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
mark@catseye.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org