More context in example

[Ange-Cesari]

Hey @FlorianUekermann ,

I have trouble understanding both low and high API, would you mind having some context / documentation about what is the acme server address we have to reach, the port, how to stop the server once it's done (is a detach the only action required ? How does it work with tokio then ?) and all the other things you might seem necessary

Best, Ange

[FlorianUekermann]

Hi Ange,

If you are using tokio, the high_level_tokio example is the best place to start.

Based on the questions above, I suspect there is some confusion about how the crate works. I'm guessing a bit what the confusion is about, based on the questions above, so not all of the following may be exactly what you need to know. Don't hesitate to ask follow-up questions.

what is the acme server address we have to reach, the port,

I suspect you are referring to the arguments of the bind call (e.g. tokio::net::TcpListener::bind(....). Those have nothing to do with acme, or this crate. The arguments are just the address of your servers network interface and port on which you want to listen for incoming connections. For https on all available network interfaces no specific IP Ipv6Addr::UNSPECIFIED and port 443 are usually what you want.

how to stop the server once it's done (is a detach the only action required

With the high level API, you don't need to do anything to stop the server. If you don't call next() on AcmeIncoming, it's not doing anything and as soon as AcmeIncoming is dropped, all resources are freed automatically. With the low level API it's up to you to stop the task you may have spawned, that is polling AcmeState. But I highly recommend using the high-level API, unless you have a reason not to. The .detach() in some examples is just how independent tasks are spawned using the smol runtime, that has nothing to do with shutting anything down.

In case that part wasn't clear: You typically don't want to stop calling AcmeIncoming::next() or shut anything down at all. AcmeIncoming::next() yields TLS connections, which you use with whatever http implementation you want to use. Examples for warp and axum already exist. If there is another one you want to use, please let me know so I can have a look at it.

Hope that helps.

[Ange-Cesari]

Hello @FlorianUekermann ,

Thank you for taking the time to answer. It's no surprise you couldn't answer fully my questions, i didn't give you context at all.

For a little bit of context, i was asking you if it's possible to shut down the 443 port because I have this Workflow :

I need, as soon as my binary is up, to ask for a signed certificate to my acme server.

Which means that I need, at the very beggining, the binary is up to use the port 443, do the TLS ALPN challenge (with your lib) then, shut down the 443 port.

Create a https server (with another lib) on the 443 port to be able to receive mtls connections

And at the moment the certificate will expire, the mtls connections on port 443 is down, and we redo a CSR, redo the TLS ALPN challenge (with your lib again) , and then redown the 443 to reup the server...

I'd like to know if your lib also manages the keypair creation ? If not, what kind of key do we have to create ? (pkcs1, 8...) is it pem format or something else ?

If you lib does the managing of the key, what kind of Keys do you create ?

Sorry I did not give you full hints to answer,

Best, Ange

[FlorianUekermann]

I see. Simple answers first:

• Yes, this lib manages keypair creation. It uses rcgen.
• AcmeState::resolver() gives you access to a rustls::server::ResolvesServerCert, which you may use to get the certificate using the resolve method. Polling AcmeState::next() will yield EventOk::DeployedNewCert to signal that a cert was acquired.
• Dropping stuff cleans up everything, there's nothing else you need to do.

However, the library is very composable and may already cover your usecase better than you think. I think you can simplify the process you outlined significantly, if you use rustls for mtls. Have a look at the low-level examples for details. It boils down to this:

• Listen to tcp connections on 443 any way you like
• use futures_rustls::LazyConfigAcceptor or similar to get the ClientHello
• check if the incoming tls connection is an alpn challenge using rustls_acme::is_tls_alpn_challenge
  • if yes: Use the rustls config provided by AcmeState::challenge_rustls_config() to complete the handshake
  • if no: Use whatever config you want for the mtls handshake, as long it contains the server cert resolver provided by AcmeState::resolver()

As long as you keep polling AcmeState::next(), renewal will be taken care of automatically.

In case this is commercial and you would like some hands-on help (code, review, call), I'm happy to help on a consulting basis. If this is a private open source project I'm also happy to look at a few lines of code for free.