Code change:
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. However, having only a generic "catch-all" error with the real reason "hidden" in a free-form text in , that's going to vary from implementation to implementation, is going to make this less useful for any kind of automated processing and/or analysis. Ideally, I think, we should have specific enums that cover 95%+ of reasons happening in production, and only use the generic "catch-all" error for things not covered by them... So, playing the devil's advocate, perhaps we should add a few more? (Note that there is already raised on mismatched identity, SHA256, SPKI or other missed expectations.) Also, if you can get your hands on errors happening in production, that could help us make more informed decision here.
I agree we shouldn't do a 1:1 mapping (especially with a library), but the hierarchy needs to be clear, and mapped to terminology used in the standards. I.e., there should be a generic catch-all 'cert error' code, and then more specific ones for the major classes of problems.
TLS itself also contains a pile of certificate-verification-related alerts. Although I think the set is mostly just carried over from SSL. URL NAME may also have some thoughts on certificate verification error-reporting.
Despite what libraries may provide, for their developers, is fairly clear: the only defined result is a I think coupling any protocol-level expectation about diagnostics for errors is fundamentally misaligned. It should not matter, for example, whether a particular library checks the validity period of the certificate before the signature. We know, empirically, that different libraries do very different things there: macOS vs Mozilla NSS vs Microsoft CryptoAPI each verify something like validity at different points within their verification algorithms. We know it's deeply flawed to view there being "the" certificate chain for a server, because by definition, the chain is defined by the client's policy and set of trust anchors. As a consequence, we know that clients SHOULD implement certificate path building, to explore possible certificate chains, and we know that TLS 1.3 was explicitly updated to reflect those decades of running code and the emergent rough consensus that the message, beyond the first , is an attempt to aid/influence that. is a huge collection of different ways verifiers can process and examine errors, during forward path building and reverse verification, and notes that the trade-offs are heavily dependent upon client and use cases. 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. 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.

Related discussion:
text: 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.