Forum Discussion
HTTPS/HTTP rewrite URL (Wildcard SSL cert)
Hi guys,
I am pretty new to the forum and iRules...
Here's the issue I am having right now.
We are using a Wildcard SSL cert for one of our HTTPS URL (Lets call it https://*.abc.mydomain.com)
My CTO has requested us to implement a redirect rule for this URL. So when our customers try to access
"https://abc.mydomain.com", they will be redirecting to "https://www.abc.mydomain.com".
I used CNAME on the DNS server so whenever people are accessing "https://abc.mydomain.com" will be redirecting to the same web page as "https://www.abc.mydomain.com".
However, the redirecting does not udpate the URL on the browser to the "Redirected" URL...
Therefore, when you go to the URL, you will always get a SSL cert error message. (Since the original URL https://abc.mydomain.com does not match our wildcard ssl cert)
Is there anything I can configure on the BIG-IP to achieve this?
Any help will be great...
Jon
5 Replies
- hoolio
Cirrostratus
Hi Jon,
To avoid the cert mismatch error you'd need to have a certificate that's valid for abc.mydomain.comn and www.abc.mydomain.com. Your iRule would then work without the browser receiving a warning.
Aaron - hoolio
Cirrostratus
Another option would be to point one of the domains to a separate IP address with a validcert for that FQDN.
Aaron - JMA_46115
Nimbostratus
Hi Aaron,
I will give it a shot for the first solution. Making another cert and virtual server for abc.mydomain.com.
Thank you for helping me out.
Jon - Kamalpreet_1068
Nimbostratus
Hi Jon,
Lets do like this
1. Do the DNS entry for abc.mydomain.com & www.abc.mydomain.com to point to say "1.1.1.1"
2. Create 2 VIP on LB of IP - 1.1.1.1 listening on port 80 & https
3. On VIP apply rule
when HTTP_REQUEST {
if { [HTTP::uri] == "/" } {
HTTP::redirect "https://www.abc.mydomain.com"
}
}
All the traffic will be redirected to www.abc.mydomain.com and you can use that wildcard cert
Kamal - hoolio
Cirrostratus
The problem with using a single IP address for multiple fully qualified domain names is that LTM needs to complete an SSL handshake with a single SSL cert before being able to decrypt the SSL and inspect or modify the HTTP to determine which FQDN the client requested. If LTM presents a cert which doesn't have the client's requested FQDN, the client will generate a mismatched cert error.
If the clients are in a controlled set (ie, all owned by one organization) you could potentially use TLS SNI to determine which cert to present:
http://en.wikipedia.org/wiki/Server_Name_Indication
The reason TLS SNI hasn't taken hold fully yet is that many older browsers and operating systems don't support it yet:
http://en.wikipedia.org/wiki/Server_Name_IndicationNo_support
If you can get a single certificate which is valid for all of the FQDNs clients would use to access the virtual server, you can avoid this issue. Typically, this is done with wildcard or Subject Alternate Nate (SAN) certs.
If a SAN or wildcard cert can't be used and the clients are not corporate owned, you'll generally need one virtual server IP address per SSL certificate.
Aaron
Help guide the future of your DevCentral Community!
What tools do you use to collaborate? (1min - anonymous)Recent Discussions
Related Content
* 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