Update TLS certificates in running server

[mbacarella]

Is there a way to do this at present?

It introduces some operational risk to do an unattended server restart just to freshen the server certificates. With ACME/Lets Encrypt it needs to be done every 60 days, so, it's not completely negligible.

[mbacarella]

I offer a $100 bounty for this: https://www.bountysource.com/issues/103418479-update-tls-certificates-in-running-server

[hannesm]

Not in conduit (since I don't understand it too well), neither in cohttp -- but such a mechanism is available e.g. in unipi: https://github.com/roburio/unipi/blob/9b4a3f8650e22dcf6b5a7b51a14dd8938eef2129/unikernel.ml#L188-L237 -- the same approach being used in dns-resolver https://git.robur.io/robur/dns-resolver/src/commit/e3e58547eaa63553b0680ae15cfb84632989384b/unikernel.ml#L21-L39 (though here, dns-certify.mirage is used to grab the certificate via dns, with OCaml-DNS running the authoritative nameservers and https://github.com/roburio/dns-letsencrypt-secondary being responsible for LE provisioning -- notably tlstunnel does the same https://github.com/roburio/tlstunnel/blob/23a22f8702b4d1519b7f8f73bebe9582d63aeedb/unikernel.ml#L304-L340).

[hannesm]

not sure about the use case, but I recommend to give unipi a try: data in a git remote, uses http/af, let's encrypt provisioning builtin. clear separation from code (unikernel) and data to server (git remote).

[mbacarella]

I understand, though I have working, well-worn code based on Cohttp already that I'd rather continue to use.

[dinosaure]

I understand, though I have working, well-worn code based on Cohttp already that I'd rather continue to use.

I would like to advise you to give a try on http/af/unipi 👍 (it should not be hard, types are globally the same). It seems clear that ocaml-conduit is not into an active development and, in my goal, I planned to delete ocaml-conduit from all of my libraries. For instance, unipi or more specially paf and httpaf do what you want.

paf provides a way to do the let's encrypt challenge, see these lines.

Then, it is able to use h2 - and by this way, the server support HTTP/2.0 protocol - via the ALPN mechanism. CoHTTP is not able to do that.

Finally, I'm looking forward about a PR on httpaf to be able to support HTTP upgrade (from 1.1 to 2.0/websocket). More globally, I see much more coming work on this side than CoHTTP and this is why I chosen this path now.

EDIT: Plus it seems clear that httpaf is more performant than CoHTTP, you can look into this PR