I have a https_vs that does not offload the SSL. I also have two pools https_pool and https_training_pool. I have to have iRules to inspect the https address for "portal.newco.com" to go to the https_pool and "training.newco.com" to go to the https_training_pool. I have looked for a week now and everything I read says that I have to set up Type:Standard, Protocol:TCP & HTTP Profile:http. Whenever I set these I can't get to my web servers. I can't implement the iRule w/o setting the HTTP Profile to http. When I remove the HTTP Profile and leave everything else, it works, but I then I can't use the iRule.

It's mandatory to offload SSL in BigIP to inspect the HTTP headers (Host, and others). There's no way around it. However, you can use serverssl profile in conjunction with clientssl to re-encrypt before the request gets forwarded to a pool member.

HTTP Profile breaking HTTPS

Hannes_Rapp_162
Nacreous
Oct 18, 2016
It's mandatory to offload SSL in BigIP to inspect the HTTP headers (Host, and others). There's no way around it. However, you can use serverssl profile in conjunction with clientssl to re-encrypt before the request gets forwarded to a pool member.
- Dan_W__274799
  Nimbostratus
  Oct 18, 2016
  When I set it with the serverssl and clientssl then I get a certificate error on the web page, and it doesn't seem to redirect my portal vs training pages. I receive a "Connection not secure" on the pages.
- Hannes_Rapp_162
  Nacreous
  Oct 18, 2016
  Clientssl profile is the device default. It points to a self-signed certificate which ofcourse is not trusted by Web Browsers. To get rid of the "connection not secure" warning, you will need to take the valid SSL certificate, Private Key and CA Intermediary certificate from your Web Server that currently does SSL offload, and install those on BigIP.
  
  After you have the ca-issued certificate files installed on BigIP, you will create a custom client-ssl profile which points to those valid files. And once you have the custom client-ssl profile, you update your Virtual Server configuration accordingly. The server-ssl profile may remain default.
Hannes_Rapp
Nimbostratus
Oct 18, 2016
It's mandatory to offload SSL in BigIP to inspect the HTTP headers (Host, and others). There's no way around it. However, you can use serverssl profile in conjunction with clientssl to re-encrypt before the request gets forwarded to a pool member.
- Dan_W__274799
  Nimbostratus
  Oct 18, 2016
  When I set it with the serverssl and clientssl then I get a certificate error on the web page, and it doesn't seem to redirect my portal vs training pages. I receive a "Connection not secure" on the pages.
- Hannes_Rapp
  Nimbostratus
  Oct 18, 2016
  Clientssl profile is the device default. It points to a self-signed certificate which ofcourse is not trusted by Web Browsers. To get rid of the "connection not secure" warning, you will need to take the valid SSL certificate, Private Key and CA Intermediary certificate from your Web Server that currently does SSL offload, and install those on BigIP.
  
  After you have the ca-issued certificate files installed on BigIP, you will create a custom client-ssl profile which points to those valid files. And once you have the custom client-ssl profile, you update your Virtual Server configuration accordingly. The server-ssl profile may remain default.
Vijay_E
Cirrus
Oct 18, 2016
You would have to set up SSL with HTTP profile. HTTP profile tends to check the contents of the packet and without SSL, it won't be able to inspect the contents of the encrypted packets.

In order to troubleshoot "Connection not secure", perform a curl to check and make sure that the domain that you are requesting and the certificate domain are the same.
VernonWells
Employee
Oct 18, 2016
To expand on this somewhat: with TLS traffic, if the BIG-IP is not "offloading" (decrypting on the client-side), it is impossible for the BIG-IP to inspect the traffic in a meaningful way (aside from some information exchanged in the TLS handshake). This is true not only for BIG-IP, but for any device. TLS is specifically designed to prevent a so-called "man-in-the-middle", and does so in part by encrypting traffic. It initiates the encryption in such a way that only the client and server can encrypt and decrypt the flow. When the BIG-IP is set up for offloading (via a clientssl profile), the BIG-IP becomes the "server" in the TLS conversation with the client, and thus, can encrypt and decrypt the flow. However, as part of the "man-in-the-middle" protection, TLS uses certificate based system authentication. That is, using a signed certificate, the server in a TLS exchange must provide its identity. The signature "proves" that the end-system really is what it claims to be. This is the reason you must install the validly signed certificate and private key from the real servers on the BIG-IP, and create a clientssl profile that points to these.

When you assign the http profile to a Virtual Server, it assumes the incoming traffic is HTTP. It uses protocol validation, and rejects traffic that is not valid HTTP. TLS traffic itself is not valid HTTP (even if it contains HTTP traffic), so without offloading, TLS traffic is dropped when the http profile is applied. On the other hand, if offloading is used (again, meaning a clientssl profile is also applied), the incoming traffic is first decrypted, and the traffic contained with the TLS stream is then processed by any other profiles.
Dan_W__274799
Nimbostratus
Oct 18, 2016
Thank you everyone. I was trying to keep from installing the Cert on the F5. It would have been fine using the Performance(HTTP) Type, but since I need to redirect based on URL, than I was banging my head making this work. You guys have it working for me now. Thanks, again, for the quick responses.

Dan