Jump to content
Welcome to our new Citrix community!

SSL/TLS connection to backend server in a service group


Chris Craddock

Recommended Posts

Community,

I was curious about how the Netscaler works in terms of encrypting connections between itself and the backend servers in a service group. Lets say we have the following:

 

-SSL type Virtual Server on port 443 with SSL Cert applied

-SSL Type service group, with two servers listening on port 443

 

My understanding initially was that when the client connects to the VS, the SSL handshake between the client and the VS is terminated at the VS (SSL offloading), and then the VS forwards the traffic to the backend servers on port 443 unencrypted. However, I am recently learning that this may not be the case. In this setup, is a second encrypted SSL connection made between the Netscaler (SNIP?) and the backend server? If so, how does this connection work? Does it use the cert that is applied to the VS to make the connection?

 

The reason I ask is because I am facing a problem where when we run traffic through one of our API services that is in a GSLB, the remote end gets a bunch of Java Exceptions related to SSL, but when we run the traffic through our other Site (which seems to be configured identically from a Netscaler perspective), the Java Exceptions go away. I attached the Java Exception for reference. I cant figure out why when traffic is sent to the one Site, they get the exceptions but at the other Site, they do not. The same cert is applied at both sites. 


 

Thank you for any insights you can provide. 

Java Exception Example.txt

Link to comment
Share on other sites

Just some info on the lb/cert questions you asked. 

9 hours ago, Chris Craddock said:

My understanding initially was that when the client connects to the VS, the SSL handshake between the client and the VS is terminated at the VS (SSL offloading), and then the VS forwards the traffic to the backend servers on port 443 unencrypted.

Yes - this understanding is incorrect.  If your service is defined as type SSL:443, then the backend traffic is encrypted and will source from snip to destination. See additional notes below:

 

Regarding SSL and LB:
1) for SSL traffic types for the vserver, the ADC does do SSL termination, which means the client side connection connects to the vserver as SSL; and the ADC decrypts and looks inside.  What happens on the backend depends on if the service destination is also SSL or HTTP.  If the backend service is SSL, then the ADC acts as the "client" on the backend transaction and connects over SSL to the SSL server. This backend traffic is encrypted according to the backend destination.  If your backend destination is HTTP, then the backend traffic is unencrypted.

 

2) For ssl bridge traffic traffic is not decrypted on the ADC and what is received encrypted from the client, stays encrypted, and is then forward to the service destination to be decrypted.

 

Another explanation:

When you configure an lB vserver of type SSL going to services of type SSL, you are configuring end-to-end encryption where the ADC terminates the client-side transaction, decrypts and looks inside to allow LB and other features to be applied (like optimization and security features).  When the load balancing destination is selected, aka the service, if this is also SSL based, then the traffic will be re-encrypted to transmit to the actual server destination.

 

For SSL offload (frontend ssl only), you would have lb vserver of type SSL and backend service destinations on HTTP:80.

 

For your other questions:

9 hours ago, Chris Craddock said:

In this setup, is a second encrypted SSL connection made between the Netscaler (SNIP?) and the backend server? If so, how does this connection work? Does it use the cert that is applied to the VS to make the connection?

 

Basically the lb vserver is the client-side connection point and acts as the "server/fulfilling entity" for the client side request.  The SSL cert on the lb vserver matches the FQDN of the client side connection to the lb vserver, should be issued by a CA trusted by the client, and will be the cert used to terminate/decrypt the client side transaction arriving at the ADC.

 

For the service side of the transaction, the ADC is actually the "client/requesting entity" establishing a connection to the actual backend destination. In this case, the actual server (not the ADC) has the appropriate cert installed on it, issued usually by a domain or other internal CA.  ADC by default does not require a root cert to be trusted for this backend connection. You do not need certs on the "service" on the ADC; the actual cert used for the backend ssl connection is the on the actual server you are connecting to.  Traffic will egress the ADC from a SNIP to the backend destination (in most cases).

 

 

 

 

  • Like 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...