This topic provides the steps to configure an internal decryption action profile manually.

Prerequisites

  • Have the correct user role and permissions to set up TLS Inspection.
  • Have an internal server certificate imported or ready to be imported or have the related information to generate the certificate.

Procedure

  1. With admin privileges, log in to NSX Manager.
  2. Select Security > TLS Inspection > Profiles.
  3. Click Add Decryption Action Profile > Internal Decryption.
  4. Enter a name for the new policy.
  5. (Optional) Select a profile setting: Balanced (default), High Fidelity, High Security, or use Custom to change the sub-settings.
    Profile Setting Description
    Decryption Failure: Bypass & Log or Block & Log Sets what to do when there is decryption failure which could be due to mTLS (mutual TLS) or certificate pinning in use. If you select Bypass & Log, then NSX caches this domain, and all subsequent connections to the domain are bypassed.
    Crypto Enforcement: Transparent or Enforce Sets the minimum and maximum TLS versions and cipher suites for the client and server. You can bypass this using the Transparent option.
  6. (Optional) Modify Idle connection timeout. This is the time in seconds the server can remain idle after establishing a TCP connection. Default is 5400 seconds. Keep this timeout lower than the gateway firewall idle timeout settings.
  7. Expand the Server Certificates and Keys section and configure one or more internal server certificates.
    1. Import a certificate or CA certificate. See Import a Self-signed or CA-signed Certificate.
    2. Generate a self-signed certificate or a self-signed CA certificate.
    3. Select an existing server certificate by clicking the check box at the front of the row.
    4. Make an existing server certificate the default by clicking on the Default radio button at the end of the row.

    If the SNI extension is not present in the client hello, the default server certificate is presented to the client. If this option is not configured, then the TLS Proxy does not intercept connections that contain no SNI extension in client hello. If the SNI extension is present in client hello, but there is no matching certificate for that in the list of configured certificates, TLS Proxy does not intercept these connections.

    When a client accesses one of those internal services, the TLS Proxy presents this selected certificate based on the server domain match to Issued-to-field (CN) field.

    If more than one server certificate is configured, they must all have different domains, specified by Common Name (CN) or Subject Alternate Name (SAN). Two certificates cannot be configured for the same domain, either FQDN (for example, www.vmware.com) or wildcard (*.vmware.com). However, certificates with wildcard domains that overlap with specific FQDN certificates are allowed. In such cases, more specific certificates are preferred over wildcard certificates while selecting a certificate to present to the client based on the SNI extension in client hello, .

  8. (Optional) By default the server certificate validation is optional and disabled by default. You do not need to configure this if it is an Enterprise-owned service. If you want to enforce this validation, turn on the Server Certificate Validation by toggling it On.
    1. Expand the section and configure your validation options. You can choose the default trusted CA bundle and CRL or import them.
      For details, see Import or Update a Trusted CA Bundle and Import a Certificate Revocation List.
    2. Click Save.

Results

You are now able to use the internal decryption action profile to configure TLS Inspection policies and rules on your tier-1 gateways.

What to do next

Create TLS Inspection internal decryption policies and rules.