Acmetool only allows 1 email address for generating certs

[emcniece]

A common use-case is to have LE email addresses for specific domains. With the current setup, only a single email address can be used for generation.

Investigating if acmetool can accept an email address via CLI. If so, we should use labels to specify an LE email in addition to the default one.

[emcniece]

While acmetool doesn't accept CLI email addresses, it does accept --response-file. It would be possible to create a responses file for each issued domain, then insert an email address into each unique file.

This is a bad option - it introduces the need for state management, string replacement, and lots of conditional handling.

[Munsio]

Indeed this is a bad option.
I think an extra cli command for the email address could be tricky cause than acmetool itself is responsible to store this information.

Maybe we could make a pull request for something like:
An additional .json property file should be stored to each issued domain where this kind of information is stored. With that even the batch command could recreate the certificates.

[Munsio]

Or what if we support that feature with a little bit of manual work.
like rgon.le-response = 'my-handmade-response-file'

In the catalog itself we ask him for an default email and he can add those response-files by hand on the system if he really needs it

[emcniece]

I like the rgon.le-response option better as the power is in our hands, not with a third-party application.

This will require more templating logic in Rancher-Gen, as we will have to handle something like

notify-cmd="acmetool want {{.Labels.rgon.domain}} --response-file {{.Labels.rgon.le-response | /var/lib/acme/conf/responses}}"

The response-file substitution logic could also be handled within Rancher-Gen:

notify-cmd="acmetool want {{.Labels.rgon.domain}} {{response-file .Labels.rgon.le-response}}"

[mathuin]

Out of curiosity, why not create the response file on the fly from a template? You have a template generation tool right there -- default to the address set during stack creation and only override if a label is present. One optional new label per container is far better than adding a whole file.

[emcniece]

This makes a ton of sense!

We can leverage label substitution and guarantee that there is a response file for each domain.

[Munsio]

@mathuin you are right it would be much easier but we have to think about the recreation of the certificates. Acmetool has a "batch" command where it recreates all of its certs that are > 66% of the expiring date. Thats definitly a thing we need to check if it is possible if we only create those files on the fly cause i for my self wan't the additional responsibility to safe the state of everything to enable that renew process.

[emcniece]

I wonder if the --batch flag re-uses the common responses file, or if it uses data produced during certificate acquisition?

[Munsio]

https://hlandau.github.io/acme/userguide#response-files

It seems that the --batch command uses the default response file. I searched the code a little bit and din't see anything against that.

So we have 2 options in my opinion:

1. we search for another letsencrypt cert client
2. we create an issue where we address our problems with the current system and give them a solution how it could work (PR on acmetool)

[emcniece]

We do have a functioning product, let's not abandon it just yet. After MVP release we can explore this feature.

[mathuin]

@Munsio I do not agree with your interpretation of the documentation you cited above.

Here's what it says in the source code's documentation on response files found at https://github.com/hlandau/acme/blob/83d2466ceb01a76d281ff8983465db191fbfa1e2/_doc/response-file.yaml#L6

# You will typically want to use --response-file with --stdio or --batch.

Having a response file like this with a template blank for the value of "acme-enter-email" and defaulting to the supplied value if the container doesn't have a label looks pretty easy. You don't even have to store the response files anywhere, but you could create them and store them in /var/lib/acme/conf/responses/domain whenever the labels on that container change. Then it's a solved problem!

That being said, it's definitely worth waiting for MVP.