Let’s Encrypt is a free, automated (automates both issuing and renewing the certificate) and open certificate authority. This section elaborates the configuration summary for the Let’s Encrypt integration with the NSX Advanced Load Balancer.

The SSL/ TLS protocol helps to keep an internet connection secure. It safeguards any sensitive data sent between two machines, systems, or devices, preventing intruders from reading and modifying any information transferred between two machines/ systems/ devices. The SSL/ TLS Certificate facilitates secure, encrypted connections between the two machines, systems, or devices. However, there are some challenges around SSL/ TLS Certificate:

  • Manually getting a certificate

  • The cost associated with a certificate signed by CA

Let’s Encrypt resolves all the above challenges. For more information on this, see Let’s Encrypt.

Working with Let's Encrypt

Before issuing a certificate, Let’s Encrypt servers validate that the requester controls the domain names in that certificate using “challenges,” as defined by the ACME standard. Let’s Encrypt uses the ACME protocol to verify that you control a given domain name and issue you a certificate. There are different ways that the agent/ client can prove control of the domain:

  • Provisioning a DNS record under the domain (as per CSR’s common name).

  • Provisioning an HTTP resource under a well-known URI.

Note:

NSX Advanced Load Balancer supports HTTP-01 challenge for domain validation.

HTTP-01 Challenge

  • Let’s Encrypt gives a token to ACME client, and the ACME client puts a file on the web server at http://<YOUR_DOMAIN>/well-known/acme-challenge/<TOKEN>. That file contains the token, plus a thumbprint of account key.

  • Once the ACME client tells Let’s Encrypt that the file is ready, Let’s Encrypt tries retrieving it (potentially multiple times from multiple vantage points).

  • If validation checks get the right responses from the web server, the validation is considered successful, and certificate will be issued.

Note:

As Let’s Encrypt CA communicates on port 80 for HTTP-01 challenge, hence port 80 must be opened on the firewall and Let’s Encrypt CA must be able to reach to user’s network (network where NSX Advanced Load Balancer System is deployed, Let’s Encrypt CA connects through public network to user’s NSX Advanced Load Balancer System on port 80).

If there is a virtual service listening on port 80 at NSX Advanced Load Balancer, script does not create a virtual service else script would automatically create a virtual service listening on port 80 for the respective virtual service listening on port 443/ custom SSL Port.

For more information regarding domain validation see the below URLs:

Configuring Let’s Encrypt

The following is the configuration summary for the Let’s Encrypt integration with the NSX Advanced Load Balancer :

  1. Get the script that will assist in getting and renewing the certificate.

  2. Add the script as controller script on NSX Advanced Load Balancer system.

  3. Add user account with customer (limited access only).

  4. Create certificate management profile on NSX Advanced Load Balancer system.

  5. Add virtual service on NSX Advanced Load Balancer system.

  6. Ensure that FQDN resolves to public IP, port 80 is open at Firewall.

  7. Create CSR and select the configured certificate management profile.

  8. Review the list of certificates, Let’s Encrypt CA would push signed certificate.

  9. Associate the certificate to the configured virtual service.

Note:

Steps 1, 2, and 4 are required only if DNS-01 Challenge is used. For HTTP-01 Challenge, the Certificate Management profile will be available already as a drop-down in Step 7. Also for DNS-01 Challenge, you must provide your own implementation of add_dns_text_record and remove_dns_text_record functions.

For the Let’s Encrypt ControlScript to work, FQDN has to be configured for vsvip. If the option is not available through the UI, use the CLI to configure an FQDN in the vsvip:

[admin:alert-ctlr]: > configure vsvip <vsvip name>
[admin:alert-ctlr]: vsvip> dns_info
[admin:alert-ctlr]: vsvip:dns_info>
[admin:alert-ctlr]: vsvip:dns_info> fqdn <fqdn>
[admin:alert-ctlr]: vsvip:dns_info> save
[admin:alert-ctlr]: vsvip> save

Configuring the NSX Advanced Load Balancer System

