You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I plan to work on this myself, but I'm looking for some initial feedback first.
On a very high level ACME logic looks like:
Send post request to CA (eg letsencrypt), with info about which domains you want a certificate for
If this request is ok, CA will send back a list of challenges
A list of these challenges can be found here. Initially we probably want to only support the HTTP-01 challenge. Which is just putting a simple file under a specific path.
Once this is done a new post request is sent to the CA containing a CSR. If this request is ok and the CA confirms the challenge was solved a certificate is send back
What this looks like for rama users:
Use logic provided to specify for which domain names we want a cert for
Run validate logic
If all goes well return certificates, which can then be used later on for tls/https
This is pretty simple logic and rama pretty much has all building blocks already to achieve this. It's just a question of combining them. One of the first questions is then where does this logic belong? It's not really a service, but more a util wrapper. Its mostly http logic, but that changes when we want to support other challenges.
This solution is also pretty bare bones and expects the user to then use these certs. There could also be easier ways to expose this eg an https service, but I think exposing this bare bones is more in line with what this project tries to achieve?
Important thing to note here aswel, this will only provide acme client logic, not cert management logic. Meaning that certs will only be created during startup or when the user uses this logic. Refreshing certs is still the responsibility of the user or could later also be implemented as a followup PR by providing a service that periodically refreshes certs and that the user has to include in its service stack under a predefined path. Exposing this as service is also something that could already be done right now, and only later add the logic to auto refresh certs.
The text was updated successfully, but these errors were encountered:
For now it can live under src/tls/acme/... and you can move the re-export of rama_tls in rama to src/tls/mod.rs.
If ever desired we could make a separate crate for it rama-acme, but for now it seems high level enough that it can akin to the cli serviceslive directly underrama`.
Community members like yourself can also make a crate rama-x-... but ACME seems sufficient foundational to tls services that it warrants official support under rama.
For a first PR I would indeed not do the auto refresh thing yet as that would require some more thought on how to make it interact with the server config.
Can be immediately as a service for now. As rama evolves and as we have real life usage of the ACME service we can always iterate, make it more configurable and separate out potential building blocks later out. But for now it can similar to something like the EchoService be pretty high level.
I plan to work on this myself, but I'm looking for some initial feedback first.
On a very high level ACME logic looks like:
What this looks like for rama users:
This is pretty simple logic and rama pretty much has all building blocks already to achieve this. It's just a question of combining them. One of the first questions is then where does this logic belong? It's not really a service, but more a util wrapper. Its mostly http logic, but that changes when we want to support other challenges.
This solution is also pretty bare bones and expects the user to then use these certs. There could also be easier ways to expose this eg an https service, but I think exposing this bare bones is more in line with what this project tries to achieve?
Important thing to note here aswel, this will only provide acme client logic, not cert management logic. Meaning that certs will only be created during startup or when the user uses this logic. Refreshing certs is still the responsibility of the user or could later also be implemented as a followup PR by providing a service that periodically refreshes certs and that the user has to include in its service stack under a predefined path. Exposing this as service is also something that could already be done right now, and only later add the logic to auto refresh certs.
The text was updated successfully, but these errors were encountered: