SSL Re-negotiation rejected by MS client when keepalives disabled in apache

One of our partners is using Microsoft Web Services 2.0 to connect to our webservices through Apache HTTPD 2.0 reverse-proxies. The resource they're POSTing to requires client (mutual) ssl authentication:

<Location /SecuredArea>
    SSLVerifyClient require
    SSLDepth 10
    SSLCACertificatePath /path/to/clientcas
    SSLRequire ( %{SSL_CIPHER} !~ m/^(EXP|NULL)/ \
                 and %{SSL_CLIENT_S_DN_CN} in { "List", "of", "accepted" "names" } \
    }
</Location>

Soon we noticed that requests arriving less than about 1 minute apart would fail. The web client returned Could not create SSL/TLS secure channel.

The apache error logs showed:

[debug] ssl_engine_kernel.c(1893): OpenSSL: Write: SSLv3 read client hello B
[debug] ssl_engine_kernel.c(1912): OpenSSL: Exit: error in SSLv3 read client hello B
[error] [client 12.34.56.78] Re-negotiation handshake failed: Not accepted by client!?

The access log showed:

12.34.56.78 - - [11/Jan/2010:13:58:39 -0500] "POST /SecuredArea HTTP/1.1" 403 - "-" "Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol 2.0.50727.3603)"

Since the partner was connecting to several other sites without issues, they were not interested in troubleshooting their end. I don't know how their other peers are configured or even what they're running.

I tried all the workarounds for this apache bug, including upgrading a test server to Apache 2.2.

I was also seeing bad PUTs in the Inter-Process Session Cache caused by large session sizes. Changing SSLSessionCache from dbm to shmcb cleared those up, but did not resolve the actual issue.

Finally, I found two fixes:

1. Get rid of the SSL re-negotiation by moving SSLVerifyClient up to VirtualHost context. Since the rest of the resources under the VirtualHost aren't intended to be under client authentication, this means setting up a separate host for one resource.

2. Comment out BrowserMatch ".\*MSIE.\*" nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0 I'm concerned that removing this will have unintended consequences down the road.

The question is, which of these solutions is better? Or is there yet another one? If this site will never have living & breathing users, how risky is removing the BrowserMatch settings?