NSX Advanced Load Balancer supports terminating client SSL and TLS connections at the virtual service, which requires it to send a certificate to clients that authenticate the site and establishes secure communications.
A virtual service that handles secure connections requires the following:
SSL/ TLS profile
This determines the supported ciphers and versions. For more information on SSL/ TLS profiles, see SSL/TLS Profile topic in the VMware NSX Advanced Load BalancerConfiguration Guide.
SSL Certificate
This is presented to clients connecting to the site.
SSL certificates can be used to present to administrators connecting to the NSX Advanced Load Balancer web interface or API, and also for the NSX Advanced Load Balancer SE to present to servers when SE-to-server encryption is required with client (the SE) authentication.
The SSL/TLS Certificates page on allows the import, export, and generation of new SSL certificates or certificate requests. Newly-created certificates may be either self-signed by NSX Advanced Load Balancer or created as a Certificate Signing Request (CSR) that must be sent to a trusted Certificate Authority (CA), that generates a trusted certificate.
Creating a self-signed certificate generates both the certificate and a corresponding private key.
Imported existing certificates are not valid until a matching key has been supplied.
NSX Advanced Load Balancer supports PEM and PKCS #12 formats for certificates.
SSL/ TLS Certificates Page
Navigate to to open the SSL/TLS Certificates page. This tab includes the following functionalities:
Search: Search across the list of objects.
Create: Shows the list of certificates from the drop-down menu to create a certificate.
Edit: Opens the Edit Certificatewindow. Only incomplete certificates that do not have a corresponding key can be edited.
Export: The down arrow icon exports a certificate and corresponding private key.
Delete: A certificate may only be deleted if it is not currently assigned to a virtual service. An error message will indicate the virtual service referencing the certificate.
The table on this tab contains the following information for each certificate:
Name: This displays the name of the certificate. Mouse over the name of the certificate will display any intermediate certificate that has been automatically associated with the certificate.
Status: This shows the status of the certificate. Status in 'green' indicates it is good, in 'yellow'/orange/red' indicates the certificate is expiring soon or has already expired, and 'gray' indication, if the certificate is incomplete.
Common Name: This displays the fully qualified name of the site to which the certificate applies. This entry must match the hostname the client will enter in their browser in order for the site to be considered trusted.
Issuer Name: This displays the name of the certificate authority.
Algorithm: This displays the algorithm as either EC (Elliptic Curve) or RSA.
Self Signed: This displays whether the certificate is self-signed by NSX Advanced Load Balancer or signed by a Certificate Authority.
Valid Until: This displays the date and time when the certificate expires.
Create Certificate
Navigate to . Click Create to open the New Certificate (SSL/ TLS)window.
When creating a new certificate, you can select any of the following certificates:
Root/Intermediate CA Certificate: This certificate is used to automatically create the certificate chain for application certificates. There are no configuration options other than importing the certificate through a file or pasting the text. The root/ intermediate certificate will show up in a separate table at the bottom of the SSL Certificates page. It is recommended to import the root/intermediate certificate prior to importing an application certificate that relies on the intermediate for the chain.
Application Certificate: This certificate is used for normal SSL termination and decryption on NSX Advanced Load Balancer. This option is also used to import or create a client certificate for NSX Advanced Load Balancer to present to a back-end server when it needs to authenticate itself.
Controller Certificate: This certificate is used for the GUI and API for the Controller cluster. Once uploaded, select the certification through .
To create a new certificate, follow the steps below:
Name: Specify the name of the certificate.
Type: Select the type of certificate to create from the drop-down menu. The following are the options:
Self Signed: Quickly create a test certificate that is signed by NSX Advanced Load Balancer. Client browsers will display an error that the certificate is not trusted. If the HTTP application profile has HTTP Strict Transport Security (HSTS) enabled, clients will not be able to access a site with a self signed certificate.
CSR: Create a valid certificate by first creating the certificate request. This request must be sent to a certificate authority, which will send back a valid certificate that must be imported back into NSX Advanced Load Balancer.
Import: Import a completed certificate that was either received from a certificate authority or exported from another server.
Common Name: Specify the fully qualified name of the site, such as www.vmware.com. This entry must match the hostname the client entered in the browser in order for the site to be considered trusted.
Input the required information required for the type of certificate you are creating:
Self-Signed Certificates
CSR Certificates
Importing Certificates
The OCSP stapling can be enabled and configured using the UI. For more information, see OCSP Stapling in NSX Advanced Load Balancer topic in the VMware NSX Advanced Load BalancerConfiguration Guide.
Self-Signed Certificates
NSX Advanced Load Balancer can generate self-signed certificates. Client browsers do not trust these certificates and will warn the user that the virtual service’s certificate is not part of a trust chain.
Self-signed certificates are good for testing or environments where administrators control the clients and can safely bypass the browser’s security alerts. Public websites must never use self-signed certificates.
If you have selected Self Signed option from Type drop-down menu in the New Certificate window, then specify the following details:
Common Name- Specify the fully-qualified name of the site, such as www.vmware.com. For the site to be considered trusted, this entry must match the hostname that the client entered in the browser.
Organization: Company or entity registering the certificate, such as NSX Advanced Load Balancer Networks, Inc. (optional).
Organization Unit: Group within the organization that is responsible for the certificate, such as Development (optional).
Country: Country in which the organization is located (optional).
State Name or Province: State in which the organization is located (optional).
Locality or City: City of the organization (optional).
Email: The email contact for the certificate (optional).
Subject Alternate Name (SAN)- The Subject Alternate Name (SAN) lets you specify additional host names to be protected by a single SSL certificate, such as example.com and example.org. The are essentially the alternative identities of the subject that is specified in the Certificate.
Algorithm: Select either EC (Elliptic Curve) or RSA. RSA is older and considered less secure than EC, but is more compatible with a broader array of older browsers. EC is new, less expensive computationally, and generally more secure; however, it is not yet accepted by all clients. NSX Advanced Load Balancer allows a virtual service to be configured with two certificates at a time, one each of RSA and EC. This will enable it to negotiate the optimal algorithm with the client. If the client supports EC, then the NSX Advanced Load Balancer will prefer this algorithm, which gives the benefit of natively supporting Perfect Forward Secrecy for better security.
Key Size: Select the level of encryption to be used for handshakes, as follows:
2048-bit is recommended for RSA certificates. Higher values may provide stronger encryption, but dramatically increase the CPU resources required by both NSX Advanced Load Balancer and the client. For stronger encryption, use ECC certificates instead.
SECP256R1 is recommended for EC certificates.
Higher values may provide better encryption but increase the CPU resources required by both NSX Advanced Load Balancer and the client.
Enable HSM Certificate: Rather than store the private key locally on the Controller or Service Engine, it is maintained in an external hardware security module. This option enables referencing an HSM profile containing information about communicating with the HSM.
After specifying the necessary details, click Save.
CSR Certificates
The Certificate Signing Request (CSR) is the first of three steps involved in creating a valid SSL/ TLS certificate. The request contains the same parameters as a Self-Signed Certificate. However, NSX Advanced Load Balancer does not sign the completed certificate. Rather, it must be signed by a Certificate Authority that is trusted by client browsers.
You can select CSR option from Type drop-down menu in the New Certificate window. The configuration options for a certificate signing request are the same as for self-signed certificates. See the descriptions above for definition of each field.
Once completed, forward the completed CSR to any trusted Certificate Authority (CA), such as Thawte or Verisign by selecting the Certificate Signing Request at the bottom left of the Add Certificate popup. Then either copy-paste it directly to the CA’s website or save it to a file for later use.
Once the CA issues the completed certificate, either paste or upload it into Certificate field at the bottom right of Add Certificate popup. The certificate is not usable on NSX Advanced Load Balancer until this step is complete.
It can take several days for the CA to return the finished certificate. Meanwhile, you can close the New Certificate window to return to the SSL/TLS Certificates page. The new certificate will appear in the table with the notation Awaiting Certificate Valid Until column.
When you receive the completed certificate, click Edit icon for the certificate to open the Edit Certificate, and then paste the certificate and click Save to generate the CSR certificate. NSX Advanced Load Balancer will generate a key from the completed certificate automatically.
Import Certificates
You can directly import an existing PEM or PKCS /#12 SSL/ TLS certificate into NSX Advanced Load Balancer (such as from another server or load balancer). A certificate will have a corresponding private key, which must also be imported.
NSX Advanced Load Balancer generates the key for self-signed or CSR certificates automatically.
The following are the steps to import the certificate:
Navigate to .
Click CREATE and select the certificate type such as Application Certificate.
Click Type and select Import. Certificate or Private Key can be imported by copying-pasting or uploading a file.
PEM File – PEM files contain certificate or private key in plain-text Base64 encoded format. Certificate and private key can be provided in separate PEM files or combined in a single PEM file.
If certificate and private key are provided in a single PEM file, navigate to Paste Key text box and add the private key by following any one of the methods listed below:
Upload File: Click the Upload File button, select the PEM or PKCS12 file, then click Validate button to parse the file. If the upload is successful then, the Key field will be populated.
Paste: Copy and paste a PEM key into the Key field. Ensure that you do not introduce extra characters in the text, which can occur while using some e mail clients or rich text editors. If you copy and paste the key and certificate together as one file then, click Validate button to parse the text and populate the Certificate field.
If certificate and private key are provided in two separate PEM files, follow the below steps to import each individually:
Certificate - Add the certificate in the Paste Certificate text box by copying-pasting or file upload, as described above.
Key – Add the private key in the Paste Key field by copying-pasting or file upload.
PKCS#12 File - PKCS #12 files contain both the certificate and key, PKCS #12 is a binary format, which cannot be copied-pasted, and hence it can be uploaded only. Navigate to the Paste Key and follow the below step to import the PKCS #12 file.
Upload File - Click the Import File button, select the PKCS #12 file, click the Validate button to parse the file. If the upload is successful, both the Key and Certificate fields will be populated.
Key Passphrase: You can also add and validate a key passphrase to encrypt the private key.
Import: Select Import to finish adding the new certificate and key. The key will be embedded with the certificate and treated as one object within the NSX Advanced Load Balancer UI.
Certificate Authority
Certificates require a trusted chain of authority to be considered as valid. If the certificate used is directly generated by a certificate authority that is known to all client browsers then, no certificate chain is required. However, if there are multiple levels required, an intermediate certificate may be necessary. Clients will often traverse the path indicated by the certificate to validate on their own if no chain certificate is presented by a site, but this adds additional DNS lookups and time for the initial site load. The ideal scenario is to present the chain certificates along with the site cert.
If a chain certificate, or rather a certificate for a certificate authority, is uploaded through the in the certificates page, it will be added to the Certificate Authority section. NSX Advanced Load Balancer will automatically build the certificate chain if it detects a next link in the chain exists.
To validate a certificate that has been attached to a chain certificate, hover the pointer over the certificate’s name in the SSL Certificates table at the top of the page. NSX Advanced Load Balancer supports multiple chain paths. Each may share the same CA issuer, or they can be chained to different issuers.
SSL/ TLS Profile
NSX Advanced Load Balancer supports the ability to terminate SSL connections between the client and the virtual service, and to enable encryption between NSX Advanced Load Balancer and the back-end servers. The SSL/ TLS profile contains the list of accepted SSL versions and the prioritized list of SSL ciphers.
Both an SSL/ TLS profile and an SSL certificate must be assigned to the virtual service while configuring it to terminate client SSL/ TLS connections. If you encrypt traffic between NSX Advanced Load Balancer and the servers then, an SSL/ TLS profile must be assigned to the pool. While creating a new virtual service through the basic mode, the default system SSL/TLS profile is used automatically.
SSL termination can be performed on any service port. However, browsers assume that the default port as 443. The best practice is to configure a virtual service to accept both HTTP and HTTPS by creating a service on port 80, by selecting the + icon to add an additional service port, and then set the new service port to 443 with SSL enabled. A redirect from HTTP to HTTPS is generally preferable, which can be done through a policy or by using the System-HTTP-Secure application profile.
Each SSL/ TLS profile contains default groupings of supported SSL ciphers and versions that may be used with RSA or an Elliptic Curve certificate, or both. Ensure that any new SSL/TLS profile you create, includes ciphers that are appropriate for the certificate type that will be used later. The default SSL/ TLS profiles included with NSX Advanced Load Balancer provides a broad range of security. For instance, the Standard Profile works for typical deployments.
Creating a new SSL/ TLS profile or using an existing profile entails various trade-offs between security, compatibility, and computational expense. For instance, increasing the list of accepted ciphers and SSL versions increases the compatibility with clients while also lowering security potentially.
NSX Advanced Load Balancer can accommodate a broader set of security needs within a client community by associating multiple SSL profiles with a single virtual service, and have the Service Engines choose which to use based on the client’s IP address. For more information, see 'Client-IP-based SSL Profiles' section in this guide.
SSL Profile Settings
Navigate to .
Search: Searches across the list of objects.
Create: Opens the new application or
systemprofile.Edit: Opens the existing profile to edit.
Delete: An SSL/ TLS profile can only be deleted, if it is not currently assigned to a virtual service. An error message will indicate the virtual service referencing the profile. The default system profiles can be modified, but not deleted.
The table on this tab provides the following information for each SSL/ TLS profile:
Name: Name of the profile.
Accepted Versions: SSL and TLS versions accepted by the profile.
Create an SSL Profile
The following are the steps to create or edit an SSL profile:
Name: Specify a unique name for the SSL/ TLS Profile.
Type: Select the type of profile from the drop-down menu.
Accepted Versions: Select one or more SSL/ TLS versions from the drop-down menu to add to this profile. Chronologically, TLS v1.0 is the oldest supported, and TLS v1.2 is the newest. SSL v3.0 is no longer support as of NSX Advanced Load Balancer v15.2. In general with SSL, older versions have many known vulnerabilities while newer versions have many undiscovered vulnerabilities. As with any security, NSX Advanced Load Balancer recommends diligence to understand the dynamic nature of security and to ensure that NSX Advanced Load Balancer is always up to date. Some SSL ciphers are dependent on specific versions of SSL or TLS supported. For more information, see OpenSSL.
Accepted Ciphers: Enter the list of accepted ciphers in the Accepted Ciphers field. Each cipher entered must conform to the cipher suite names listed at OpenSSL. Separate each cipher with a colon. For instance, AES:3DES means that this Profile will accept the AES and 3DES ciphers. When negotiating ciphers with the client, NSX Advanced Load Balancer will prefer ciphers in the order listed. You may use an SSL/ TLS profile with both an RSA and an Elliptic Curve certificate. These two types of certificates can use different types of ciphers, so it is important to incorporate ciphers for both types. Selecting only the most secure ciphers may incur higher CPU load on NSX Advanced Load Balancer and may also reduce compatibility with older browsers.
PKI Profile
For more information on PKI Profile, see PKI Profile and PKI Profile Settings topics in the VMware NSX Advanced Load BalancerConfiguration Guide.
Certificate Management
To create a new certificate, follow the steps below:
From the UI, navigate to the .
Click Create.
In the New Certificate Management screen, enter the Name of the profile.
In the Control Script field, select the required alert script configuration, as required.
Note:Click Create button in the drop down, to create a new Control Script (if required).
If the profile needs to pass some parameter values to the script, select Enable Custom Parameters.
Enter the Name and Value for the parameters.
Note:Re-upload the Control Script, if the file has been modified after uploading for the changes to reflect.
The location (URL) of the Trust Anchor service and the login credentials for the service, will be passed to the script. For parameters that are sensitive (for instance, passwords), select the Sensitive check box.
Marking a parameter sensitive prevents its value from being displayed in the web interface or being passed by the API. For parameters that are to be dynamically assigned during CSR creation, select the Dynamic check box. This leaves the parameter unassigned within the profile.
Click Save.
Authentication Profile
The Authentication profile (“auth profile”) allows configuration of clients into a virtual service through HTTP basic authentication.
The authentication profile is enabled through the HTTP basic authentication setting of a virtual service’s Advanced Properties tab.
NSX Advanced Load Balancer also supports client authentication through SSL client certificates, which is configured the HTTP Profile’s Authentication section.
Auth Profile Settings
Select to open the Auth tab. This tab includes the following functions:
Search: Search across the list of objects.
Create: Opens the Create/ Edit window.
Edit: Opens the Create/ Edit window.
Delete: An Auth profile may only be deleted if it is not currently assigned to a virtual service or in use by NSX Advanced Load Balancer for administrative authentication.
The table on this tab provides the following information for each authorization profile:
Name: Name of the profile.
Type: The Type will be LDAP.
Create an Authentication Profile
To create or edit an authentication profile, do the following:
Name: Enter a unique name.
LDAP Servers: Configure one or more LDAP servers by adding their IP addresses.
LDAP Port: This is the service port to use when communicating with the LDAP servers. This is typically 389 for LDAP or 636 for LDAPS (SSL).
Secure LDAP using TLS: Enable startTLS for secure communications with the LDAP servers. This may require a service port change.
Base DN: LDAP Directory Base Distinguished Name. Used as default for settings where DN is required but was not populated like User or Group Search DN.
Anonymous Bind: Minimal LDAP settings that are required to verify User authentication credentials by binding to LDAP server. This option is useful when you do not have access to administrator account on the LDAP server.
User DN Pattern: LDAP user DN pattern is used to bind an LDAP user after replacing the user token with real user name. The pattern must match the user record path in the LDAP server. For instance, cn=,ou=People,dc=myorg,dc=com is a pattern where we expect to find all user records under ou “People”. When searching LDAP for a specific user, we replace the token with user name.
User Token: An LDAP token is replaced with real user name in the user DN pattern. For instance, inUser DN Pattern is configured as “cn=-user-,ou=People,dc=myorg,dc=com”, the token value must be -user-.
User ID Attribute: LDAP user ID attribute is the login attribute that uniquely identifies a single user record. The value of this attribute must match the user name used at the login prompt.
User Attributes: LDAP user attributes to fetch on a successful user bind. These attributes are used only for debugging purpose.
Administrator Bind: LDAP administrator credentials configured under LDAP Directory Settings below are used to bind NSX Advanced Load Balancer as an admin when querying LDAP for Users or Groups.
Admin Bind DN: Full DN of LDAP administrator. Admin bind DN is used to bind to an LDAP server. Administrators must have sufficient privileges to search for users under user search DN or groups under group search DN.
Admin Bind Password: Administrator password. Password expiration or change is not handled. The password is hidden from Rest API and CLI.
User Search DN: LDAP user search DN is the root of search for a given user in the LDAP directory. Only user records present in this LDAP directory sub-tree are allowed for authentication. Base DN value is used if this value is not configured.
Group Search DN: LDAP group search DN is the root of search for a given group in the LDAP directory. Only matching groups present in this LDAP directory sub-tree will be checked for user membership. Base DN value is used if this value is not configured.
User Search Scope: LDAP user search scope defines how deep to search for the user starting from user search DN. The options are search at base, search one level below or search the entire subtree. The default option is to search one-level deep under user search DN.
Group Search Scope: LDAP group search scope defines how deep to search for the group starting from the group search DN. The default value is the entire subtree.
User ID Attribute: LDAP user ID attribute is the login attribute that uniquely identifies a single user record. The value of this attribute must match the user name used at the login prompt.
Group Member Attribute: LDAP group attribute that identifies each of the group members. For instance, member and memberUid are commonly used attributes.
User Attributes: LDAP user attributes to fetch on a successful user bind. These attributes are only for debugging.
Insert HTTP Header for Client UserID: Insert HTTP header into the client request before it is sent to the destination server. This field is used to name the header. The value will be the client’s User ID. This same User ID value will also be used to populate the User ID field in the Virtual Service’s logs.
Required User Group Membership: User must be a member of these groups. Each group is identified by the DN. For instance,
cn=testgroup,ou=groups,dc=LDAP,dc=example,dc=comAuth Credentials Cache Expiration: The maximum allowed length of time a client’s authentication is cached.
Group Member Attribute Is Full DN: Group member entries contain full DNs instead of only User ID attribute values.
