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: I think the core question is whether you expect the client and the proxy to be in the same management domain. If they aren't, and the ED seems to be oriented around this scenario (where server and proxy are likely same administrative domain, but proxy and client aren't), then it seems better served as an opaque diagnostic string. As RFC 4158 calls out, beyond the 'boolean' is really just an administrative/diagnostic capability, not something meant to be semantically rich, meaningful, or stable, and certainly not to allow next-hop policy decision making.
Just to be clear - the user agent isn't involved in this at all, beyond receiving the header so as to make it available to someone diagnosing a problem (Likely someone from the origin, from the CDN/reverse proxy operator, and/or a help desk talking to an end user). What I think I hear you saying is that we should define a generic error and allow implementations to convey textual detail in it. Does that make sense? I also still see some value in distinguishing a TLS alert received from the origin by the proxy (in its role as TLS client) from this case (a problem it encounters as a TLS client).
Yes. This matches with Criterion 2 of URL and the dual mode trade-off in URL , which perhaps more clearly highlights the local policy aspect ("Ultimately, the developer determines how to handle the trade-off between efficiency and provision of information"). 100% agreed here. I was only commenting to the extent at which the proxy validates the peer certificate independent of the TLS layer framing. Perhaps poorly stated, but my comment in URL was trying to capture that Option 2 from URL () would likely just reduce to a boolean anyways, in a well-behaved TLS client.