tls: Add a way to inspect peer certificate chain

[nielsdevreede-rl]

Seastar currently offers the following three functions that enable inspection of part of the certificate chain presented by and accepted from the peer during a TLS handshake using X.509 certificate credentials.

• seastar::tls::certificate_credentials::set_dn_verification_callback
• seastar::tls::get_dn_information
• seastar::tls::get_alt_name_information
  These function only provide access to the Distinguished Name of the subject and the issuer and the Subject Alternative Name of the leaf certificate accepted during the handshake. Applications may have a need to inspect other properties of the certificate or certificate chain as as accepted during the TLS handshake.

Here, we propose to introduce the function seastar::tls::get_peer_certificate_chain to inspect the raw peer certificate chain data as presented and accepted during the TLS handshake. We propose not to introduce any additional abstractions to the intentionally simple existing Seastar TLS interface and to return the raw certificate data as a sequence of sequence of bytes.

We attempt to retain existing Seastar implementation conventions as much as possible, by closely mimicking the existing implementation and documentation of seastar::tls::get_dn_information and seastar::tls::session::get_peer_certificate. This leads to some minor code duplication between seastar::tls::session::get_peer_certificate and seastar::tls::session::get_peer_certificate_chain, which we propose not to resolve as these two superficially similar functions serve different purposes and return incompatible types.

We propose to introduce a single test case, test_peer_certificate_chain_handling, mostly mimicking the test_alt_names test case. For this we also propose to generate simple additional certificate test data.

Please let me know if this is suitable for inclusion upstream. I'm happy to clarify design decisions and/or update my pull request according to your guidance.

Kind regards,

Niels

[avikivity]

@elcallio please review

[elcallio]

Would maybe like to see a typedef for the byte contents, but no other real objections.

[niekbouman-rl]

nice work Niels, I left two small questions in tls_test.cc

[avikivity]

Please use the normal changelog style, we don't use feat(whatever).

[nielsdevreede-rl]

As requested, I have changed the commit message, introduced a type alias and fixed my CMake errors. For ease of review, I have made the latter changes in separate commits, but would propose to squash all commits into a single commit upon your approval.

[xemul]

As requested, I have changed the commit message,

It's still feat(TLS): introduce tls::get_peer_certificate_chain somehow

[nielsdevreede-rl]

I have updated the pull request title to match the commit description. I have also squashed the commits and synced with master in an attempt to resolve the workflow failures.

[nielsdevreede-rl]

It seems the test failures are due to the fact the the subject and issuer of the leaf certificate contain identical distinguished names and do not identify the authority by key ID. I managed to resolve this using OpenSSL 3.2.2, but not using OpenSSL 3.2.0, which is the version provided by Ubuntu 24.04. Instead of trying to resolve this, I propose to simplify the unit test so that only a "chain" of length one is tested.

Apologies for the repeated test failures

[niekbouman-rl]

LGTM!

[avikivity]

Please fold the patches into each other, we only keep patch history if the patches are logically separate, not if they fix each other.

[nielsdevreede-rl]

Please fold the patches into each other, we only keep patch history if the patches are logically separate, not if they fix each other.

Done