Repository navigation
Expose unverified server certificate chains #5821
Description
Activity
After some offline discussion, extending this issue with more related API surface area. For all of these we will want the information exposed via s2n-quic events as part of the delivery (can be unstable):
Local configuration
- [Client + server local certificate chain] Expose the configured local certificate chain from an s2n-tls Connection. This would introspect what was configured on the Config, and return the default certificate chain. The certificate chain should roughly correspond to
s2n_connection_get_selected_cert.selected_certlooks likely to be sufficient for this but I don't see tests for the handshake failure case, so adding/confirming test coverage may be the only s2n-tls ask. - [Client + server local trust store] Expose the configured trust store from an s2n-tls Connection. This could use the same 'serialization' as the cert_authorities extension (i.e., return distinguished names for each contained certificate). This should always be accessible, even if the particular connection didn't use the trust store.
- Active s2n-tls security policy on the Config associated with the connection.
Remote information
- unverified_client_cert_chain exposed in s2n-quic
- unverified_server_cert_chain added (the original ask in this issue)
- server-sent certificate_authorities persisted out of the CertificateRequest as an s2n-quic event / s2n-tls accessor
- client-sent certificate_authorities in ClientHello (new feature) also accessible
- [Client + server local certificate chain] Expose the configured local certificate chain from an s2n-tls Connection. This would introspect what was configured on the Config, and return the default certificate chain. The certificate chain should roughly correspond to
Briefly looked into our cert retrieval behavior. The API for retrieving your own cert works in both successful and failed handshakes. The API to retrieve your peer's cert doesn't work in handshakes that have failed cert authentication (s2n_connection_get_peer_cert_chain.) However, we have another API s2n_connection_get_client_cert_chain that does work after failed cert validation. Weirdly though, in our rust bindings, we gated it by handshake complete, so it cannot return a cert if the handshake fails.
Anyways, yes, there is no way of retrieving a cert if the cert validation fails in our Rust bindings. We're going to need a new API for this so probably just get_unverified_peer_cert_chain() and have it work for both server and client. I suspect we can just generalize what we did for s2n_connection_get_client_cert_chain since it already returns unverified certs.This issue is basically three different asks:
- Expose unverified cert chains (acceptance criteria is s2n-quic can retrieve unverified certs.)
- Expose local and peer certificate authorities(No idea what this is going to look like)
- Connection getter for security policy
@maddeleine I'd like to take the unverified peer cert chain part (just ask 1) if it's still open, and leave the certificate authorities and security policy items for later. For the memory concern in the issue, do you want the chain always collected and dropped after a successful handshake, or put behind an opt-in? If you'd rather take this one yourself given the priority, that works too.
- added 2 commits that reference this issue
on Jun 18, 2026
Security issue notifications
If you discover a potential security issue in s2n we ask that you notify
AWS Security via our vulnerability reporting page. Please do not create a public github issue.
Problem:
Applications using s2n-tls currently cannot access the server's certificate chain when certificate validation fails. The existing s2n_connection_get_peer_cert_chain API requires validation to have succeeded (S2N_ERR_CERT_NOT_VALIDATED is returned otherwise), which prevents applications from inspecting the certificate chain for logging or diagnostics when a handshake fails due to an untrusted or invalid certificate. This makes it harder to debug certificate validation failures, which currently return an opaque ("Certificate is untrusted") error which is not useful for debugging.
This would complement the existing
s2n_connection_get_client_cert_chainAPI, which already provides this functionality for client-sent certificates.Need By Date:
Sooner is better.
Solution:
A description of the possible solution in terms of S2N architecture. Highlight and explain any potentially controversial design decisions taken.
Possible problems to think through:
get_peer_cert_chainmethod? Or maybe we need an opt-in mechanism on the connection to enable collecting this information?Requirements / Acceptance Criteria:
What must a solution address in order to solve the problem? How do we know the solution is complete?
This will need to get exposed in the Rust bindings, so that it can then be exposed in s2n-quic (cc aws/s2n-quic#3037).
Out of scope: