iRule to Decide which VS to use.

is it okay to receive certificate warning page when accessing?

 

 

just in case if you have not yet seen this information.

 

 

sol6823: Configuring multiple HTTPS sites on the same SSL client profile by creating a wildcard certificate request

 

http://support.f5.com/kb/en-us/solutions/public/6000/800/sol6823.html

 

 

sol13452: Configuring a virtual server to serve multiple HTTPS sites using TLS Server Name Indication (SNI) feature

 

http://support.f5.com/kb/en-us/solutions/public/13000/400/sol13452.html

 

 

hope this helps.

Hey guys thanks for the quick reply.

 

 

1. We cant use different ports as it's customer (end user) facing so has to be as standard as possible.

 

2. TLS v1.2 SN I've never seen before so i'll have to do some learning.

 

3. Problem is that it's not multiple sub domains it's multiple domains.

 

 

Regarding the "you can't read the URL until the SSL connection...." are you sure as i can create redirect rule based on URL in a HTTPS connection, if i can do this it's surly simple to say

 

 

Redirect to >> this VS

 

 

No/

 

 

matt

SNI, like wildcard and SAN certificates, allows you to have multiple SSL sites with the same IP (same VIP). SNI is somewhat different though because it's actually an extension to the TLS protocol that, when supported, allows the server to "switch" the server certificate it presents based on what the client is asking for. Essentially, in the client's SSL CLIENTHELLO message, the client would normally say "hello, I'd like to talk SSL, and these are the ciphers I support". With SNI, the client says, "hello, I'd like to talk SSL, and this is the hostname I'd like to talk to, and here are the ciphers I support". Most modern browsers now support SNI, though you should still consider what your client base may be. To enable SNI, create a separate client SSL profile for each hostname and enter that name into the Server Name block of the profile. Also select one of the profiles to be the default should the user access with an IP or not support SNI. Apply all of these client SSL profiles to the virtual server. SNI requires v11, but that's all it takes to configure.

 

 

As for selecting SSL profile via URL, that depends on if you mean hostname or URI. If by hostname then the above methods should work. If by URI, then your master VIP is potentially a good idea. You'd need two VIPs: the master VIP that clients should know and redirects based on that original URI path, and the application VIP that has the SNI (or wildcard/SAN) client SSL profiles. You cannot do URI-based load balancing until after you've negotiated the SSL session.

 

 

Thanks Kevin.

 

You could create an iRule to redirect, but you'll need to terminate the SSL session on the F5 first and you'll have to use a single SSL certificate (for a single FQDN/CN) to do that (unless SNI is a possibility). Presumably that won't be the certificate for the domain the user has entered in their browser. If your users can tolerate a certificate warning page (when they initially connect and before you redirect them) then that's fine but it seems unlikely.

 

3. Problem is that it's not multiple sub domains it's multiple domains. i understand SAN certificate supports multiple domain name.

 

 

Secure Multiple Domain Names with a Single SSL Certificate

 

http://www.symantec.com/theme.jsp?themeid=san-ssl-certificates

 

 

SAN (Subject Alternative Name) vs UCC (Unified Communications Certificate)

 

https://knowledge.verisign.com/support/ssl-certificates-support/index?page=content&id=SO13974&actp=search&viewlocale=en_US&searchid=1350903150640

Yes, SAN or wildcard certificates, albeit typically expensive, are a definite solution. They also don't require any specific browser support. Wildcard certificates provide, as the name implies, an single SSL certificate that covers all of a given domain (ex. *.mydomain.com). A subject alternative name certificate is similar, but allows a named set of hosts.

I know with SANS the client could if they view the Cert, see all the possible domains included in that certs. Unfortunally our requirement would not make this viable.

 

 

I guess the other idea is to have the SSL profile selected dynamically based on host

 

 

If host = blah.com

 

then use SSL_profile blah

 

else use SSL_profile blobby

You can't read the host name until AFTER you've terminated the SSL.

I think your best bet then is SNI. Take a look at this article for an idea on browser SNI support (http://en.wikipedia.org/wiki/Server_Name_Indication). The list includes IE7 and Firefox 2, so you'll likely be okay for 99% of users. As Steve says, you can't see any of the HTTP data (host, URI, etc.) until AFTER you've negotiated the SSL session.

You can't read the host name until AFTER you've terminated the SSL.

 

Just to be clear, this is not an F5 limitation. It's HTTP over SSL over TCP over IP.

 

 

I believe there is no solution to your problem.