Client SSL Profile set to Require Client Certificate breaks RDP in APM
Hello, I have a policy set up in the BIG-IP F5 VE 15.1.10.5 APM to allow access to a handful of Remote Desktop (RDP) links. I'm attempting to set the authentication to require Common Access Card (CAC) Certificate login. In my access policy visual editor, I have a Client Cert Inspection branch that leads into OCSP Authentication and then if successful assigns the RDP resources through LDAP.This all works perfectly fine as long as the Client SSL profile connected to the access policy has Client Authentication > Client Certificate set to "Request" or "Require." If set properly, when a user attempts to connect to the webtop URL they are prompted for their certificate, authorized against the OCSP, and given access to the resources as corresponds to LDAP group. However when attempting to use one of the Remote Desktop Links it'll download the RDPconnection as intended and fail to connect with "There was a problem connecting to the remote resource. Ask your network administrator for help." I know this is because of the Client SSL profile because if i change it back to "Ignore" and have the user click the Remote Desktop link, it downloads and connects to the specified resource with no issue. The server the RDP connects to is configured with a client certificate that is trusted by the Root and Intermediate CA in the "Trusted Certificate Authorities" under the Client SSL Client Authentication profile. I was originally able to get around this by, instead of using Client Cert Inspection in my access policy, using On-Demand Cert Auth and leaving the Client SSL profile to "Ignore" client certificate. This allowed the user to be prompted and authenticated when originally accessing the webtop and utilize the RDP resources assigned. Unfortunately, On-Demand Cert Auth recently broke and users are not being prompted for their certificate and as such cannot connect to the webtop without the Client SSL profile being set to "Request" or "Require" to force the certificate prompt. https://my.f5.com/manage/s/article/K63123740 I've read the above KB where it says "the RDP client doesn't like the certificate request." but I'm not sure why, RDP should support certificate requests, users authenticate with token certificates all the time when RDP'ing to resources unless I'm misunderstanding what is happening? With that article I thought maybe the Server SSL profile would be an issue, but only changing the Client SSL profile certificate settings affects login. Any help would be appreciated, thanks!
Oracle Weblogic with F5 issue,Jsession your session has expired
What can be done to resolve an issue on an oracle weblogic VIP which offloads SSL, The page loads and a "YOUR SESSION HAS EXPIRED" message is popped out,and the page redirects back to login page. When the backend servers are called directly, no such error is encountered. I already deployed an iapp for this,and it didn't solve the issue.
iRule and SSL Cipher Blocking URL Access
Hello, We want to disable TLSv1.0 via the SSL profile on our VIPs. I have a new SSL profile that does that with the below format. DEFAULT:!SSLv3:!RC4:!TLSv1 We ALSO want to direct any TLSv1.0 traffic to our own HTML page. I've created an iRule for that, shown below. when HTTP_REQUEST { if { [SSL::cipher version] eq "TLSv1" } { HTTP::respond 200 content [ifile get "/Common/NoTLSv10_iFile"] noserver "Content-Type" "text/html" "Cache-Control" "no-cache, must-revalidate" "Connection" "Close" } else { log local0. "SSL Protocol version [SSL::cipher version]" } } I validated that the iRule works as expected when applied to the HTTPS VIP and testing with IE with only TLSv1.0 enabled. HOWEVER, my testing today WITH the new SSL profile is not getting the same results. Testing with IE with only TLSv1.0 enabled routes traffic to an internet search, not to our html page. I have the iRule applied to our HTTPS VIP. We have both HTTP and HTTPS for each VIP but there is a HTTP to HTTPS redirect iRule applied to the HTTP VIPs. I'm trying various iterations of ordering the two iRules on the HTTP VIP but not having any success. The end goal is twofold: block TLSv1.0 traffic send any TLSv1.0 traffic to our HTML page There's clearly something conflicting but I'm not able to determine how to resolve. I appreciate any assistance that can be provided. Diane
RDP connection via application access fails when client certificate is set to require
I've set up a VIP with a client SSL profile that requires a certificate. The access policy on this VIP has some resource assignments: network access, rdp application access and rdp via app tunnel access. All of these resources work just fine, except the rdp application access. The connection is not established and the handshake gives this failure: TLSv1.2 Record Layer: Handshake Protocol: Multiple Handshake Messages Content Type: Handshake (22) Version: TLS 1.2 (0x0303) Length: 269 Handshake Protocol: Certificate Handshake Type: Certificate (11) Length: 3 Certificates Length: 0 Handshake Protocol: Client Key Exchange However, another resource works just fine: TLSv1.2 Record Layer: Handshake Protocol: Multiple Handshake Messages Content Type: Handshake (22) Version: TLS 1.2 (0x0303) Length: 269 Handshake Protocol: Certificate Handshake Type: Certificate (11) Length: 3 Certificates Length: 2647 Handshake Protocol: Client Key Exchange In the first capture, the certificate length is 0. In the second one it is 2647. Now, I've set the client SSL profile to 'request' and all resources work just fine. Can someone shed some light on this issue? Why does it fail when set to 'require'?
How to enable SNI on Big-IP Version 11.5.3 (Build 1.16.167)
I have a VIP where I'm trying to apply two client ssl profiles, intending to use SNI. The problem is, when I apply the second profile, it says: 0107149c:3: Virtual server /ESAI/lb-drupal-tuftsmagazine.tufts.edu-443 has more than one clientssl/serverssl profile but none of them is default for SNI. By searching these forums, (in particular this page it seems I need to add Server Name to the client ssl profile, but that field isn't present on my system. On the ssl client profile page, there is no "Server Name" field, no mention of SNI anywhere on the page. Is this a licensed feature, or something I don't have? Has the control been relocated in my version of Big-IP? Or something? Thanks...
Sync failed: ClientSSL profile (/Common/clientssl) cannot get its defaults from ()
After some config changes (also in clientssl), I want to sync, but it looks like it does not work: Sync Failed A validation error occurred while syncing to a remote device Sync error on DCLB01: Load failed from /Common/DCLB02 01071a12:3: ClientSSL profile (/Common/clientssl) cannot get its defaults from (), as it doesn't exist. Recommended action: Review the error message and determine corrective action on the device I've tried to revert all changes in clientssl profile, but it does not work. I've tried to overwrite the config, by the second device in HA group, but id doesn't work either. Any help much appreciated.
LTM :: SSL Client Authentication :: Lock Out
Has anybody implemented any controls on their LTMs that prohibits a source from repeatedly authenticating to a virtual server that requires SSL client authentication? Granted... the ability to brute-force a 2048 bit key signed with sha256 from an internal/protected PKI is going to be rather... umm... difficult. However I don't want to give any prospects of a snow ball's slight chance in Mojave to induce any sort of undesirable condition (DoS, failure of authentication logic, unknown bugs... whatever it is). I want to slow that process down so it can either be detected earlier or prevented as a whole - of course. Plus, I'm an overly paranoid soul who simply rather not provide the ability for random sources to pound on the door at-will. That being said... anybody share that concern? Has anybody done anything to put controls in place to limit failed SSL client authentication? In my scenario, nobody should be touching the VS unless they have an approved mobile device that is part of our MDM with a certificate acquired by our PKI (SCEP). In light of that, I have zero regard for the gracefulness of client rejection. There might be something built-in to accommodate this scenario... but I'm not aware of it. I was initially thinking iRule, so I just dove right into it. I'm no programmer... but I'm thinking something along these lines (warning: this code has not been tested!). Would love any constructive feedback on any of the above or below! Thanks 🐵 when RULE_INIT { set static::ip_lockout_attempts 3 set static::ip_lockout_xtimeout 900 } when CLIENT_ACCEPTED { set client_ip [IP::client_addr] set hsl [HSL::open -proto UDP -pool syslog.pool] set bad_cert_count [table lookup -notouch $client_ip] if { $bad_cert_count == {} } { table add $client_ip 0 $static::ip_lockout_xtimeout } elseif { $bad_cert_count < $static::ip_lockout_attempts } { table lookup $client_ip } else { reject set time_remaining [expr { [table timeout -remaining $client_ip] / 60 }] HSL::send $hsl ":: SSL_REJECT :: Source IP $client_ip has been locked out. Time remaining: $time_remaining minutes." } } when CLIENTSSL_CLIENTCERT { if { [SSL::cert count] > 0 } { set cert_result [X509::verify_cert_error_string [SSL::verify_result]] if { $cert_result eq "ok" } { table delete $client_ip } else { table incr $client_ip HSL::send $hsl ":: SSL_REJECT :: Client certificate from $client_ip rejected." } } else { table incr $client_ip HSL::send $hsl ":: SSL_REJECT :: Client certificate from $client_ip not supplied to virtual server." } } Theory and base code borrowed from Jason Rahm and Stephanie via DevCentral.
SSL client profile - certificate authentication - multiple CRL files
Hi guys, currently I'm running a tests with certificate-based user authentication, using LTM/APM. In general everything is working fine, except for the fact, that there is no option to check several CRL files in one SSL client profile. As there are multiple CAs, that have issued client certificates, I need to check several CRL files. The documentation is not very specific about this piece of information. There are only statements, that it is not allowed to have multiple CRLs in a single master file. I have tried to use CRLDP, but this does only work in conjunction with LDAP. I can only provide the CRLs via file upload to BIG-IP or via HTTP downloads from an internal server. The only idea I have so far, but which is still not tested, is to use several SSL client profiles, one for each Trusted CA, assign the correct CRL file, stored locally on the BIG-IP, and the assign the SSL client profiles dynamically, based on the requested hostname in the SNI extension. To be honest, I cannot believe that there is no easier way to achieve this. Any ideas on that? Thanks in advance. Greets, svs