gateway-tls-overview

TLS certificate selection uses SNI matchers to map the client's requested server name to the appropriate certificate in the TLS store during the downstream TLS termination handshake. The gateway evaluates SNI to select the correct certificate before completing the handshake.

mTLS handshake failures during BackendTLSPolicy SAN validation often occur when the upstream backend certificate Subject Alternative Names do not match the expected policy configuration. The gateway enforces fail-closed behavior, aborting the connection if SAN validation fails.

Pingora BoringSSL handshake tracing follows a strict callback order: select_certificate_callback, then certificate_callback, and finally handshake_complete_callback. The min_tls_version must be set during the select_certificate_callback stage to ensure proper handshake execution.

TLS early-abort troubleshooting requires checking the early-abort audit path when certificate_callback never executes. The gateway logs this fail-closed event to audit the connection termination, indicating the handshake failed before reaching the certificate verification stage.

BoringSSL and OpenSSL differ in callback lifecycle management and snapshot ex_data requirements for gateway TLS termination. Pingora relies on BoringSSL specific callback ordering and snapshot-based certificate application, which affects how TLS states are managed during handshakes.

Upstream mTLS verification modes should be configured when the gateway acts as a TLS client connecting to secure backends requiring mutual authentication. BackendTLSPolicy drives this upstream mTLS behavior, enforcing certificate SAN validation against the backend's presented credentials.