User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:2.0) Gecko/20110321 Firefox/4.0 Build Identifier: Mozilla/5.0 (X11; Linux x86_64; rv:2.0) Gecko/20110321 Firefox/4.0 This was also reported on the Firefox support site: https://support.mozilla.com/en-US/questions/811718 When a web server is configured to require client certificates conditionally -- e.g. only for certain URLs, then it breaks the next un-authenticated request *after* the authenticated request. When it was a page request, Firefox refuses the renegotiation and displays the usual SSL error screen with error code "ssl_error_handshake_unexpected_alert". However, if the authenticated page doesn't redirect, it can also manifest in failing to load some media file (CSS or JS). After a refresh everything will work again, because it creates a new non-client-authenticated SSL session. Apache logs the following error every time: [Thu Apr 21 19:48:04 2011] [error] [client X.Y.Z.W] Re-negotiation handshake failed: Not accepted by client!?, referer: https://example.org/ An example Apache configuration to reproduce this error looks like this: <VirtualHost MY-IP-ADDRESS:443> SSLEngine on SSLCertificateFile ... SSLCertificateKeyFile ... <Location ~ "^/cert-login/"> SSLCACertificatePath /path/to/ca SSLVerifyClient require SSLVerifyDepth 2 </Location> </VirtualHost> Reproducible: Always Actual Results: SSL error page with ssl_error_handshake_unexpected_alert Expected Results: Loading the un-authenticated page
Does your server support secure renegotiation? To check, go to https://www.ssllabs.com/, put your server's domain name into the "Test Your SSL Server Now!" input box, and click Submit. SSLLabs will do a bunch of tests which take a while. Afterwards, in the report you will see a line in the "Miscellaneous" section called "Renegotiation", with the value "Secure Renegotiation Supported." If you see something else, then your server doesn't support secure renegotiation; enabling it to resolve this issue. How you enable it depends on the server and/or SSL accelerator (load balancer) you are using. If your server already supports secure renegotiation or enabling secure renegotiation doesn't help, then it might be a bug in Firefox. Either way, please post a reply in this bug with the results of your testing.
Thanks. Yes, the SSL Labs test says "This server supports secure renegotiation" and scores 85%.
What was the latest version of Firefox that worked? 3.6? Do you know if any of the 4.0 betas worked?
Yeah, Firefox 3.6.8 - 3.6.10 don't have this problem. The earliest 4.0 version where I tried smartcard authentication was IIRC around RC 10 or 11 and that was already broken.
I'm not at all familiar with the Firefox codebase, but is there anything I can do to help solve this problem?
(In reply to comment #5) > I'm not at all familiar with the Firefox codebase, but is there anything I can > do to help solve this problem? We need a test case that we can use, and the certificates to test it. I don't want to build the test case on your production system. If somebody could post a set of Apache(?) configuration files and instructions for generating the necessary certs and keys--without any sensitive info that would compromise their production systems' security--that would give us a great head-start in figuring out what is wrong.
Created attachment 528818 [details] Configuration package to reproduce the bug This tarball contains files necessary to reproduce said bug. 1. Copy all files from the archive to /tmp/certtest/ 2. Drop certtest.conf to your Apache vhosts directory -- on Ubuntu/Debian that's /etc/apache2/sites-enabled 3. Enable Apache 'ssl' and 'alias' modules if necessary, restart Apache 4. Install /tmp/some_user_cert.pfx as a Firefox client certificate 5. Navigate to https://127.0.0.1:8443/ and accept the self-signed server certificate 6. The page should open -- if it's a 404 page then everything went OK, doesn't matter for our test 7. Enter the URL https://127.0.0.1:8443/cert 8. Observe that the request to /cert went fine, but when the server redirects you back to /, Firefox refuses re-negotiation and displays the "ssl_error_handshake_unexpected_alert" page 9. A simple refresh fixes the error. 10. Observe message in Apache logs: [error] [client 127.0.0.1] Re-negotiation handshake failed: Not accepted by client!?
Marti, can you try using the following tool to identify a regression range for this bug? http://harthur.github.com/mozregression/ Thanks
The problem has now disappeared in Nightly: Last bad nightly: 2011-05-05 First good nightly: 2011-05-06 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=31879b88cc82&tochange=88fdbd974f82 Further track down with Tinderbox http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2f2d4de42515&tochange=92d5e760e0c0
Reproduced: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:220.127.116.11) Gecko/20110420 Firefox/3.6.17 Mozilla/5.0 (X11; Linux x86_64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1 Mozilla/5.0 (X11; Linux x86_64; rv:5.0a2) Gecko/20110524 Firefox/5.0a2 Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20100101 Firefox/5.0 WFM: Mozilla/5.0 (X11; Linux x86_64; rv:7.0a1) Gecko/20110527 Firefox/7.0a1
(In reply to comment #4) > Yeah, Firefox 3.6.8 - 3.6.10 don't have this problem. I've used the testcase in comment 7, but even 3.6.8 - 3.6.10 seem broken to me and so far I've not found an old version that works for me. Thus, reproduced: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:18.104.22.168) Gecko/20100722 Firefox/3.6.8 Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:22.214.171.124) Gecko/20100824 Firefox/3.6.9 Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:126.96.36.199) Gecko/20100914 Firefox/3.6.10 h
Local track down with GNU/Linux shows when Nightly went good. The first good revision is: changeset: 68988:29f3dc7ad5db user: Kai Engert <firstname.lastname@example.org> date: Thu May 05 16:35:11 2011 +0200 summary: Bug 642148 - Upgrade Mozilla to NSPR 4.8.8 beta 3 and NSS 3.12.10 beta 1, r=wtc, r=kaie
Marti, can you please confirm that this bug isn't an issue any more using recent versions of Firefox?
Yes, this problem has been fixed for a while now. Sorry that I forgot to update this bug.