Jump to content
Welcome to our new Citrix community!

SSL offload and internal CA cert requirements

Recommended Posts


Thanks for your answers. I just need to review which certs are required at this stage, rather than how to implement it.

So for this example scenario, assuming we also enable server authentication on the backend on Netscaler:


vserver web.name.int

SSL load balancing with offload two servers:




We need which certs from internal CA ?

1) cert for web.name.int installed on netscaler

2) cert for web1.name.int installed on server

3) cert for web2.name.int installed on server


Do we also need the individual backend server certs installed on the netscaler as well ?

Any caveats with using backend authentication ?

Thanks again.

Link to comment
Share on other sites


Hi asoilem42 ,


As I said before there is no special requirement.


You need need a valid SSL certificate and the corresponding private and public key pair.  You also install an intermediate certificate that establishes the credibility of your SSL Certificate by tying it to your CA’s root certificate. 


Once you receive the SSL certificate, you can install the same certificate  on your servers  and the NetScaler  


Do we also need the individual backend server certs installed on the netscaler as well ? No same SSL certificate on backed and NetScaler

Any caveats with using backend authentication ? No I don't think so.





Link to comment
Share on other sites

If you think of the flow as:

client --> NS LB/CS/VPN vserver --> NS service --> backend server


For the client to vserver communication, you require a server certificate issued to the FQDN of the LB/CS/VPN vserver that user's use to connect to the NS entity.

It should be issued by a trusted CA.  If necessary, you also import intermediate CA/root CA certs onto the NS to build a certificate chain if needed.

- If the majority of your users connecting to the vserver are external or devices you don't control, then request server certs from a public CA (so you don't have to worry about trusts)

- If the lb vserver (or other entity) is being accessed by mostly internal users and/or domain joined systems, then you can use your internal CA or Domain CA to issue your certs.

- Wildcard, SAN, multi-san certs can be used as appropriate for your environment.


For the NS service (NS to server side of the connection), you don't usually need a cert on the NS as the NS is the "client" in the server-side connection connecting to the backend server.

Therefore most of the certs you require are on the actual servers and not on the NS itself.

You might need to import a root CA in some cases if you require the NS to trust the certs on the servers it is connecting to; but usually not.


For an end-to-end SSL example, where your NS is doing ssl termination, then your lb with cert example would look like this:


Example; (sorry I didn't use your naming conventions; was on a small screen)

1) user  will connect to load balancing vserver as demo.domain.com; backend servers are srv1.domain.com and srv2.domain.com


# import cert/create ssl certkey

add ssl certkey demo.certkey -cert <certfile.cer> -key <keyfile.pem>


# no cert needed on NS for services; certs are installed on actual backend servers...usually domain signed

add service svc_srv1 <ip1> ssl 443

add service svc_srv2 <ip2> ssl 443


# lb vserver with cert bindings

add lb vserver lb_vsrv_demo ssl <vip1> 443

    bind lb vserver lb_vsrv_demo svc_srv1

    bind lb vserver lb_vsrv_demo svc_srv2

bind ssl vserver lb_vsrv_demo -certkey demo.certkey















Link to comment
Share on other sites

that's look good


I would something like this


add ssl certKey "Cert Name" -cert "Demo.pfx" -key "Demo.pfx" -inform PFX -password test1

add server svc_srv1 <ip1>

add service svc_srv1 <ip1> ssl 443

add lb vserver  lb_vsrv_demo SSL <ip1> 443
bind lb vserver lb_vsrv_demo "svc_srv1"
bind ssl vserver lb_vsrv_demo -certkeyName "Cert Name"

Link to comment
Share on other sites


This topic is now archived and is closed to further replies.

  • Create New...