Skip to content

fix(transport): reload_tls_config reaches the acceptor's certificate - #208

Merged
yeoleobun merged 1 commit into
restsend:mainfrom
pmenke-de:fix/tls-reload-reaches-acceptor
Oct 16, 2026
Merged

yeoleobun merged 1 commit into
restsend:mainfrom
pmenke-de:fix/tls-reload-reaches-acceptor

Conversation

@pmenke-de

Copy link
Copy Markdown
Contributor

Fixes #207.

Problem

reload_tls_config reports success but the listener keeps presenting
the certificate it started with.

create_acceptor (src/transport/tls.rs) builds the rustls
ServerConfig with Arc::new(resolver.clone()) and returns
Arc::new(resolver) as the handle stored in cert_resolver.
ReloadableCertResolver::clone creates a fresh RwLock with a copy of
the CertifiedKey, so the acceptor and the stored handle are two
resolvers. A reload writes to the stored one; handshakes read from the
acceptor's copy.

Fix

Create one Arc<ReloadableCertResolver> and give that same Arc to
with_cert_resolver and to the caller. Nothing else changes:
ReloadableCertResolver, its Clone impl and reload_tls_config stay
as they are.

Test

test_reload_tls_config_reaches_handshake in
src/transport/tests/test_tls_reload.rs: serves a TlsListenerConnection
with certificate A, connects with a rustls client whose verifier records
the presented end-entity certificate, calls reload_tls_config with
certificate B, connects again and expects B.

On main the test fails at the second assertion (A is presented again);
with this change it passes. The existing resolver tests in that file
keep passing (they call reload on a resolver directly and so never saw
the problem).

Checks

cargo fmt --check, cargo test --lib (441 tests).

create_acceptor built the rustls ServerConfig with a clone of the
ReloadableCertResolver and kept the original for reload_tls_config.
ReloadableCertResolver::clone creates a new lock with a copy of the
certificate, so a reload replaced the certificate of the stored
resolver while the acceptor kept answering handshakes with the one it
started with. The reload logged success and had no effect on the wire.

Wrap the resolver in one Arc and hand that Arc to both the ServerConfig
and the listener, so a reload is seen by the next handshake.

Add a regression test that serves a TLS listener, records the
certificate a client is presented, reloads, connects again and expects
the new certificate. It fails on main and passes with this change.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
@yeoleobun
yeoleobun merged commit 1bd53ec into restsend:main Oct 16, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

TlsListenerConnection::reload_tls_config never changes the certificate the listener presents

2 participants