Forum Discussion
JD1
Altostratus
AltostratusIIS 7 - SSL Client certificate set to "Accept" seems to force F5 SSL TCP RST.
Hi all,
I've just upgraded an 11.3.0 HF5 to 11.6.0 HF4 BIG-IP.
We've got a couple of IIS7 servers behind, which (for no apparent reason) the server admins configured the SSL Settings to "Accept" on the client certification authentication.
Now, I understand the following to be true (similar to 'request' in Apache): "Accept will take a certificate if it's presented, but will also continue with connections where the client doesn't present one."
However, since the upgrade, the IIS7 servers are unhappy with the BIG-IP handshake and I'm seeing TCP RST in the ssldump from the IIS7 servers.
I'm intrigued what has changed between the two versions to suddenly cause this behavior.
Is there a serverssl profile setting which would allow this to continue happily?
I appreciate that if a backend server (whatever the HTTP daemon/server is) would need SSL Proxying if ever direct client-server authentication was required, but I'm pretty sure that the communication in this case should've continued normally being the SSL Client Cert from IIS7 wasn't set to Require.
Appreciate any and all input on this.
Regards,
J.D.
Brad_ParkerCirrus
It is very possible that the ciphers are no longer compatible. Could your server admins only be allowing SSLv3 and starting with 11.5 the"DEFAULT" cipher list doesn't include SSLv3?
https://support.f5.com/kb/en-us/solutions/public/13000/100/sol13156.html
- JD1I 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.
- Brad_ParkerWhere 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?
- JD1tcpdump (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)?
Brad_Parker_139Nacreous
It is very possible that the ciphers are no longer compatible. Could your server admins only be allowing SSLv3 and starting with 11.5 the"DEFAULT" cipher list doesn't include SSLv3?
https://support.f5.com/kb/en-us/solutions/public/13000/100/sol13156.html
- JD1I 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.
- Brad_Parker_139Where 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?
- JD1tcpdump (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)?