Forum Discussion

Febin_130295's avatar
Febin_130295
Icon for Nimbostratus rankNimbostratus
Jul 30, 2013

F5 SSL Offloading - Apache - Certificate Error

Hi

 

I am trying to offload SSL using F5 for my vendor application. SSL offloading is done based on wild card string *.abcd.local.

 

for e.g. original application url is

 

 

This is now redirected via F5 and the url gets changed to (SSL offloading is based on the wild card string *.abcd.local)

 

On invoking this url the apache web server responds back with ..... with all session cookies and parameters.

 

Since the response url does not contain the wild card string *.abcd.local, certificate error appears. How can we get around this at the F5 level using iRules, so that SSL offloading is enforced.

 

Regards

 

Febin

 

 

 

4 Replies

  • Since the response url does not contain the wild card string *.abcd.local, certificate error appears. How can we get around this at the F5 level using iRules, so that SSL offloading is enforced.where is https://originalsite.defg.local/loginpage? is it in http location header?

     

     

    if yes, is "rewrite redirects" http profile setting or "HTTP::header replace" irule command useful?

     

     

    Rewriting Redirects by Deb Allen

     

    https://devcentral.f5.com/tech-tips/articles/rewriting-redirects
  • First things first, redirect-rewrite is an option that rewrites "http://" to "https://" on 30x redirect responses from the server. This is useful when the application 1) doesn't know it's being accessed via SSL on the client side of a proxy, and 2) it issues absolute (vs. relative) paths in redirects. It does not touch payload URL references.

     

     

    Now, if I understand your situation, the application is issuing absolute references both in headers (redirects) and possibly payload data (page object references) of the value that it thinks it is (originalsite.defg.local). If that's true, then the solution is really dependent on the extent of the confusion. If it's just in the redirects, then a simple redirect-catching iRule will likely do the trick. But if there are references throughout the app that need to be changed on egress, then you may want to consider a ProxyPass option. ProxyPass is an iRule that simulates the mod_rewrite functionality of an Apache proxy, and is designed to rewrite URL references both inbound and outbound. The new 11.4 release has consumed that capability into a "rewrite profile" option as well.

     

     

    Ultimately, to avoid certificate mismatch errors you must rewrite all outbound references from *.defg.local to *.abcd.local.

     

     

  • Hi

     

     

    Thanks for your response

     

     

    Just to clarify my requirement, since I am totally new to this concept.

     

     

    Scenario

     

     

    I have an application which is directly accessed by https://ek5054.fgbmis.local/home. The server hostname is ek5074 with ip address 10.100.101.161

     

     

    On F5 I have configured a virtual IP for 10.100.101.161 as 10.100.101.162 and given an entry in dns as irec.fgbapps.local for the virtual IP.

     

     

    Now SSL offloading is done based on the wildcard character *.fgbapps.local

     

     

    When I try to access the application as https://irec.fgbapps.local/home, the IE throws up a Certificate error.

     

     

    As per my understanding, this is due to the server response is with an url as https://ek5054.fgbmis.local/msalsext/param?.........

     

     

    I can click on continue on the certificate error and the system works fine. I can even replace the ek5054.fgbmis.local on IE with irec.fgbapps.local along with the other parameters and click ok, the same page appears.

     

     

    Basically what I need to know is whether I can replace the ek5054.fgbmis.local on the server response url to irec.fgbapps.local so that F5 identifies it and doesnt throw up the certificate error.

     

     

    Regards

     

    Febin
  • The certificate error doesn't have anything to do with server response, at least not from a layer 7 (HTTP) perspective. When a client initiates an SSL session with a server, the server's immediate response (during the SSL negotiation and BEFORE any HTTP traffic) is a SERVERHELLO message. This is when it presents its certificate to the client. If that certificate 1) contains a subject name that is DIFFERENT than the name the client asked for, or 2) the client cannot establish a trust relationship based on its own explicit trust store, the user will see the certificate error message. So, if you have a clientssl profile assigned to the VIP, and that profile is using a certificate that has a subject of "irec.fgbapps.local", the client is asking for "https://irec.fgbapps.local", and the client can trust the issuer of that certificate, then another likely cause of the certificate error is some communication from the server that is redirecting the client to another host name. The best way to assess this is to capture the client (browser) side interaction with something like Fiddler.