Basic TLS termination
To expose a listener over HTTPS, set the listenerprotocol to HTTPS and supply a tls block with the paths to your certificate and private key.
This is the exact configuration from
examples/tls/config.yaml. Self-signed certificates require the -k flag when testing with curl.TLS fields reference
Cipher suites
You can restrict which cipher suites the listener negotiates. The order you specify is preserved — agentgateway will prefer suites listed first.- TLS 1.3 only
- TLS 1.2 + 1.3
Supported cipher suites
TLS 1.3 cipher suites
TLS 1.3 cipher suites
TLS 1.2 cipher suites
TLS 1.2 cipher suites
TLS version control
Agentgateway supports TLS 1.2 and TLS 1.3 only. UseminTLSVersion and maxTLSVersion to pin the acceptable range.
Attempts to configure versions below TLS 1.2 are not supported.
Backend TLS
When agentgateway proxies traffic to an upstream service that requires TLS, configurebackendTLS on the route policy. Agentgateway will use the system trusted CA certificates by default, and automatically derive the SNI from the destination hostname.
Custom CA certificate
To verify the upstream with a custom CA, reference a ConfigMap containing the CA certificate:Custom SNI
Override the SNI sent during the TLS handshake:Skip verification (insecure)
Hostname mode verifies the CA certificate but ignores hostname/SAN mismatches.
Mutual TLS (mTLS)
mTLS requires clients to present a certificate signed by a trusted CA. Set thetls.root field to the CA certificate path on the listener.
Backend mTLS
To use a client certificate when connecting to a backend (outbound mTLS), reference a Kubernetes Secret containing the client certificate:kubernetes.io/tls with tls.crt and tls.key data fields. An optional ca.crt field, if present, will be used to verify the server certificate.
Complete example
1
Generate a self-signed certificate
2
Write the agentgateway config
3
Start agentgateway
4
Test the connection