Code change:
2.3.23. <del> Name: tls_expired_peer_certificate Description: The intermediary received an expired peer certificate during TLS handshake with the next hop. Extra Parameters: None. Recommended HTTP status code: 502 2.3.24. Name: tls_unexpected_peer_certificate Description: The intermediary received an unexpected peer certificate (e.g., SPKI doesn't match) during the TLS handshake with the next hop. Extra Parameters: identity: a sf-string containing a comma-separated list of Subject Alternative Names from the certificate received from the next hop. sha256: a sf-string containing the hex-encoded SHA-256 of the certificate received from the next hop. spki: a sf-string containing the base64-encoded SHA-256 of the Subject Public Key Info (SPKI) from the certificate received from the next hop. Recommended HTTP status code: 502 2.3.25. Name: tls_missing_proxy_certificate Description: The next hop requested a client certificate from the intermediary during TLS handshake, but it wasn't configured with one. </del> <ins> Name: tls_alert_received </ins> <del> Extra Parameters: None. Recommended HTTP status code: 500 2.3.26. Name: tls_rejected_proxy_certificate Description: The next hop rejected the client certificate provided by the intermediary during TLS handshake. Extra Parameters: None. Recommended HTTP status code: 500 2.3.27. Name: tls_error Description: The intermediary encountered a TLS error when communicating with the next hop. </del> <ins> Description: The intermediary received a TLS alert from the next hop. </ins> Extra Parameters:

Related discussion:
text: While I can understand the appeal for providing 'informational' statuses, any suggestion beyond a level of is probably too normative, and unsupported by the underlying specifications and best practices.
NAME the context here is a CDN or other reverse proxy reporting back errors in HTTP response headers, for debugging. There are no requirements around sending them (and senders are cautioned against leaking information that could aid an attacker). So, at one end a Boolean doesn't really help, and at the other end, the full list of errors by any one library (or all of them) is impractical. The list of alerts from NAME seems promising, and I note that we already have , whose value can be any TLS Alert string. However, That's intended to convey alerts received (and perhaps we should communicate that more clearly). The desired semantics here are that the problem indicated by the alert is generated in the client itself, not received by it. That leads me to believe that there are two viable paths forward: Rearrange the errors so that they mirror the alerts above (leaving 's semantic as stated above); e.g., we'd have , , and so forth Reduce everything into two errors, and or similar. Both would carry the TLS Alert value as an additional payload item. I think the difference is mostly stylistic, so NAME and I can figure that out. The bigger question is whether this is the right set of errors to focus upon.
But I think this is missing an important detail: from the perspective of a client, the only stable output is the boolean. For example, OpenSSL's reporting of errors is symptomatic of deeper flaws within its certificate verification; fixing those errors necessarily means some existing errors can't effectively be reported. This is covered at some length in . Ultimately, the set of errors that are relevant are, to an extent, subject to local policy: it's rare for certificate validators to think of errors in the ontology laid out by the TLS layer. Typically, a client just does a "best guess" (or just maps straight to ) when trying to map to the TLS layer, in part so it doesn't disclose extra information. This is certainly true when you think about local policy, such as limits on validity or the requirement of associated metadata, potentially delivered over TLS, such as Certificate Transparency or OCSP Must-Staple.