User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; it; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; it; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 I have two bank accounts, both with home banking using SSL client authentication, both certificates have been emitted by the same CA. Everytime I use the homebanking, with default SSL settings, firefox ask me for the certificate to use for every file it downloads from HTTPS (included images, javascript and css) and it never auto-highlight the last certificate I selected for that site. If I change SSL settings, enabling the "autoselection" of the certificate it always select the first certificate it finds for the CA, even if it's not the right certificate for that site. Why don't permit the user to select a default certificate for every site (as in Konqueror) or to permit to flag as default a certificate when the user is prompted for it the first time? Reproducible: Always

While this bug does have to do with our security settings, it doesn't need to be hidden like a security exploit would. I'm unhiding it so more people can see it. The behaviour you describe definitely does sound frustrating.

The fact that your bank's https web site keeps prompting your to choose a cert is due to the configuration of your bank's https server. It is possible, and desirable, to configure such servers in a way that will not keep doing that. I suggest you ask your bank to enable the "SSL server session cache".

You could also change your pref from "Ask me every time" to "Select one Automatically" -- but be aware that raises some potentially serious privacy issues since any site on the internet can then ask you for that cert and possibly get private details about you (depends on what's in the certificate).

In reply to comment 3, Dan, in comment 0, the reporter wrote: > enabling the "autoselection" of the certificate it always select the first > certificate it finds for the CA, even if it's not the right certificate > for that site. This is indeed an issue with automatic selection. It searches the unexpired user certs that are capable of being used for signature verification and are issued by any of the CAs specified by the server, and takes the first one of those that it finds. It has no way to automatically make any finer selection. Allowing the user to record a cert choice for an individual server would be an interesting enhancement. However, it would mask the problems with badly configured servers, which ultimately leads to more misconfigured servers. This is what we learned from the browser storing CA certs and filling in certs chains from servers that send incomplete chains: doing so has led to a dramatic increase in the number of misconfigured servers, because the mechanism that previously led to the correction of the misconfiguration (namely, the user complaining to the server owner) no longer occurs, so the server owner never learns of his mistake. The cost to both client and server of the server supplying a missing cert is negligible. The cost of doing many unnecessary client authentications is not. I think this bug is really an enhancement requrest for per-server client auth cert configuration. The present situation, while unpleasant for the user, is not erroneous in any way, not a "bug" in the client. If there is a "bug", it is the server's lack of an SSL session cache.

Duplicate of bug 416809 and/or bug 149673?

This behaviour exists since 2.0.0.13, until that version I never experienced such a problem. I personally configured https for cartaservizi.regione.fvg.it, an italian e-government site, requiring a smart-card to identify users, disabling the SSL session cache permits me to handle card removals, since the server asks for the client certificate every time the browser sends a request. For cartaservizi.regione.fvg.it "Select one Automatically" is a "fix": it's extremely rare that a user has more than one smart-card loaded on its computer at the same time, but for my home-banking I have 2 accounts and I MUST be able to select the authentication certificate just once per session, just like IE permits, so to access the right account.

Jesse, are there any Mozilla developers who are actually interested in solving these usability problems? Bug 416809 and this bug really describe different facets of the same overall client cert usability issue, and they propose different solutions. If SSL servers properly implemented the SSL session cache, users could leave their preference set to "ask me every time" and still would not be inundated with certificate selection requests. IMO. FF users ought to be evangelizing their server admins on the virtues of server session caches. I can think of two possible and reasonable enhancements that could be made to FF3 that would help with this. 1. Add a feature to forget the client's SSL session cache information for the server from which the current page is served. This would forget a single session, as opposed to forgetting all sessions at once, which is presently offered in Tools->"Clear Private Data". I would recommend that this "clear one session" feature should be less buried than the "clear private data" dialog now is. 2. Add a feature that simply remembers, for the lifetime of the process, the user's most recent choice of certificate for a particular server. After the user chooses a cert for a server, we keep reusing that choice until the process ends or the user clears the session info for that server. This would be a PSM feature, with the new memory of certificate choice for servers being maintained by PSM. This could be done with no new UI. This feature would be used in the "ask me every time" mode. If UI czars want to help, they could add this as a third mode (alternative to "choose automatically" and "ask me every time"), although I would expect that the "ask me every time" choice would quickly fall into disuse, given those three choices. This feature has at least one drawback. It reduces or eliminates all pressure on open source server designers to ever fix their nonfunctional SSL session caches. Because frequent client authentication is SO MUCH MORE CPU intensive (on both ends) than infrequent client authentication (which you get for free with an SSL session cache), as long as servers continue to fail to implement SSL session caches, SSL client authenticated connections will continue to be widely regarded as CPU resource hogs. This will actually hinder adoption of client authentication MORE in the long run than will the present situation of having to respond to too many client cert selection dialogs.

(In reply to comment #7) > 2. Add a feature that simply remembers, for the lifetime of the process, > the user's most recent choice of certificate for a particular server. Is this a duplicate of bug 395399, or different because it's a variant that requests only process-lifetime memory and requires no new UI?

(In reply to comment #7) > This feature has at least one drawback. It reduces or eliminates all > pressure on open source server designers to ever fix their nonfunctional > SSL session caches. Because frequent client authentication is SO MUCH MORE > CPU intensive (on both ends) than infrequent client authentication (which > you get for free with an SSL session cache), as long as servers continue to > fail to implement SSL session caches, SSL client authenticated connections > will continue to be widely regarded as CPU resource hogs. This will actually > hinder adoption of client authentication MORE in the long run than will > the present situation of having to respond to too many client cert selection > dialogs. Again, just as bug#149673 comment#28... The discussion is regarding *USER EXPERIENCE* and not technical experience. A user does not expect to select his certificate again once he selected it oncefor a target server, exactly as he does not expect to enter his user/password again and again. The SSL session cache is *CACHE* it can be dropped from whatever reason at the client or server side. And may be created if the client needs more sessions (such as file transfer or AJAX), or even in load balancing farm. The web client application should remember that the user already selected credentials (may be client certificate, user and password or any) for target server, and reuse them even if the session is reestablished (it can be socket, SSL cached or SSL new). The fact that the user should be bothered because of a technical limitation of the protocol or failover is unacceptable. So all the resource consumption discussion or server configuration is irrelevant. You guys won't be the trigger to teach developers/admins how to properly configure or develop their applications. Most of them knows what they are doing, and dropping the cache is one valid option they have. Please consider mark as dup of bug#149673.

I am having the same issue described here and this is really causing issues with many of our customers. Please help! This is not a server side issue due to ssl session. We have following setting on ssl.conf SSLSessionCache shmcb:/var/cache/mod_ssl/scache(512000) SSLSessionCacheTimeout 1800 Also, this issue only occurs if "SSLVerifyClient require" is inside the <Location> tag in apache configuration such as below. <Location /oim> SSLVerifyClient require SSLOptions +StdEnvVars +ExportCertData </Location> If we take SSLVerifyClient outside, the problem disappears (Firefox will not ask Certificate repeatedly). We can't do this however since /oim is the only path that needs to have SSL certificate required. I know that this sounds like Apache issue, but since no other browsers exhibit similar issue including IE, I strongly believe that there is something that Firefox needs to do to correct this problem regardless of Firefox is ultimately doing right thing or not..

In reply to comment 11: This is absolutely a server side issue. If the server did properly reuse SSL sessions, the browser would not prompt you to select a certificate. The browser ONLY prompts you when the server has a requests a certificate, and a server CANNOT request a certificate in a handshake that is re-using a previously established SSL session. If your business is affected by this server bug, then you've got a strong incentive to push on the developers of the server software on which you rely, to fix this bug.

(In reply to comment #12) > In reply to comment 11: > This is absolutely a server side issue. If the server did properly reuse > SSL sessions, the browser would not prompt you to select a certificate. > The browser ONLY prompts you when the server has a requests a certificate, > and a server CANNOT request a certificate in a handshake that is re-using > a previously established SSL session. If your business is affected by this > server bug, then you've got a strong incentive to push on the developers of > the server software on which you rely, to fix this bug. I do not agree that this is *absolutely* a server side issue since no other browsers (that I could test with) demonstrate this issue. Maybe they all have a workaround for this *server side issue* so that the user will not get affected? What is your thought?

This is *NOT* a server side issue, see comment#10.

Regarding comment 10, I agree that this bug seems to be a duplicate of bug 149673, which is also a server side issue. If Patrizio agrees (since it's his bug) and Johnathan has no objection, I will mark this bug as a duplicate of bug 149673. soichih, Your comment 11 suggests that you have a reproducible test case. It would be very helpful to capture all the SSL connections between one browser and your server, demonstrating the behavior, using a tool like ssldump or ssltap. You could then take the detailed humanly readable output and zip it up and attach it to this bug (even if this bug becomes resolved). ssldump is very powerful, but is more difficult to understnad and use. It can capture multiple simultaneous TCP connections. It has an option to decrypt the traffic, if you give it the private keys, but this is not at all necessary for our purposes. ssltap is very simple to use, but only handles one connection at a time. That limitation might change the behavior of the tests.

Soichih, alternatively, add a comment to this bug with complete steps to reproduce, so that any browser developer can reproduce the problem by visiting a URL you supply that visits your server.

(In reply to comment #15) > soichih, Your comment 11 suggests that you have a reproducible test case. Kai, if you want a reproducible test case for this, then try to log into koji.fedoraproject.org :)