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" } \

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] Re-negotiation handshake failed: Not accepted by client!?

The access log showed: - - [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?

1 Answer 1


1.) is recommended because of this, so #1 is a good idea anyway.

  • Yes, I've seen that, but I thought that a fixed openssl was coming soon. After reading openssl.org/news/secadv_20091111.txt & openssl.org/news/state.html again I'm not so sure.
    – pra
    Jan 12, 2010 at 5:50
  • 1
    The "fix" that is currently available is to disable renegotiation completely. There is a draft RFC that proposes a fix to SSL itself; I understand that recent snapshots of openssl implement this draft RFC. But both the client and server need to implement this fix, and you only control the server side, so I agree it will be awhile before it's out there. option #1 seems to solve all your problems. Jan 13, 2010 at 2:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.