Some browser version numbers would be good, as well as some more information on what else is on that server.
Based on what you have provided, it sounds like there are other SSL certs on that server, and the non-firefox browsers are getting one of the others? From here I'll hazard a guess that the cert they're getting is from the default virtualhost? I'll also hazard a guess that you're testing from a Windows XP system.
Where I'm going with this is that you've got multiple SSL certificates all bound to the same port, and a different one should be presented based on what host name is being visited. This depends on Server Name Indication, which isn't supported by older browsers or by XP's encryption libraries.
Unfortunately, the workarounds for this (which you'll need, there's too many old browsers out there still) are non-trivial; buy a new certificate that'll cover everything on that port (a wildcard or Subject Alternate Name cert), or add an extra IP to the server for the other VirtualHost to listen on with just its own cert.
Most likely the server/network setup has an issue somewhere and is not caused by any IE9 quirks.
First off get rid of the ancient pre IE6 config: SetEnvIf User-Agent ".MSIE." \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0 and just try running with out that at all (in any forms). Unless you need to support IE5 which i doubt you do in which case you are correct to change the regex to MSIE [2-5]
The Load balancer and having no keepalive is likely the problem. I would be very suspicious of the load balancer and check exactly what is going on there first.
A load balancer will usually 'balance load' between two or more ip addresses (internal or external it doesn't matter at this point).
Then having no keepalive on connections between requests the client computer/browser will have to perform SSL negotiation for every request. Combine this with slowness and low timeout settings and we can get SSL cert mismatching issues and IE will probably bail because of strict security setup. I haven't investigated exactly if IE9 has this trait only. I would suspect other browsers do this too and deal with it differently.
If you are using SSL you should have KeepAlive on as it will make the site much faster and not have to go through SSL Negotiation over and over thus failing because the load balancer is not keeping the session on the same server during the lifetime of the visitor.
If your application is internal (on an intranet) your load balancer is randomly jumping ip addresses on you and SSL needs it to be the same per connection.
If it is not on an intranet the same could be true, I don't know how your network is setup but you should check into that first. Disable the load balancer and see if the problem exists. and definately put keep alive on.
http://httpd.apache.org/docs/2.2/mod/core.html#keepalive
I would also check if you got reverse dns setup at all. If it is pointing to the load balancer or the server behind the load balancer or what not.
Test your connection and analyze your headers, if external use something like redbot.org or webpagetest.org to check what headers are sent out. Also you can use something like fiddler
Best Answer
The issue seemed to center mostly around uploading files to a host via an SSL secured session.
MS says it's been fixed as of IE7. Mentioned at the end of this article: http://blogs.technet.com/askperf/archive/2007/11/09/internet-explorer-and-ssl-closure-alerts.aspx
If it's still there in the latest version of Apache, I'd err on the side of caution and keep it in there. The performance hit for your server and IE clients is not as bad as rendering them unable to access parts of the site.