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: PTAL NAME NAME NAME
Looks reasonable to me!
NAME PTAL; I'll merge tomorrow if I don't hear anything.
NAME how do you distinguish between a proxy certificate and the certificate used for the next hop?
By "proxy certificate" I mean the certificate sent by the CDN (when acting as a client) to the origin server for the purpose of mutual authentication. In contrast, would apply (at least in my mind) only to the certificate presented by the origin server.
So, I think the argument is that is either a (i.e., the server you're connecting to gave you an error to the effect that you need to present a client certificate), or a (i.e., you realised you need to present a certificate before connecting, but don't have one) depending on exactly how the error occurred. Is that sufficient?
As someone who spent countless hours debugging connection issues to various origin servers, my main concern is that alone doesn't provide enough information as to why the connection failed, it only narrows it down to a TLS certificate issue, but for anything definitive that you would want to share with the customer, you'd still need to go and dig further into logs, or try to replicate the issue. Yes, I know that you could put more information in the "details" field, but I'm not a big fan of implementation-specific free-form text. Having said that, I'm not going to oppose if you prefer to have only those 3 generic fields.
Thanks. As Ryan points out, the problem is that implementations have different terminology and granularity of error reporting, and it's not the place of this specification to impose that on them.
Looking at what to map x509 errors (as returned by into, the most obvious one is . However, there's also , which is one of these errors. It seems odd to have these two, but not any of the many other verification errors. At first glance, I suspect it may be better to have a single error, and let the convey the reason - whether it's expiration or something else.
Ultimately, there is a fine balance between providing a generic "catch-all" error, and enumerating all possible errors. The linked lists 69 possible reasons for success or failure, and including all of them clearly doesn't make sense, especially when only a few of them will happen in practice.