elsdoerfer/acme-daemon repository overview

This is a daemon that handles the querying of Let's Encrypt certificates.

⁠Development

There is a staging letsencrypt key in the repo:

$ ACCOUNT_JSON="$(cat $(pwd)/devaccount.json)" LOG_LEVEL=DEBUG gunicorn wsgi:app --worker-class gevent -w 4 --reload
$ http POST http://127.0.0.1:8000/get domain=01861477.ngrok.io

To make a staging account:

• Edit simp_le.py to not require a successful validation to write the account_key.json Look at the end of the persist_new_data() function.
• simp_le --server https://acme-staging.api.letsencrypt.org/directory⁠ -d test.de:$(pwd)/devaccount -f account_key.json -f cert.pem -f chain.pem -f key.pem --default_root .

⁠Deployment

• Two images, both on DockerHub Public.
• Built via Github push.

⁠Configuration

ACCOUNT_KEY Note that this, I think, must be in a format as generated by simp_le? It is does proprietary? Or is it JWRSA? STORAGE

⁠TODO

Instead of simp_le, use:

• https://github.com/mail-in-a-box/free_tls_certificates⁠
• Patch simpl_le to be better for library use

⁠How it works

/add API to request a cert for a domain. /get to see if a cert exists for a domain.

When you add, the cert is added to an internal queue. We could use a real queue system later, but this was easiest for now. Because of the fragility of this, you should think of this more of an call-style API that might fail. It's up to you to persist certs, and call into /add again if the first attempt failed (this one will not repeat that).

It's also up to you to renew the certs.

Persistence of the certs: This system, for now, is not intended to persist the certificates. It actually has a system to do this, but I added it as a crutch, to allow the caller of the system to treat the cert as something that can be recreated (without actual re-issuance).

Maybe I am still not sure what this service is supposed to be.