Provide a parameter to externally set the ACME account ID

[Eagle3386]

Scenario:
For years, you're using some other service on some other system to issue/renew certs via ACME account ID 1234 just fine.

Then, you start using Home Assistant which offers its own "app" (basically another docker container, run in parallel to its main container) to issue/renew LE certs - which is nothing but an adapted cert-multi-dns instance which in turn uses lego which in turn creates its own files & folder structure as perfectly described here (just klick on tree).
Upon first launch, lego, if it determines that there's no ACME account stored yet, creates the required ACME account & uses that ACME account ID from then on until forever.

Problem:
This scenario leaves any user with two ACME accounts instead of one. Especially, because due to the nature of containers, there's no access to internal files, so the ACME account ID can't be changed.

Proposal:
Provide a parameter, e.g., --account.id, which, if provided, overrides the current account ID read from lego's internal config files & instead stores that ID for future actions.

[ldez]

Your explanation is still not clear because you are focused on a possible solution instead of the detailed description of the problem.

Note: 2 containers can share files by mounting a volume.

[Eagle3386]

1. Yes.
2. No. 1 container with HA, 1 with the "letsencrypt app" that runs cert-multi-dns which in turn calls lego (in that very same, 2nd, container)
3. No. All stored in 2nd container, but modification is useless as it's overwritten upon next launch (the "app" applies its own configuration - which doesn't offer such an account override either, but I can't push for its implementation as long as lego doesn't support such override.
4. No. I want to use the same account on 2 completely different systems: 1 is a Synology NAS running ACME.sh, 1 is a Home Assistant Yellow running their "letsencrypt app" as described in 2.
5. Yes, as that's what I understood from looking at the ACME protocols URL calls.

Let's Encrypt themselves told me that do not store email addresses anymore. In fact, there's no linkage between any email address and a user's ACME account ID (on their server(s) & in their database(s)).

[ldez]

Yes, as that's what I understood from looking at the ACME protocols URL calls.

But this is wrong: without the account private key, you can do nothing.

The usage of the account private key is everywhere inside the RFC, because this is required to sign all the requests.

Let's Encrypt themselves told me that do not store email addresses anymore. In fact, there's no linkage between any email address and a user's ACME account ID (on their server(s) & in their database(s)).

I never say that the email is used by the server: I said this email is used to name the directory used to store the private key, and metadata.
This is not the same thing.

Even when you don't provide an email, lego uses the placeholder noemail@example.com (not send to the server).

So, if you are using the same ACME server and the same email, the account will be stored in the same folder, and so be reusable.

I want to use the same account on 2 completely different systems: 1 is a Synology NAS running ACME.sh, 1 is a Home Assistant Yellow running their "letsencrypt app" as described in 2.

My understanding is that you want to reuse the account created by acme.sh with lego.

IMHO, it can be easier to use the same tool in the two places, but anyway.

The only way to do that is to provide, at least, the account private key.

[Eagle3386]

But this is wrong: without the account private key, you can do nothing.
The usage of private key is everywhere inside the RFC, because this is required to sign all the requests.

I see. Thanks for the clarification!

I never say that the email is used by the server: I said this email is used to name the directory used to store the private key, and metadata. This is not the same thing.
Even when you don't provide an email, lego uses the placeholder noemail@example.com (not send to the server).
So, if you are using the same ACME server and the same email, the account will be stored in the same folder, and so be reusable.

Again: I see. Thanks for the clarification!

My understanding is that you want to reuse the account created by acme.sh with lego.

Yes. But not because "I want", but because I need to as that's the older account containing all other domains.

IMHO, it can be easier to use the same tool in the two places, but anyway.

Yes. Absolutely! But I couldn't install what's necessary to run a Go environment on the Synology NAS. 😔
So, believe me: as soon as memory prices are back to "normal" (late last year, I bought 2x 32 GB for 240 € which they now sell for 860 €..), the long-planned DIY NAS will be built & the very first LXC container that ProxMox will run is a dedicated one for lego as the single point of everything related to cert issuance/renewal.

The only way to do that is to provide, at least, the account private key.

I can extract that from the ACME.sh system, no problem. But then again: how to use it with lego so that it overrides whatever is there right now & permanently stores the new private key?
Preferably, this should be done as Base64 as a one-liner instead of the usual multi-line format so that it can be passed as CLI argument instead of a file as HA / cert-multi-dns probably won't support a file-based approach for this..

[ldez]

Yes. Absolutely! But I couldn't install what's necessary to run a Go environment on the Synology NAS.

You don't need to do that: we provide binaries, Docker images, and lego is already packaged by most of package managers.

https://go-acme.github.io/lego/installation/index.html

---

If I should describe a workflow to do what I understand of your goal.

1. Create an account (acme.sh or lego)
2. Recover the account with lego by using the previously created private key and the right "email" (local account ID).
3. The recovery will create the right file structure for the account.
4. Run lego with the right "email" (local account ID).
5. The ACME process will use the same account.

With lego v4, the only way to recover an account is:

• to use the run command (the renew command will not work in this case)
• have the account private key and an empty file metadata in the right place.

The run command will gets the account file metadata, it will detect that the "registration" is missing, it will read the account private key, ask to the server the account information.
The account will be "recovered" and used for the challenges.

But, as mounting a volume doesn't seems to be solution for you, I have no solution with lego v4.

Even with lego v5, without a modification of the way HomeAssistant is using lego, I don't see a proper solution.

[ldez]

I checked how certbot-dns-multi is working, and it doesn't use lego "the binary" but lego "the library" to use it with certbot.

This is a Python binding for the lib: https://github.com/alexzorin/certbot-dns-multi/blob/main/certbot_dns_multi/_internal/bridge/main.go

This is major difference because the account is not managed by lego but by certbot.

And I don't know how certbot works.