serverssl-insecure-compatible for unsecure ports
Hi All, Is there an issue if we use serverssl-insecure-compatible for unsecure ports? Have a VIP with serverssl, pool members on 9093 port. Changed to serverssl-insecure-compatible and it works. Does serverssl works only on known ports? Thanks, Aditya
TLS Client Authentication from Server SSL Profile
Hi all We have a requirement to enable an outbound (internet) flow from some internal servers. Sitting near the edge of the network is an LTM that will proxy the connection from the servers, and is required to then do TLS mutual authentication (client authentication) to the target server on the internet. In this setup the LTM is, from the internal server's point of view, the server, so we configure a Client SSL Profile. All good. Next the LTM is, from the target server's point of view, a client so we configure a Server SSL Profile. Unfortunately this is not working for us. In the Server SSL profile we have set the Certificate and Key, which is the identity cert of the LTM itself signed by a 3rd party CA using a Web Server template with Client Authentication Key Usage. The logs from the target server (Apache 2.4.7) show the following: [ssl:info] [pid 5260:tid 2999946048] [client 10.128.2.109:58181] AH02008: SSL library error 1 in handshake (server server.com:443) [ssl:info] [pid 5260:tid 2999946048] SSL Library Error: error:140880AE:SSL routines:SSL3_GET_CERT_VERIFY:missing verify message My limited understanding on TLS MA is that the client should send a Certificate Verify message that proves it owns the private key. It appears the LTM is not sending this message which could explain why it is failing. I've tested a similar setup in my lab but bypassed the LTM and sure enough a Windows client does indeed send the Certificate Verify message and the transaction is successful. Any ideas on this one? Thank you.
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.
Enabling Server-side SSL in Production Environment
Looking for some guidance, best practices or a case study around a scenario I'm working with. I'm currently doing Client-Side TLS only. My primary use-case is an HTTPS Virtual Server (Client SSL only) with a policy for path based forwarding (currently have a couple hundred path based rules in my policy). I've now been tasked with enabling Server-Side TLS in my production environment. I do not have a requirement to support mTLS or x.509 (i.e. backend server does not need to know about the original client certificate). I'm wondering if anyone has made this migration before or has any tips for running in a "mixed mode" environment. I would like to provide my developers with the luxury of enabling TLS on their service on their own schedule. I've checked the Server Side SSL Profile docs and noticed the "Bypass on Handshake Alert" option .. I'm wondering if there's any further documentation for that feature.. seems like this is related only to the SSL Forward Proxy functionality, not sure it would help in my scenario? Ideally, I'd like to run my F5 Server SSL Profile in an "opportunistic" mode.. i.e. attempt to connect to the server using SSL, if the handshake fails, fall-back to an unencrypted connection to the server. Has anyone made this migration before? Any war stories you can share? Unfortunately, the documentation for Server SSL Profile's is great but I've found very little information about the migration path from "not-using a Server SSL profile at all" to "effectively using a Server SSL profile without causing negative impact on the journey". Thanks!Extracting SSL Certificate Issuer from Server Side Connection
Hello! I'm currently trying to build an iRule to extract the SSL Certificate Issuer from the Server Side Connection. All of the examples I have seen is based on the Client Side. To give you some background, there is currently a bug in BIG-IP SWG where it actually intercepts the SSL session when its specifically configured not to. We have mitigate the problem using an iRule but the problem still occurs, yet more uncommon. Capturing evidence of this is difficult but I figure we can at least create a log entry whenever the certificate is signed by the SWG, thus, we are intercepting the SSL session. When capturing the error using tcpdump, in Wireshark, I want specifically this information: You can clearly see here that *.fz.se is signed by my SWG. Having a log entry created for this would give us an indication of how often the problem occurs. Using iCall to trigger a tcpdump would be even better but I think at this point it will be too late to run a tcpdump.
serverssl behavior in 11.4.x
We ran into an issue that the SSL handshake on the serverside fails after updating the certificate on the server. Nothing changed on the LB. I'm aware of the serverssl profile behavior change in regards to the order of the TLS-versions, but as I mentioned the LB wasn't touched. Means it is already running v11.4.1 HF8 and everything was fine with the old certificate. After renewing it on the server, the server sends immediately a RST-packet after the client hello. After we disabled TLS1.2 with the "No TLS1.2" option in the serverssl profile (I assume using a cipher like this "DEFAULT:!TLSv1_2" would have the same effect) it was working again. So what kind of sense makes an order if the second or third option will never be used, when the first one fails? Maybe I'm totally wrong at the moment, but can someone explain me the behavior in detail or knows the root cause of this issue? Thank you! Ciao Stefan :)
Possibility of the Dynamic hostname in the SNI field?
Hello Guys, Can somebody please help me to know if I can have a dynamic host address in the serverssl profile with which I can enable the SNI on it. SO in short I have a requirement in which the hostname will be changing (****.example.com) all the time but it needs to be there in the SNI field. As far as I know, we can have a static entry in its filed so not sure if the dynamic can be placed in it or not. Really appreciate your time and help. Thanks and regards, R
Server SSL profile Server Authentication settings don't work?
im trying to configure the server ssl profile to accept certificates which it normally wouldn't to be able to provide better feedback to the users why the connection would fail. im aware of the risk. for this i set the Server Certificate on require and the Expire Certificate Response Control and Untrusted Certificate Response Control both on ignore. still the connection fails with these messages: Jun 22 13:09:04 bigip-01 debug tmm1[17068]: 01260006:7: Peer cert verify error: unable to verify the first certificate (depth 0; cert /edit) Jun 22 13:09:04 bigip-01 debug tmm1[17068]: 01260009:7: Connection error: ssl_shim_vfycerterr:4084: unable to verify the first certificate (48) i can also set Server Certificate to ignore and then all server certificates are accepted, only then i can't use [SSL::verify_result] to determine the status, it is always 0 (OK). anyone tried this and got some more insights on how to make it work.
Oneconnect behavior while updating server certificates
I imagine this sort of situation isn't THAT unique, so I'm hoping to maybe find some guidance haha. We have a VS that uses SSL-Bridging and Oneconnect. The server teams were renewing certificates on each of the pool members without a maintenance window (take 1 member down, update the cert, bring it back up and let it rejoin the pool). However, once the new certs were in place, users began reporting issues with connecting to the VS and the application. My understanding is that the certs were exactly the same, and they were only renewed on the pool members themselves (the client SSL cert wasn't changed, so the users shouldn't even be aware of the change). I could just be reaching at straws here, but my one thought is that maybe the available Oneconnect TCP connections for those members were still in-use. The servers weren't brought down long enough for the Max Age to expire the connections. I would imagine that if the F5 attempted to send encrypted traffic that the server didn't honor, it would tear down the connection and make a new one. However, I'm not finding any documentation that explains exactly how Oneconnect connections are torn down (other than the assumption of expiring via age, and I did see another DevCentral post talking about 404's will cause a Oneconnect connection to get torn down). The information in this KB article and its related articles (https://support.f5.com/csp/article/K7208) and other DevCentral searches didn't seem to point me in the right direction. Does anyone have a link or other information on how Oneconnect tears down or handles connections when the underlying SSL connection has changed?
