Handling of CA account private keys

[danb35]

I'm seeing a bit of an issue with the handling of account private keys when switching from one CA to another. The process goes something like this:

• Download letsencrypt.sh
• Create config.sh, setting CA to https://acme-staging.api.letsencrypt.org/directory, and otherwise configuring as desired
• Run letsencrypt.sh -c
• It runs, notes no account, creates a private key, registers an account with the staging CA, and otherwise does its thing
• (optionally) user makes tweaks to config, re-running letsencrypt.sh until results are as desired
• User changes CA to https://acme-v01.api.letsencrypt.org/directory and runs letsencrypt.sh to generate "official" certs
• Script errors out with {"type":"urn:acme:error:unauthorized","detail":"No registration exists matching provided key","status":403}

The user can, of course, delete or rename the private_key.pem file, and then the script will run fine. I'd suggest, though, one of two ways of handling this in the script:

1. Rather than putting the private key in $BASEDIR/private_key.pem, put it in $BASEDIR/accounts/$CA_HOSTNAME/private_key.pem. When the user changes to a different CA, the script will see that there's no key, create a new one, and register it.
2. If the script gets this error from the CA, rename private_key.pem to something else, create a new one, and make a new registration.

I think (1) is the better option of the two, but either would avoid this.

[lukas2511]

yea... i know... i kinda hate changing paths now, as it has been like this for quite some time... but i guess something has to be done...

[nneul]

Why not go hybrid
Use the private key as provided - but if there isn't one already present in $BASEDIR/accounts/$CA_HOSTNAME/private_key.pem - copy the base one to it after attempting registration.

[qaxi]

Changing paths ... it can really be painful.
It opens way to other CAs but it's "big" change.
On the other hand, how many CAs you know to support this kind of cert handling ...
My idea is: add --testCA parameter
It has two positives

• relatively easy - changing CA, ACCOUNT_KEY and ACCOUNT_KEY_JSON to "testing" values
• it can be used for initial testing of full process (mainly correct WELLKNOWN and hooks) in user environment

If you like it, will do it and then send you pull request to let you see if it's OK for you.

[phloggu]

If you don't want to change path, set up softlinks instead.

[michielbdejong]

Would it be an idea to store the key in ./private_key-$HASH_OF_CA_URL.pem and then use ls private_key*.pem to see which private keys are available?

[michielbdejong]

Or another option: add the CA URL into private_key.json, and give a meaningful error message when a mismatch is detected.