Forum Discussion

Joe_Pipitone's avatar
Joe_Pipitone
Icon for Nimbostratus rankNimbostratus
Nov 07, 2012

Rewrite/redirect before SSL handshake

We have an interesting scenario that would all go away if we could just get rid of this old legacy system, but for now it's here to stay.

 

We have an application that is using IIS basic authentication to log users in (please, don't ask)

 

I have implemented SSL and have a certificate in place. The certificate is for subdomain.newdomain.com.

 

This is what happens:

 

User goes to:

 

http://subdomain.olddomain.com/somepage.asp

 

 

this gets rewritten to:

 

https://subdomain.newdomain.com/somepage.asp

 

 

If the user goes to:

 

https://subdomain.olddomain.com/somepage.asp

 

 

They get a certificate mis-match error, becuase my rewrite/redirect iRule does not take precendence over the SSL hand-shake. We also have IIS basic authentication trying to re-authenticate the user because it's a different domain.

 

I'm curious to know - is there a way to force the rewrite before the SSL handshake?

 

If not, people are just going to have to live with it and use the correct URL. Thank you for any insight you may have.

 

6 Replies

  • In a word, no - for two reasons:

     

     

    1. The DNS name is tied to the subject name in the certificate (that's why the certificate mismatch error)

     

    2. SSL happens BEFORE HTTP, but after TCP. You don't have access to the hostname until the data has been decrypted.

     

     

    You have at least 2 options:

     

     

    1. A SAN certificate in the client SSL profile. A SAN certificate would contain multiple subjectAlternativeName attributes. You can't use a wildcard certificate here because you'd need it to cover *.com.

     

     

    2. Server Name Indicator. Available in v11, SNI takes advantage of a relatively new TLS extension allowing the client to specify in the initial CLIENTHELLO message what the requested hostname is, allowing the BIG-IP to "switch" SSL profiles. You'd create at least two client SSL profiles, one for subdomain.olddomain.com and one for subdomain.newdomain.com, and enter these names into the respective server name blocks. Then apply both client SSL profiles to the virtual server. Make sure to assign one as the "default" - probably subdomain.mydomain.com - for any client that doesn't support SNI. So a client would access https://subdomain.olddomain.com, complete the SSL negotiation, then get redirected (via iRule or HTTP Class) to https://subdomain.newdomain.com where they'd initiate a completely new SSL connection.

     

  • OK - I appreciate your feedback this is all great info. I suppose I will think positive and this will be a kick in the rear to get rid of this legacy app once and for all.

     

     

    once again, thank you.
  • Hello,

     

     

    did you found a solution ?

     

    we have the same issue to redirect HTTPS to HTTP for a certain domain xxx.com

     

    regards from Switzerland
  • Hello,

     

     

    did you found a solution ?

     

    we have the same issue to redirect HTTPS to HTTP for a certain domain xxx.com

     

    regards from Switzerland
  • Hello,

     

     

    did you found a solution ?

     

    we have the same issue to redirect HTTPS to HTTP for a certain domain xxx.com

     

    regards from Switzerland