Part 3: SSL certificates and StoreFront load balancing.
Part 5: High Availability configuration.
In the previous parts, we went over the basics of connecting and disconnecting as well as some useful operations and initial configuration. As we continue this journey, we’ll look at SSL certificates and load balancing StoreFront servers.
In order to bind an SSL server certificate to a NetScaler appliance, you must first have a private key file and a certificate file that together form a certificate key pair. There are many ways to achieve this and in the example below we’ll go over a simple scenario to illustrate the process. Additionally, you can also upload the root certificate and link it to the server certificate, which is something we will not cover in the example.
Requesting and configuring a server certificate using a local certification authority
In this example, we do the following:
- Create the private RSA key
- Create the CSR
- Download the CSR
- Request the certificate
- Upload the certificate
- Create the cert/key pair
This can be achieved by calling (which only works on NetScaler 10.5 or higher):
This also assumes that the call is being executed on a machine that has access to the certification authority of the example domain and by a user that is allowed to request certificates.
Configuring StoreFront load balancing
After installing and configuring a cluster of StoreFront servers (including server certificates), you can configure the NetScaler appliance to load balance the servers.
Creating a new StoreFront load balancing configuration
To create a load balancing configuration that load balances StoreFront servers, you would normally go over the following steps:
- Enable features
- Create servers
- Create services
- Create LB monitors
- Bind monitors to services
- Create LB virtual server
- Bind services to LB virtual server
- Bind SSL certificate and key to LB virtual server
This is how we would call the example script which consumes new functions in the example NetScaler Configuration module:
Keep in mind that the values for the parameters in all of the example calls must be modified to fit your configuration.
Get the example PowerShell Module and script (Part 3)
This module is now updated in Scripting: Automating NetScaler configurations using NITRO REST API and PowerShell – Part 4
Coming up next
We’ll continue with additional use cases and examples as part of the NetScaler Configuration PowerShell module example.
This software / sample code is provided to you “AS IS” with no representations, warranties or conditions of any kind. You may use, modify and distribute it at your own risk. CITRIX DISCLAIMS ALL WARRANTIES WHATSOEVER, EXPRESS, IMPLIED, WRITTEN, ORAL OR STATUTORY, INCLUDING WITHOUT LIMITATION WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NONINFRINGEMENT. Without limiting the generality of the foregoing, you acknowledge and agree that (a) the software / sample code may exhibit errors, design flaws or other problems, possibly resulting in loss of data or damage to property; (b) it may not be possible to make the software / sample code fully functional; and (c) Citrix may, without notice or liability to you, cease to make available the current version and/or any future versions of the software / sample code. In no event should the software / code be used to support of ultra-hazardous activities, including but not limited to life support or blasting activities. NEITHER CITRIX NOR ITS AFFILIATES OR AGENTS WILL BE LIABLE, UNDER BREACH OF CONTRACT OR ANY OTHER THEORY OF LIABILITY, FOR ANY DAMAGES WHATSOEVER ARISING FROM USE OF THE SOFTWARE / SAMPLE CODE, INCLUDING WITHOUT LIMITATION DIRECT, SPECIAL, INCIDENTAL, PUNITIVE, CONSEQUENTIAL OR OTHER DAMAGES, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. You agree to indemnify and defend Citrix against any and all claims arising from your use, modification or distribution of the code.