Forum Discussion

JD1's avatar
JD1
Icon for Altostratus rankAltostratus
Mar 05, 2015

IIS 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.

 

12 Replies

    • JD1's avatar
      JD1
      Icon for Altostratus rankAltostratus
      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.
    • Brad_Parker's avatar
      Brad_Parker
      Icon for Cirrus rankCirrus
      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?
    • JD1's avatar
      JD1
      Icon for Altostratus rankAltostratus
      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)?
    • JD1's avatar
      JD1
      Icon for Altostratus rankAltostratus
      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.
    • Brad_Parker_139's avatar
      Brad_Parker_139
      Icon for Nacreous rankNacreous
      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?
    • JD1's avatar
      JD1
      Icon for Altostratus rankAltostratus
      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)?