Title: Upstream TLS info unavailable when transport failure occurs
Description:
When upstream TLS validation errors occur, it could be beneficial to provide additional information about the upstream cert (using access log formatter), beside the transport error itself. For example, subject, issuer, validity, SANs and entire cert can be used to troubleshoot the failure.
Right now, in order to provide focused observability on the root cause for TLS validation failure, the error message is enhanced with additional details like SANs, CRLDPs, etc.:
Repro steps:
The config below intentionally fails TLS session establishment due to mismatch between actual and required cert SANs:
static_resources:
listeners:
- name: listener_0
address:
socket_address:
address: 0.0.0.0
port_value: 10000
filter_chains:
- filters:
- name: envoy.filters.network.http_connection_manager
typed_config:
"@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
stat_prefix: ingress_http
access_log:
- name: envoy.access_loggers.stdout
typed_config:
"@type": type.googleapis.com/envoy.extensions.access_loggers.stream.v3.StdoutAccessLog
log_format:
text_format: |
[%START_TIME%] %UPSTREAM_TRANSPORT_FAILURE_REASON% %UPSTREAM_PEER_SUBJECT%
http_filters:
- name: envoy.filters.http.router
typed_config:
"@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router
route_config:
name: local_route
virtual_hosts:
- name: local_service
domains: ["*"]
routes:
- match:
prefix: "/"
route:
host_rewrite_literal: www.envoyproxy.io
cluster: service_envoyproxy_io
clusters:
- name: service_envoyproxy_io
type: LOGICAL_DNS
# Comment out the following line to test on v6 networks
dns_lookup_family: V4_ONLY
load_assignment:
cluster_name: service_envoyproxy_io
endpoints:
- lb_endpoints:
- endpoint:
address:
socket_address:
address: www.envoyproxy.io
port_value: 443
transport_socket:
name: envoy.transport_sockets.tls
typed_config:
"@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.UpstreamTlsContext
sni: www.envoyproxy.io
common_tls_context:
validation_context:
match_typed_subject_alt_names:
- san_type: DNS
matcher:
exact: "not.www.envoyproxy.io"
trusted_ca:
filename: "/etc/ssl/cert.pem"Access logs will not show the Peer Cert details:
[2026-02-18T17:21:14.440Z] TLS_error:|268435581:SSL_routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED:TLS_error_end -
When the validation is removed, peer cert details are avaialble:
[2026-02-18T17:21:42.027Z] - CN=www.envoyproxy.io
Seems like the upstream TLS info is recorded on success:
|
upstream_info.setUpstreamSslConnection(info.downstreamAddressProvider().sslConnection()); |
But only failure reason is recorded on error:
|
stream_info_.upstreamInfo()->setUpstreamTransportFailureReason(transport_failure_reason); |
Title: Upstream TLS info unavailable when transport failure occurs
Description:
When upstream TLS validation errors occur, it could be beneficial to provide additional information about the upstream cert (using access log formatter), beside the transport error itself. For example, subject, issuer, validity, SANs and entire cert can be used to troubleshoot the failure.
Right now, in order to provide focused observability on the root cause for TLS validation failure, the error message is enhanced with additional details like SANs, CRLDPs, etc.:
Repro steps:
The config below intentionally fails TLS session establishment due to mismatch between actual and required cert SANs:
Access logs will not show the Peer Cert details:
[2026-02-18T17:21:14.440Z] TLS_error:|268435581:SSL_routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED:TLS_error_end -When the validation is removed, peer cert details are avaialble:
Seems like the upstream TLS info is recorded on success:
envoy/source/common/router/upstream_request.cc
Line 652 in 2591343
But only failure reason is recorded on error:
envoy/source/common/router/upstream_request.cc
Line 601 in 2591343