Forum Discussion
CirrusTwo URLs for same VIP and same pool for two different application ?
Hello All,
I have a query, I have two applications hosted on backend (real server) server, so can I use two URLs with same virtual server(VIP) and same pool for two different applications, the URLs are https only ?
Thanks
Hi,
No, you need a SAN cert.
You are doing Dev/internal which makes the answer easy.
get xca from here
It makes managing your own certs a joy.
Make your own CA cert, with a 10 year life. Then distribute that to your internal clients as a trusted root CA. Maybe push with group policy.
Then create a csr. Suppose you are using app1.int.local and app2.int.local.
Go to the SAN part and put in
*.local
*.int.local
because there is no reason to limit you to that. Don't mess around, * matches all.
Then sign the csr with your CA, give it a 10 year life.
Ensure its enabled for a TLS server.
Ensure it has an ocsp entry. set to DNS: ocsp.local. If its not there you get "This certificate has no revocation infomration" popups on the browser.
Voila! You can use that cert and its key for any of your .local and .int.local test sites.
Export the cert as pkcs11, give it a trivial password then import it to the bigip. That gets the cert and the key.
You just need the one client-ssl profile with that cert and key, for all test Vips. Pick out the name that was actually presented with SNI::name
For example, I use .root.xx and .local in my lab, with subdomains. My SAN wildcard certificate looks like this
DNS Name=root.xx
DNS Name=*.root.xx
DNS Name=*.sub1.root.xx
DNS Name=*.sub2.root.xx
DNS Name=*.local
DNS Name=*.ak.local
DNS Name=*.sea.local
Ensure your DNS has the correct A records then the users can connect to
Connects to the VIP, gets your cert which is valid for *.int.local.
The CA is loaded to the browser as a trusted root CA. so it gets a Green padlock.
Check SNI::name to get app1.int.local, then connect to the correct internal resource.
Hope that helps!
--John
8 Replies
computerliAltostratus
Hi Sulabh,
You can use two URLs with one F5 VIP and pool. Both applications can point to same F5 VIP. Just make sure that you have URLs included in the certificate SAN, as the requirement is HTTPS.
Also consider the following:
Profile settings like TCP , HTTP
Persistence
iRules , if required
Sulabh_SrivastaThanks dtn, the URLs are in DEV/Inernal environments and so F5 is using the default clientssl profile with self signed certficate. Will this self signed cert on my condition ?
dtn_25020Nimbostratus
Hi Sulabh,
You can use two URLs with one F5 VIP and pool. Both applications can point to same F5 VIP. Just make sure that you have URLs included in the certificate SAN, as the requirement is HTTPS.
Also consider the following:
Profile settings like TCP , HTTP
Persistence
iRules , if required
- Sulabh_Srivasta
Thanks dtn, the URLs are in DEV/Inernal environments and so F5 is using the default clientssl profile with self signed certficate. Will this self signed cert on my condition ?
Hi,
If you are using different fqdn pointing to the same HTTPS vip, then you can enable SNI by assigning multiple client-ssl profiles to the vip.
You must have a SAN certificate.
In an irule you can query what the orginating FQDN was.
https://devcentral.f5.com/wiki/iRules.SSL__sni.ashx
Then select a pool based on the name.
If you you have multiple apps behind 1 fqdn (HTTP or HTTPS) then you /might/ be able to select on part of the URI to choose a pool. Thats painful.
- Sulabh_Srivasta
Thanks John for your answer, the URLs are in DEV/Internal environments and so F5 is using the default clientssl profile with self signed certficate. Will this self signed cert work on my condition ?
Hi,
No, you need a SAN cert.
You are doing Dev/internal which makes the answer easy.
get xca from here
It makes managing your own certs a joy.
Make your own CA cert, with a 10 year life. Then distribute that to your internal clients as a trusted root CA. Maybe push with group policy.
Then create a csr. Suppose you are using app1.int.local and app2.int.local.
Go to the SAN part and put in
*.local
*.int.local
because there is no reason to limit you to that. Don't mess around, * matches all.
Then sign the csr with your CA, give it a 10 year life.
Ensure its enabled for a TLS server.
Ensure it has an ocsp entry. set to DNS: ocsp.local. If its not there you get "This certificate has no revocation infomration" popups on the browser.
Voila! You can use that cert and its key for any of your .local and .int.local test sites.
Export the cert as pkcs11, give it a trivial password then import it to the bigip. That gets the cert and the key.
You just need the one client-ssl profile with that cert and key, for all test Vips. Pick out the name that was actually presented with SNI::name
For example, I use .root.xx and .local in my lab, with subdomains. My SAN wildcard certificate looks like this
DNS Name=root.xx
DNS Name=*.root.xx
DNS Name=*.sub1.root.xx
DNS Name=*.sub2.root.xx
DNS Name=*.local
DNS Name=*.ak.local
DNS Name=*.sea.local
Ensure your DNS has the correct A records then the users can connect to
Connects to the VIP, gets your cert which is valid for *.int.local.
The CA is loaded to the browser as a trusted root CA. so it gets a Green padlock.
Check SNI::name to get app1.int.local, then connect to the correct internal resource.
Hope that helps!
--John
- Sulabh_Srivasta
John, thanks a lot.
