At the time of writing this issue there is already the following support for tls acceptor auth config:

pub enum ServerAuth {
    SelfSigned(SelfSignedData),
    Single(ServerAuthData),
    CertIssuer(ServerCertIssuerData),
}

Where ServerCertIssuerData is:

pub struct ServerCertIssuerData {
    pub kind: ServerCertIssuerKind,
    pub max_cache_size: u64,
}

and ServerCertIssuerKind is:

pub enum ServerCertIssuerKind {
    SelfSigned(SelfSignedData),
    Single(ServerAuthData),
}

The goal of this issue is to provide a third variant to ServerCertIssuerKind such that it becomes:

pub enum ServerCertIssuerKind {
    SelfSigned(SelfSignedData),
    Single(ServerAuthData),
    Dynamic(???),
}

The dynamic "thing" would support any kind of custom logic to support getting certs. The thing could receive some kind of CertIssueInput, for example:

struct CertIssuerInput {
     pub sni: Host,
}

Proposed steps to resolve this issue:

1. choose an approach, or create your own, work out on paper and align here in the issue in the comment section with me.
2. implement the approach and open a PR as soon as you feel ready, want early feedback, are stuck, have questions, or want to collaborate.

Some approaches we can make this happen:

1. provide a trait ServerCertIssuer and work with a Box`; This approach is the most obvious but also not one I like as it means we have to box by default

2. provide a channel based approach such that the variant would become something like (pseudo code):

  // ...
  Dynamic(ServerCertInputSender),
}

struct ServerCertInputSender {
     sender: Sender<ServerCertInputReceiver>,
}

struct ServerCertInputReceiver {
    sender: oneshot<Result<ServerAuthData, BoxError>>,
}

// the internal details of `ServerCertInputSender` and `ServerCertInputReceiver` would be hidden behind an api that simply uses
// the `send` methods. E.g. `send(input)` and `send(result)`. Wthout having to know the internal implementation
// or that a channel is even used

3. something else. Feel free to propose something other than the above proposals

Generics is something we do want to avoid here as it would make the entire type and using it a lot more cumbersome / complicated. Even when not using this dynamic approach.

This kind of feature would allow the implementation of an external cert issuer, as to not have to keep the CA or physical proximity of the proxy. It could also allow dynamic cert selection. And many other use cases.