SSL Handshake failed for TCP - Android Application Request

Hi Sean,

Do you have this iRule applied to both an HTTP and an HTTPS VIP?

Do you have a client SSL profile added to the HTTPS VIP? If so, is the cert in the profile for domain1.com or www.domain1.com?

What is the SSL error?

Do you see any run time TCL errors in /var/log/ltm when you get the page cannot be displayed error?

You could combine the switch cases into one (though this won't change the effect of the iRule). You could also append the originally requested URI to the query string on the redirect:

when HTTP_REQUEST {
   switch [string tolower [HTTP::host]] {
      "domain1.com" -
      "www.domain1.com" {
         HTTP::redirect "https://domain1.domain2.com[HTTP::uri]"
      }
   }
}

Aaron

I did apply iRule to HTTP and HTTPS VIP after troubleshooting, but that made no difference.

 

 

Yes, client SSL profile is being used on HTTPS VIP, the cert is for domain2.com, since that is what I am trying to forward to, and the existing domain traffic (on the VIP we will be pointing to) is using this profile (it is a wildcard for domain2.com).

 

 

SSL error is simple 'untrusted connection' since the url domain's are different.

 

 

There aren't any entries in the ltm for my 'test' VIP or Pool.

 

 

I like the combination iRule you showed... I also need to keep in mind that the original traffic going to blah.domain2.com is still going through this connection and my existing iRule for HTTP -> HTTPS and adding a uri has to work as well for each of these requests...

 

If blah.domain2.com and another hostname like domain1.com or www.domain1.com are resolving to the same VIP, then clients will get a mismatched cert warning on HTTPS requests when trying to access a hostname that the cert isn't issued for. You would want to have a cert installed which matches the hostname(s) that the client is making the request to--not the domain that you're redirecting the clients to.

 

 

You could either get a single cert which is valid for all the domains (using subject alternate names and/or a wildcard cert) or change the name resolution to point to separate IP addresses.

 

 

Aaron

I think I just found my error... I had inadvertently set the SSL client and SSL server profiles to my HTTP VIP... That was causing the block or dropped requests...

 

 

I'm still seeing issue with requests going to https://domain1.com which makes sense... I'm guessing I will need another iRule applied to my HTTPS VIP to forward just like the HTTP one.

 

 

Thanks again!

That sounds about right. Forwarding to a second VIP won't help with trying to handle multiple certs on a single client facing IP address:port combination as you'd need to try to decrypt the SSL on the first VIP before knowing which traffic to forward to the second VIP. Sending the "wrong" cert on the first VIP to the client will trigger the mismatched cert warning on the browser before you can send the request to the second VIP with the "correct" cert.

 

 

Aaron