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:

1. Send post request to CA (eg letsencrypt), with info about which domains you want a certificate for
2. If this request is ok, CA will send back a list of challenges
3. 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.
4. 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:

1. Use logic provided to specify for which domain names we want a cert for
2. Run validate logic
3. 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.