IIS 7 - SSL Client certificate set to "Accept" seems to force F5 SSL TCP RST.

I had considered that, and tried adding SSLv3 back in already (for testing), however it would still beg the question "Why only when the server side is configured to accept/request client certificate?". Additionally, ssldump shows that the server side responds with a matching cipher available.

Where does the SSL failure happen. Use tcpdump to gather the handshake failure. Which side is terminating the handshake? Do you have a certificate configured in your SSL server profile?

tcpdump (ssldump more so) shows TCP RST from server side. Not a client certificate in server ssl, AFAIK the section for that becomes server authentication certificates (to certify the server is who they say, not to certify the F5 BIGIP is who it says)?

If you configure a certificate in the certificate section of the server ssl profile, it presents that certificate the the server as a client certificate. If you could post the client hello and server hello packet details we may be able to see what is going on.

Hi Brad. I don't see a 'client section' the equivalent in the serverssl profile, it seems to show Server Authentication. Unless this is exactly the same function from BigIP perspective. Still, why would I now need to configure a client certificate between bigip and IIS if IIS is set to accept not require and it worked back on 11.3 HF 5? Only thing changed is BigIP version, ciphers quite clearly are supportive of the deprecated sslv3 removal. I'll get the client hello etc asap and post.