To configure Let’s Encrypt for NSX Advanced Load Balancer.

  1. Download the script available at letsencrypt_mgmt_profile. To download the file, click Raw option. Copy the code available.

  2. In the NSX Advanced Load Balancer Controller, navigate to Templates > Scripts > ControlScripts and click Create.

  3. Add a Name, paste the code copied in step 1 in the Import or Paste Control Script field, and Save the configuration.

  4. Configure a custom role by navigating to Administration > Accounts > Roles. Ensure that write access is enabled for Virtual Service, Application Profile, SSL/TLS Certificates and Certificate Management Profile, for this role.



  5. Navigate to Administration > Accounts > Users > CREATE. Create a user, enter all the required details, and select the configured custom role.





  6. Navigate to Templates > Security > Certificate Management and click Create.

  7. Enter a Name, select the configured Control Script and Enable Custom Script Parameters, and add Custom Script Params as shown below:



    Note:

    It is recommended not to use admin account. Always add a user account which has custom role (with limited access).

  8. Navigate to Templates > Security > SSL/TLS Certificates, click Create and select Application Certificate.

  9. In the NEW CERTIFICATE (SSL/TLS) screen, enter all the details in the fields, select the Self Signed, CSR, or Import option from the Type drop-down menu as required, and select the configured Certificate Management Profile.



  10. Under Certificate, enter Common Name, enter all relevant details and save the configuration. For more information on configuring OCSP Stapling, see OCSP Stapling.



Note:

Ensure that a virtual service is configured with the Application Domain Name as Common Name (CN) of certificate. CN of certificate must match with the Application Domain Name of the virtual service. FQDN (CN of certificate or Application Domain Name of virtual service must resolve to IP address and the domain must be reachable).

After few minutes, review the list of the certificates. You can see the certificate pushed by Let’s Encrypt CA. Associate the certificate to the configured virtual service.

Logs

To view the logs, enable non-significant logs for the configured virtual service and generate the certificate. Following is an example of the log.





Automation of Certificate Renewal

From the Controller properties, ssl_certificate_expiry_warning_days can be configured. By default, ssl_certificate_expiry_warning_days can be 30 days, 7 days, and 1 day. This setting can be modified if required. When certificate renewal is required (based on configured settings), the script gets activated and automatically takes care of certificate renewal.

Note:

Let’s Encrypt CA imposes a rate limit. So ensure that the renewal of the certificate does not impact the rate limit.

Automatic Certificate Renewal for the Imported Certificate

Automatic certificate renewal for imported certificates can be done for:

  • CSR generated on NSX Advanced Load Balancer, signed by Let’s Encrypt and then imported on NSX Advanced Load Balancer. If the certificate management profile is configured for a certificate, a renewal is attempted in the last-but-one interval. By default, the Controller generates events 30 days, 7 days, and 1 day before expiry. In this setting, certificate renewal will be attempted 7 days before expiry.

  • Certificate (signed manually by Let’s Encrypt outside NSX Advanced Load Balancer) and key imported on NSX Advanced Load Balancer (CSR not created on NSX Advanced Load Balancer).

Once the CSR is generated and signed by Let’s Encrypt CA, update the certificate uploaded by the user by this newly generated certificate. This certificate goes to automatic default renewal cycle.

Configuring Force Certificate Renewal

You can configure on-demand force certificate renewal for:

CSR generated on NSX Advanced Load Balancer, manually signed by Let’s Encrypt and then imported on NSX Advanced Load Balancer Certificate renewal is done from the backend using the API endpoint:

/api/sslkeyandcertificate/{uuid}/renew

Starting with NSX Advanced Load Balancer version 22.1.3, force certificate renewal is supported through the UI.

  1. To configure force certificate renewal,

  2. From the NSX Advanced Load Balancer UI, navigate to Templates > Security > SSL/TLS Certificates the certificate required, and click the Renew icon.



  3. Click YES, CONTINUE in the confirmation prompt that appears.

  4. On successful certificate renewal, the following message is displayed:



Native support for Life-Cycle-Management for Let’s Encrypt Certificate

Starting with NSX Advanced Load Balancer 22.1.3, a Let’s Encrypt Certificate Management profile is available by default for attaching while creating a CSR. When the Controller boots up, the Certificate Management profile for Let’s Encrypt is available by default. Configure the name, tenant, and password.

The Let’s Encrypt Management profile will be available for selection in the Certificate Management Profile field in the application profile.

Note:

For native support, only the HTTP-01 challenge is currently addressed in NSX Advanced Load Balancer, and the DNS-01 challenge is not supported.

Additional Information