Forum Discussion
Kevin_Stewart
Nov 07, 2012Employee
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.