A security certificate is required for TLS Inspection on NSX. To intercept, decrypt, and encrypt traffic for TLS Inspection and other advanced security applications, you must prepare the TLS proxy so it can act as a transparent proxy for TLS connections. NSX Manager requires these certificates to establish trust between applications.

Certificate management supports the following options for TLS Inspection.
  • Import an existing certificate or generate a new self-signed or CA self-signed CSR (certificate signing request).
  • Export an existing certificate.
  • Import or update a default trusted CA bundle.
  • Import or update a default public certificate revocation list (CRL).
  • Advanced filtering on all predefined filter options.
  • Expired certificate banner on Certificates page.
  • Color-coded notification of valid or invalid certificates.

For information on these options, see Certificates.

The TLS proxy requires a CA certificate, also called the proxy CA. NSX Manager uses the proxy CA to generate certificates that impersonate the endpoints in the intercepted connection. In other words, it helps to spoof certificates for the intercepted traffic on website servers. You can choose one of two types of proxy CA certificates:

To generate certificates that impersonate the endpoints in the intercepted connection, the TLS proxy requires a CA certificate, also called the proxy CA. NSX Manager uses the proxy CA. In other words, it helps to spoof. You can choose one of two types of proxy CA certificates:
  • Self-signed certificates are typically used for testing or limited deployments that are untrusted. This workflow begins with a request to the NSX Manager to generate a CA certificate keypair with a CSR (Certificate Signing Request). It then makes a request to the NSX Manager to self-sign the CSR.
  • An Enterprise issuing CA signs trusted subordinate CA certificates. This workflow begins with a request to the NSX Manager to generate a CA certificate keypair with a CSR, download the CSR, then submit the CSR to the Issuing CA which results in receiving a signed certificate. It then uploads the signed public CA certificate to the NSX Manager. The upload can include a certificate chain. Certificate chains are intermediate signing certificates between the new certificate and the root CA certificate.

There are several ways to upload a new CA certificate to the NSX Manager: use the TLS wizard in the UI, manually add the certificate in the UI, or use the NSX API. For details, see Import a CA Certificate.

Trusted CA Bundles

After setup, these CA certificates get distributed to the nodes running the TLS proxy. You can upload multiple CA certificate bundles with different names. Each CA bundle used by the TLS proxy gets configured in the decryption action profile. Upon upload, the CA bundle gets validated as a well-formed concatenation of PEM-encoded certificates and does not get stored if it is invalid. If a bundle is invalid, it returns API error messages.

A single bundle is limited to 1 MB in size and 1,000 certificates.

Certificate Revocation List

To ensure the certificates offered by the endpoints of the intercepted connection do not get revoked, you can use the TLS Proxy CRL, default_public_crl. You can update this object by uploading a new CRL to replace the existing one. You can use it in policy profiles. To upload a new CRL to the NSX Manager use the UI or API. The CRL gets distributed to the nodes running the TLS Proxy. The API validates the CRL upon upload and refuses to store it if it is invalid. NSX supports two CRL formats:
  • PEM-encoded X.509 CRL - 40 MB maximum size, 500,000 entries
  • Mozilla OneCRL - 5 MB maximum size, 10,000 entries

Alarm Handling for TLS Inspection Certificates

If you do not maintain your proxy CA certificates and they are close to expiring or have expired or you have received an expired CA certificate, NSX Manager uses alarms to notify you.

NSX raises the same set of alarms for expiring or expired certificates in CA bundles.

You may also receive a remote logging server error due to an invalid TLS certificate. The event error logged is Log messages to logging server {hostname_or_ip_address_with_port}({entity_id}) cannot be delivered possibly due to an unresolvable FQDN, an invalid TLS certificate or missing NSX appliance iptables rule. To verify the specified certificate is valid, use the openssl command openssl x509 -in <cert-file-path> -noout -dates. You can also view and update certificates in the TLS Inspection UI.

For more details on certificate expiration, see Alarm Notification for Certificate Expiration. For details on TLS-specific "Certificate Events" from the NSX Manager, see the Event Catalog.