rustls / rustls/tokio-rustls

Provide an example on how to use `rustls::server::Acceptor`

Open
#97 11 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Rust
Stars
234
Forks
108
Avg merge
5h 12m
Merged PRs (30d)
4

Description

Hello,

I am new to both Rust and async in Rust with tokio so there might be something I might have missed or don't know. Rustls recommends here to use rustls::server::Acceptor for retrieving server certificates dynamically based on ClientHello when working in async manner. But I could not find any useful information on how to use that with Tokio-rustls.

What I have observed is Acceptor implements read_tls method which accepts a parameter which implements Read trait. But tokio::net::TcpStream implements AsyncRead which is not compatible to be passed in Acceptor. Or may be I don't know how to use that.

Any guidance or minimal example is appreciated on how to use Acceptor.

If there are any better ways to implement dynamic server certificates fetched from a key store, I would like to know that too.

PS: I need TCP socket stream directly as I am implementing a Pub/Sub Broker both for experimentation and learning Rust for real use case.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

No repository file or test is named. Start by reading the linked Rustls ServerConfig documentation and inspecting tokio-rustls's existing examples for Tokio TCP streams and server setup. Done means adding a minimal, working Acceptor example that shows dynamic certificate selection and can be followed by a newcomer.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
documentation, networking
Issue type
Documentation
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.