Handling of CA account private keys #36

New Issue

2025-12-29T00:22:59+01:00

adam commented

2025-12-29 00:22:59 +01:00

Originally created by @danb35 on GitHub (Jan 18, 2016).

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:

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.
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.

Originally created by @danb35 on GitHub (Jan 18, 2016). 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.

adam added the enhancement help wanted labels 2025-12-29 00:22:59 +01:00

adam closed this issue

2025-12-29 00:22:59 +01:00

adam commented

2025-12-29 00:23:00 +01:00

@lukas2511 commented on GitHub (Jan 18, 2016):

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...

@lukas2511 commented on GitHub (Jan 18, 2016): 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...

adam commented

2025-12-29 00:23:01 +01:00

@nneul commented on GitHub (Jan 22, 2016):

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.

@nneul commented on GitHub (Jan 22, 2016): 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.

adam commented

2025-12-29 00:23:01 +01:00

@qaxi commented on GitHub (May 12, 2016):

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.

@qaxi commented on GitHub (May 12, 2016): 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.

adam commented

2025-12-29 00:23:01 +01:00

@phloggu commented on GitHub (May 21, 2016):

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

@phloggu commented on GitHub (May 21, 2016): If you don't want to change path, set up softlinks instead.

adam commented

2025-12-29 00:23:01 +01:00

@michielbdejong commented on GitHub (Jun 1, 2016):

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 commented on GitHub (Jun 1, 2016): 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?

adam commented

2025-12-29 00:23:02 +01:00

@michielbdejong commented on GitHub (Jun 1, 2016):

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

@michielbdejong commented on GitHub (Jun 1, 2016): Or another option: add the CA URL into `private_key.json`, and give a meaningful error message when a mismatch is detected.

adam referenced this issue

2025-12-29 01:28:24 +01:00

[PR #36] [CLOSED] Hook for deploying certs via ssh #676

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/dehydrated#36