Skip to main content
The Terminate TLS Traffic Policy action allows you to control how ngrok terminates TLS traffic. This action is useful when you need to specify a custom certificate, control which TLS versions are supported, or enable mutual TLS authentication.

Configuration reference

This is the Traffic Policy configuration reference for this action.

Supported phases

  • on_tcp_connect

Supported schemes

  • https
  • tls

Type

terminate-tls

Configuration fields

Behavior

For HTTPS endpoints, ngrok already terminates TLS connections for you even if you don’t explicitly use this action in your Traffic Policy. If you specify this action in your Traffic Policy without any configuration, you see no change in behavior for your endpoints. For TLS endpoints, ngrok doesn’t terminate the TLS connection by default, and it’s up to you to handle TLS termination in your upstream service.

Changing supported TLS versions

You can use this action to specify the minimum and maximum TLS versions that your endpoint supports for incoming connections. By default, your endpoint supports TLS versions 1.2 and 1.3. To support different versions of TLS, use the min_version and max_version fields in the configuration. Clients using an unsupported version of TLS receive a handshake error.

Non-terminating action

This is a Non-terminating action. It does not return a response, and will allow Traffic Policy processing to continue to the next Action in the chain. All Cloud Endpoint Traffic Policies must end with a terminating action. This requirement does not apply to Agent Endpoints.

Examples

Minimum and maximum TLS versions

This example sets the minimum and maximum TLS versions that the endpoint supports for incoming connections to TLS version 1.3. Clients can then only connect to the endpoint using TLS version 1.3 and receive a handshake error if they attempt to connect using a different version.

Example Traffic Policy document

Start an endpoint with Traffic Policy

Make a request

If your curl was built with a version of OpenSSL that supports TLS 1.3, the request succeeds. However, you can verify that the endpoint only supports TLS 1.3 by telling curl to use a different version of TLS:
You receive an “alert protocol version” error indicating that the endpoint only supports TLS 1.3.

Using a custom certificate

To specify a custom certificate for your endpoints instead of having ngrok manage the certificate for you, use the server_private_key and server_certificate fields in the configuration. This gives you full control over which certificate your endpoint uses.

Generate certificates

Create a new Certificate Authority (CA) to sign the server certificate. This allows you to generate multiple server certificates that the CA trusts if needed.
This generates a self-signed certificate. To use a custom certificate that modern operating systems and browsers trust, you need to use a trusted CA (for example, LetsEncrypt).
1

Generate CA private key (ca.key)

2

Generate CA certificate (ca.crt)

3

Generate server private key (server.key)

4

Generate server certificate signing request (CSR) (server.csr)

Change terminate-tls-example.ngrok.app to the domain you’re using with your endpoint.
5

Generate server certificate (server.crt)

These commands create five new files: ca.key, ca.crt, server.key, server.csr, and server.key.

Example Traffic Policy document

Replace the contents of server_private_key with the contents of server.key and server_certificate with server.crt respectively in the Traffic Policy to enable your custom certificate on your endpoint and ca.crt to trust the certificate when using curl.

Start an endpoint with Traffic Policy

Make a request

Now you can make a request to the endpoint with the --cacert flag to specify the CA certificate you generated.
If you have a service running on port 8080, ngrok forwards your request to that service. If you don’t have any service running on that port, ngrok returns an error page, but the certificate setup still works.

Enabling mutual TLS

This example demonstrates how to use mutual TLS (mTLS) with this action. mTLS requires both the client and server to present certificates to each other to establish a secure connection. This example shows you how to generate a custom Certificate Authority (CA) and client certificate to use.

Generate certificates

Create a new CA to sign the client certificate. This allows you to generate multiple client certificates that the CA trusts if needed.
These commands create five new files: ca.key, ca.crt, client.key, client.csr, and client.key. You use the contents of ca.crt in your Traffic Policy to validate requests from curl, which uses client.key and client.crt.

Example Traffic Policy document

Using the CA certificate you generated, you can specify the mutual_tls_certificate_authorities field in the Traffic Policy to trust the CA that issued the client certificate.
You can also upload the CA certificate in the ngrok dashboard and use its ID in the mutual_tls_certificate_authorities array.

Start an endpoint with Traffic Policy

Make a request

Now you can make a request to the endpoint with the --cert and --key flags to specify the client certificate and private key.

Action result variables

The following variables are made available for use in subsequent expressions and CEL interpolations after the action has run. Variable values will only apply to the last action execution, results are not concatenated.
These variables are also available on the conn object (see HTTP Variables for examples).