I'm kind of confused about how to handle encryption certificates with a load balancer in place. I'm using the setupssl.sh script to create our certs and insert them into the LDAP instances - and this uses each LDAP servers hostname.
Our current configuration is that ldap requests go to a GTM, which directs the request to its closest data center load balancers. We have identical certs on each load balancer, and encrypt from the client to the load balancer, then plain text inside the data center from load balancer to ldap servers. We want to make the entire path encrypted so the load balancers would just act as pass throughs. But what I'm not quite clear on is how we would direct the requests - can we continue to use our GTM url or do we somehow need to tell the clients which servers they are connecting to? In my testing I've appended the certs from my test LDAPs to the F5 cert that I have on my test clients and I can authenticate making a direct connection to any of the test LDAPs, but I am putting in a server name. No test load balancers to test this out on so I have no idea what will happen when I actually try to go through the load balancers.
Do the certs have to have the server hostnames in them or can I create a cert that has a virtual name and put that on all the LDAP servers?
EJ
On 5/12/2014 9:53 AM, Elizabeth Jones wrote:
Do the certs have to have the server hostnames in them or can I create a cert that has a virtual name and put that on all the LDAP servers?
If I understand the scenario : you are using a LB that passes through SSL traffic to the LDAP servers without terminating the SSL sessions (packets come in from clients, and are sent to the LDAP server of choice untouched by the LB). In that case you can deploy a cert on all the LDAP servers with the virtual hostname the client use to make their connections to the LB. The clients will validate the cert presented because its hostname matches the one they used to make the connection.
However, note that any LDAP client that needs to make a connection to a specific server (bypassing the LB) will now see the "wrong" hostname and hence fail the certificate host name check. (e.g. replication traffic from other servers).
A wild card host name may be a good solution in this case.
There may be a way to get the LDAP server to present different certificates depending on the source IP (hence avoiding the need for a wildcard cert), but I don't remember such a feature existing off the top of my head.
On 05/12/2014 06:08 PM, David Boreham wrote:
On 5/12/2014 9:53 AM, Elizabeth Jones wrote:
Do the certs have to have the server hostnames in them or can I create a cert that has a virtual name and put that on all the LDAP servers?
if the GTM there's a two way SSL connection handling which doesn't have anything to-do with the hosts serving the requests. The GTM address certificate is the one which is visible to your clients otherwise you would need to know within your application which host name you are going to connect to ... obsoletes Load balancing a little bit ;)
the complete path gets encrypted by enabled SSL from the GTM to the back end systems where you need to either deploy a client certificate for authentication (if necessary) or simply just encrypt the traffic (considerable if you can ensure that there's no possibility for others to spoof the back end system in a kind of man-in-the middle szenario.
the point you want to look at is in your GTM -> profiles -> SSL -> client & server where server is the one you customers are connecting to and client is the backend communication ...
regards mIke
If I understand the scenario : you are using a LB that passes through SSL traffic to the LDAP servers without terminating the SSL sessions (packets come in from clients, and are sent to the LDAP server of choice untouched by the LB). In that case you can deploy a cert on all the LDAP servers with the virtual hostname the client use to make their connections to the LB. The clients will validate the cert presented because its hostname matches the one they used to make the connection.
However, note that any LDAP client that needs to make a connection to a specific server (bypassing the LB) will now see the "wrong" hostname and hence fail the certificate host name check. (e.g. replication traffic from other servers).
A wild card host name may be a good solution in this case.
There may be a way to get the LDAP server to present different certificates depending on the source IP (hence avoiding the need for a wildcard cert), but I don't remember such a feature existing off the top of my head.
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
no need for wildcard certs… use the Subject Alt Name. Works fine. Been doing it for years. certutil supports it as well.
/mrg
On May 12, 2014, at 12:08 PM, David Boreham david_list@boreham.org wrote:
On 5/12/2014 9:53 AM, Elizabeth Jones wrote:
Do the certs have to have the server hostnames in them or can I create a cert that has a virtual name and put that on all the LDAP servers?
If I understand the scenario : you are using a LB that passes through SSL traffic to the LDAP servers without terminating the SSL sessions (packets come in from clients, and are sent to the LDAP server of choice untouched by the LB). In that case you can deploy a cert on all the LDAP servers with the virtual hostname the client use to make their connections to the LB. The clients will validate the cert presented because its hostname matches the one they used to make the connection.
However, note that any LDAP client that needs to make a connection to a specific server (bypassing the LB) will now see the "wrong" hostname and hence fail the certificate host name check. (e.g. replication traffic from other servers).
A wild card host name may be a good solution in this case.
There may be a way to get the LDAP server to present different certificates depending on the source IP (hence avoiding the need for a wildcard cert), but I don't remember such a feature existing off the top of my head.
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
no need for wildcard certs⦠use the Subject Alt Name. Works fine. Been doing it for years. certutil supports it as well.
/mrg
Thanks, this looks like it is what I need. I do have a question about this though - we have a single url that we use that is on our GTM - the GTM routes the request based on the IP address of the incoming request to a specific data center. We have a single VIP IP address at each data center. Should I include the base url and the VIP IP addresses for both data centers, or just the base url that we are sending our requests to?
thanks,
EJ
On 5/13/2014 10:12 AM, Elizabeth Jones wrote:
no need for wildcard certs⦠use the Subject Alt Name. Works fine. Been doing it for years. certutil supports it as well.
/mrg
Thanks, this looks like it is what I need. I do have a question about this though - we have a single url that we use that is on our GTM - the GTM routes the request based on the IP address of the incoming request to a specific data center. We have a single VIP IP address at each data center. Should I include the base url and the VIP IP addresses for both data centers, or just the base url that we are sending our requests to?
Typically certificate validation is done on the DNS host name not IP address (although IP-based validation is possible).
Think of it like this : the client initiating the connection uses some host name. It needs to see a server cert that includes that same host name in order to declare the cert valid. Repeat this same thought process for all clients connecting to all your servers (including any clients that are not using the LB).
389-users@lists.fedoraproject.org
-
David Boreham -
Elizabeth Jones -
Michael Gettes -
Michael Lang