Add a high-level mirage-compatible module for paf-le #75
Conversation
|
This proposal sounds good to me but I am worried about the dependency graph. Indeed, As soon as I have some time, I could look at the proposal in more detail. |
- We renamed the module to `paf-le.mirage` (and follow the same distribution pattern of `paf` - We updated the implementation to use `Lwt.both` and ensure the concurrency between the HTTP webserver and our Let's encrypt _asker_. When the second is done, we stop the first one and returns the result - A documentation is added which mentions the required DNS configuration
|
I took the opportunity to improve your PR. I will try to figure out about a solution for #76 |
| request) in | ||
| Paf.http_service ~error_handler request_handler in | ||
|
|
||
| Paf.init ~port:80 (Stack.tcp stackv4v6) >>= fun http -> |
There was a problem hiding this comment.
Is this still necessary? I was under the impression that the Alpn protocol would remove the need for a hardcoded HTTP service on port 80.
There was a problem hiding this comment.
The HTTP/80 webserver is mainly here to solve 2 issues:
- redirect any request from
http://hostname/tohttps://hostname/ - still be able to launch the let's encrypt challenge when the certificate expired
EDIT: ALPN just solve the issue of the underlying protocol used to communicate via TLS (and say the we can communicate with http/1.1 or h2. The redirection is still needed on 80 (where ALPN operates on the 443 default TLS port)
There was a problem hiding this comment.
I guess that's where my confusion comes from, eventually @dinosaure as well.
With RFC 8737, let's encrypt allows a ALPN challenge which works as follows:
- the ACME server (from let's encrypt) connects via http + tls (client) to the domain name of the certificate
- in this connection, the ALPN
tls-alpn-01is used - our server is supposed to use a specific certificate (self-signed with some ACME extension) and private key to show that our let's encrypt client is in control of the web server
Now, with the current setup of TLS and certificate selection, I don't think we can easily get this up.
So, the current approach, as implemented by @dinosaure, looks fine to me. Future work may include to extend the TLS config in respect of certificate selection (though the logic is already pretty complex, unfortunately).
TL;DR: I opened mirleft/ocaml-tls#465 to track the above, and once that is achieved, we can come back to paf.
|
Apart from me having forgotten the |
Co-authored-by: Kate <kit.ty.kate@disroot.org>
|
/cc @hannesm, this is the PR which is needed to improve your about |
yes, this looks fine to me. thanks for working on that :) |
Co-authored-by: Hannes Mehnert <hannes@mehnert.org>
|
Let's merge and cut a release, @kit-ty-kate: I'm not totally sure about the |
CHANGES: - Fix memory leak about functor application (@dinosaure, dinosaure/paf-le-chien#78) - Add a new sub-package `le.mirage` to facilite obtaining a let's encrypt certificate and expose few functions to handle Let's encrypt certificates (@kit-ty-kate, @dinosaure, @hannesm, dinosaure/paf-le-chien#75)
No description provided.