Forum Discussion
Joe_Pipitone
Nimbostratus
Nov 07, 2012Rewrite/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 authentic...
Kevin_Stewart
Employee
Nov 07, 2012In 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.
Help guide the future of your DevCentral Community!
What tools do you use to collaborate? (1min - anonymous)Recent Discussions
Related Content
DevCentral Quicklinks
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com
Discover DevCentral Connects
