Accounts vs. domains vs. centralization


#1

Hello all,
I really like letsencrypt. I am using it for all my sites now…
I run many small web sites on a Banana Pro running 24/7, some other services on other servers. As the service split may change over time and also there is no good backup for the Banana, I try to avoid having critical data on the Banana. Instead I moved certificate management to another host and download the certificates to the Banana and other hosts (not yet automated, but close). The Banana runs a reverse proxy nginx which forwards any http request to /.well… to the host running letsencrypt, any other http request redirects to https, and there are plenty of other https servers then served from a local copy of data or proxied to other backends on my network. Working nicely, automation to be done.
Now I am also planning to run a site I for a domain I don´t really own - oh yes on the same Banana. I´d like to use a different account for that in order to be able to hand that over in case I am no longer the tech guy. Is that possible with one client setup? How do I specify the account/email when requesting a certificate initially? Does letsencrypt remember the association of domain and account when renewing? Or do I have to create another (virtual) host to run the other account/domains?
Thanks & Best regards, Joachim


#2

I tested myself, at least for initial issuing and renewing specifc certificates (i.e. letsencrypt certonly -d domain, not letsencrypt renew). Initially I moved around the directories in accounts, also forcing letsencrypt to create another one, but after that inital “tricking” it turns out to be unnecessary. When multiple accounts are available, letsencrypt prompts which one to use. Nice. I assume this is then automatic in renew, but I am not at this point yet (I tried renew once, but it renewed not the oldest ones - will check this out starting next month or so).


#3

I tested renew today, and unfortunately renew prompts for the account even though afai understand the account reference is part of the renew information. I would appreciate if the renew command would leverage that - otherwise automation will be a challenge and it looks like I´d have to setup distinct VMs for the two accounts.
Or am I missing something?


#4

@jol, I think what you’re seeing is a bug – can you let us know what client version you’re using, what command you’re running, and what the relevant renewal configuration file says?


#5

Sorry for getting back late - also working on other stuff…
As I wrote I am running letsencypt on a VM which happens to be on CentOS. The CentOS repositories include a letsencrypt package, thus I opted to use that instead of a different install mechanism. letsencrypt --version reports 0.4.1, after a yum update I just did it was 0.4.2. Don´t know how fast these repositories pick up changes by letsencrypt, but I do see value in having just one update mechanism for all software.

One of the last domain I renewed now (after the renewal) has the following renewal configuration (personal data replaced - if that should be relevant pls let me know and I will pass that privately):

cert = /etc/letsencrypt/live/mydomain/cert.pem
privkey = /etc/letsencrypt/live/mydomain/privkey.pem
chain = /etc/letsencrypt/live/mydomain/chain.pem
fullchain = /etc/letsencrypt/live/mydomain/fullchain.pem

# Options and defaults used in the renewal process
[renewalparams]
no_self_upgrade = False
no_verify_ssl = False
ifaces = None
register_unsafely_without_email = False
uir = None
installer = none
config_dir = /etc/letsencrypt
text_mode = True
staging = False
dry_run = False
work_dir = /var/lib/letsencrypt
tos = False
duplicate = False
http01_port = 80
init = False
noninteractive_mode = False
key_path = None
fullchain_path = None
email = myemail
csr = None
agree_dev_preview = None
redirect = None
verbose_count = -3
config_file = None
renew_by_default = False
hsts = False
authenticator = webroot
nginx = False
rsa_key_size = 4096
verb = renew
checkpoints = 1
manual_test_mode = False
apache = False
cert_path = None
webroot_path = /etc/letsencrypt/webroot,
reinstall = False
expand = False
strict_permissions = False
account = oneofmyaccounts
prepare = False
manual_public_ip_logging_ok = False
chain_path = None
break_my_certs = False
domains = mydomain,
standalone = False
manual = False
server = https://acme-v01.api.letsencrypt.org/directory
standalone_supported_challenges = "tls-sni-01,http-01"
webroot = False
os_packages_only = False
func = <function renew at 0x3568410>
user_agent = None
debug = False
tls_sni_01_port = 443
logs_dir = /var/log/letsencrypt
configurator = None
[[webroot_map]]
mydomain = /etc/letsencrypt/webroot


#6

Can you verify that you have the following files inside your /etc/letsencrypt/accounts/acme-v01.api.letsencrypt.org/directory/<exact value of the account option in your renewal file>/ directory?

  • meta.json
  • private_key.json
  • regr.json

I’m mentioning this because you said you might have moved around some files or directories in there.


#7

I verified that all my renewal files contain a line account = with an account that actually exists and also the .json files exist for both accounts. I also was always able to renew after picking the correct account, only that that prompt appears to be unnecessary and prevents automation.


#8

Via the standard package sources of CentOS I got letsencrypt updated to 0.5 now, but the superfluous prompt for the account is still there.


#9

I migrated my letsencrypt installation to ARMBIAN Ubuntu 16.04.1 LTS 4.8.4-sunxi and also am using letsencrypt from standard package sources of that installation. Letsencrypt --version reports 0.4.1 - and exhibits the same issue as described above.
I am wondering whether we can work to gether to fix that issue or whether I need to separate my two accounts into at least different directories or different hosts.