Feature request: more detailed access log info for TLS errors

[kenjenkins]

Is your feature request related to a problem? Please describe.

The error message from #4366 indicated a certificate verification problem, but did not include any specific details about the nature of the verification issue. This makes it more difficult to diagnose the cause of the problem.

Describe the solution you'd like

Is there any way to get Envoy to provide more details about the nature of certificate verification issues? (e.g. to help distinguish between cases where a certificate is expired, or the SAN doesn't match, or the certificate was not issued by a trusted root)

Describe alternatives you've considered

I tried setting proxy_log_level: debug, but that did not appear to give any additional information about TLS errors (it didn't appear to have any effect, as far as I can tell, so I might be using it incorrectly).

Explain any additional use-cases

n/a

Additional context

n/a

[kenjenkins]

According to the documentation:

When Envoy originates TLS when making connections to upstream clusters, any errors will be logged into UPSTREAM_TRANSPORT_FAILURE_REASON field or AccessLogCommon.upstream_transport_failure_reason field.

[...]

Common errors are:

• Secret is not supplied by SDS: Envoy is still waiting SDS to deliver key/cert or root CA.
• SSLV3_ALERT_CERTIFICATE_EXPIRED: Peer certificate is expired and not allowed in config.
• SSLV3_ALERT_CERTIFICATE_UNKNOWN: Peer certificate is not in config specified SPKI.
• SSLV3_ALERT_HANDSHAKE_FAILURE: Handshake failed, usually due to upstream requires client certificate but not presented.
• TLSV1_ALERT_PROTOCOL_VERSION: TLS protocol version mismatch.
• TLSV1_ALERT_UNKNOWN_CA: Peer certificate CA is not in trusted CA.

More detailed list of error that can be raised by BoringSSL can be found here

However I'm not seeing any of these in the access log; instead I'm seeing the same generic message "TLS error: 268435581:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED".