The HandshakeData currently only exposes server name and application protocol, which are submitted in the ClientHello message and are thus available as soon as connection is initiated. The peer's TLS certificate is transmitted later in this TLS handshake and thus will not be available as soon as Connecting is made available. I guess it will become available over the lifetime of the Connecting, but for this reason I don't think it will slot in as easily as you're suggesting it will in your OP.

I am interested in having this. I think the implementation should be similar to handshake_data. The simplest approach would probably be to build similar infrastructure as used for handshake_data and expose a separate async peer_identity getter. One caveat is that we should use a tokio::sync::Notify rather than a oneshot channel so that the method can be &self and have multiple waiters; handshake_data predates this pattern and we haven't gotten around to updating it.

In an ideal world I'd like to be able to access both handshake data and the peer identity on the server before committing to a ServerConfig, similarly to how you can currently inspect information from the first packet via Incoming, but that's probably a larger change than necessary to achieve your goals here.

@Ralith I don't think you can get to the peer identity before committing to config in rustls, and even at the protocol level you'll need to commit to a bunch of configuration values before you get the peer identity, AFAIK?

Ah, okay. We could still probably do the ClientHello stuff (in particular dispatching config based on server name is interesting) but I guess that's completely off topic for this issue then.

Right, doing an Acceptor thing for the server would be interesting, but that's separate from the client identity.