This file is used to configure aspects of TLS connection handling for both inbound and outbound connections. The configuration is driven by the SNI values provided by the inbound connection. The file consists of a set of configuration items, each identified by an SNI value (fqdn). When an inbound TLS connection is made, the SNI value from the TLS negotiation is matched against the items specified by this file and if there is a match, the values specified in that item override the defaults. This is done during the inbound connection processing and be some outbound properties can be overridden again later, such as via remap.config or plugins.

By default this is named ssl_server_name.yaml. The file can be changed by settting proxy.config.ssl.servername.filename. This file is loaded on start up and by traffic_ctl config reload if the file has been modified since process start.

The configuration file is yaml-based. After parsing the configuration, a list of tables will be the result. Each table is a set of key / value pairs that create a configuration item. This configuration file accepts wildcard entries. To apply an SNI based setting on all the servernames with a common upper level domain name, the user needs to enter the fqdn in the configuration with a *. followed by the common domain name. (* for e.g.,).

Key Meaning
fqdn Fully Qualified Domain Name. This item is used if the SNI value matches this.


By default this is proxy.config.ssl.client.verify.server.policy. This controls how Traffic Server evaluated the origin certificate.


One of the values NONE, SIGNATURE, NAME, and ALL

By default this is This controls what Traffic Server checks when evaluating the origin certificate.

verify_origin_server Deprecated. Use verify_server_policy and verify_server_properties instead. One of the values NONE, MODERATE, or STRICT. By default this is proxy.config.ssl.client.verify.server.

One of the values NONE, MODERATE, or STRICT. If NONE is specified, Traffic Server requests no certificate. If MODERATE is specified Traffic Server will verify a certificate that is presented by the client, but it will not fail the TLS handshake if new certificate is presented. If STRICT is specified the client must resent a certificate during the TLS handshake.

By default this is proxy.config.ssl.client.certification_level.

valid_tls_versions_in This specifies the list of TLS protocols that will be offered to user agents during the TLS negotiaton. This replaces the global settings in proxy.config.ssl.TLSv1, proxy.config.ssl.TLSv1_1, proxy.config.ssl.TLSv1_2, and proxy.config.ssl.TLSv1_3. The potential values are TLSv1, TLSv1_1, TLSv1_2, and TLSv1_3. You must list all protocols that Traffic Server should offer to the client when using this key. This key is only valid for openssl 1.1.0 and later. Older versions of openssl do not provide a hook early enough to update the SSL object. It is a syntax error for Traffic Server built against earlier versions.

The file containing the client certificate to use for the outbound connection.

If this is relative, it is relative to the path in proxy.config.ssl.client.cert.path. If not set proxy.config.ssl.client.cert.filename is used.


The file containing the client private key that corresponds to the certificate for the outbound connection.

If this is relative, it is relative to the path in proxy.config.ssl.client.private_key.path. If not set, Traffic Server tries to use a private key in client_cert. Otherwise, proxy.config.ssl.client.private_key.filename is used.


true or false.

If false then HTTP/2 is removed from the valid next protocol list. It is not an error to set this to false for proxy ports on which HTTP/2 is not enabled.


Destination as an FQDN and port, separated by a colon :.

This will forward all traffic to the specified destination without first terminating the incoming TLS connection.


Destination as an FQDN and port, separated by a colon :.

This is similar to tunnel_route, but it terminates the TLS connection and forwards the decrypted traffic. Traffic Server will not interpret the decrypted data, so the contents do not need to be HTTP.

Client verification, via verify_client, correponds to setting proxy.config.ssl.client.certification_level for this connection as noted below.

Do not request a client certificate, ignore it if one is provided.
Request a client certificate and do verification if one is provided. The connection is denied if the verification of the client provided certificate fails.
Request a client certificate and require one to be provided and verified. If the verification fails the failure is logged to diags.log and the connection is denied.

Upstream (server) verification, via verify_server_policy and verify_server_properties, is similar to client verification except there is always an upstream certificate. This is equivalent to setting proxy.config.ssl.client.verify.server.policy and for this connection.

verify_server_policy specifies how Traffic Server will enforce the server certificate verification.

Do not verify the upstream server certificate.
Do verification of the upstream certificate but do not enforce. If the verification fails the failure is logged in diags.log but the connection is allowed.
Do verification of the upstream certificate. If verification fails, the failure is logged in diags.log and the connection is denied.

In addition verify_server_properties specifies what Traffic Server will check when performing the verification.

Do not check anything in the standard Traffic Server verification routine. Rely entirely on the TS_SSL_VERIFY_SERVER_HOOK for evaluating the origin’s certificate.
Check the signature of the origin certificate.
Verify that the SNI is in the origin certificate.
Verify both the signature and the SNI in the origin certificate.

If tunnel_route is specified, none of the certificate verification will be done because the TLS negotiation will be tunneled to the upstream target, making those values irrelevant for that configuration item. This option is explained in more detail in SNI Routing.


Disable HTTP/2 for

- fqdn:
  disable_h2: true

Require client certificate verification for and any server name ending with Therefore, client request for a server name ending with (for e.g.,, etc.) will cause Traffic Server require and verify the client certificate. By contrast, Traffic Server will allow a client certficate to be provided for and if it is, Traffic Server will require the certificate to be valid.

- fqdn:
  verify_client: MODERATE
- fqdn: '*'
  verify_client: STRICT

Disable outbound server certificate verification for and require a valid client certificate.

- fqdn:
  verify_server_policy: DISABLED
  verify_client: STRICT

See Also

SNI Routing