Closed FlorianUekermann closed 2 years ago
I just switched out my acceptor for the one in 0.4.0-beta2
, and it seems to be working will. It's deployed in prod and on our test instance.
I think this can be closed, since it looks like 0.5.0 has been released.
@FlorianUekermann I understand why you switched to futures-rustls (I think), but sadly, that's going to make it very difficult to use in the tide-acme project in its current form, since tide-acme integrates with tide-rustls which requires async-rustls.
The only way I'd be able to address that is by fully replacing tide-rustls as well, which would require handling the rest of the TLS details that tide-rustls handled.
Yes, that's unfortunate. I'm a little fuzzy on the details atm, because I switched such a long time ago. I see three ways forward:
From
impl we can use.We should really try to find a solution for this. Let's use #46 for further discussion.
I just published 0.4.0-beta2 on crates.io and would like to release 0.4.0 in a few days. The main changes are:
ServerConfig
for connections that aren't acme validation attempts.The high level API did not change, besides using types from futures-rustls instead of async-rustls. This makes the low level API less opinionated and allows the user to do anything they want with incoming connections. This enables many new usecases via the low level API: -Using alpn with non-validation connections -Mixing other certificate sources by wrapping custom resolvers around the the rutsls-acme resolver -Client authentication
Feedback and test results are much appreciated. @joshtriplett : You may want to test how ergonomic the changed API is on your side. You may want to have a look at the
axum
features as well. Maybe there's something similar you would like to upstream.