Code change:
2.3.21. <del> Name: tls_handshake_error </del> <ins> Name: tls_protocol_error </ins> <del> Description: The intermediary encountered an error during TLS handshake with the next hop. Extra Parameters: </del> <ins> Description: The intermediary encountered a TLS error when communicating with the next hop, either during handshake or afterwards. </ins> <del> alert_message: a sf-token containing the applicable description string from the TLS Alerts registry. </del> <ins> Extra Parameters: None. </ins> Recommended HTTP status code: 502 2.3.22. <del> Name: tls_untrusted_peer_certificate </del> <ins> Name: tls_certificate_error </ins> <del> Description: The intermediary received an untrusted peer certificate during TLS handshake with the next hop. </del> <ins> Description: The intermediary encountered an error when verifying the certificate presented by the next hop. </ins> Extra Parameters: None.

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.