--always-force-new-domain-key should pre-generate the future domain key pair

[Delicates]

--always-force-new-domain-key should pre-generate the future (next) domain key pair after the new certificate is provisioned, so that --reloadcmd can update TLSA records in advance of obtaining future certificates as part of the Current + Next DANE roll-over procedure.
Pre-generated keys (if they exist) should be used for all future --always-force-new-domain-key certificate provisioning.

Key rotation requires future planning for DANE TLSA roll-over to account for DNS propagation delays and TLSA records TTL.

See slides 20-21 from the 2018 ICANN61 presentation by Viktor Dukhovni.

The Current + Next DANE roll-over procedure is:

• Generate next key when deploying current key and cert
• Deploy new chain, and publish new TLSA records:

    _25._tcp.mx.example.com. IN TLSA 3 1 1 curr-pubkey-sha256
    _25._tcp.mx.example.com. IN TLSA 3 1 1 next-pubkey-sha256

• Weeks later, obtain certificate for pre-generated next key
• But first, make sure TLSA record is already in place
• Repeat!

[Delicates]

Please note, with DNS-01 challenge, it also would be fairly trivial for acme.sh to implement the DANE roll-over procedure and manage shared trust anchor TLSA records itself via the already configured DNS API interface.

acme.sh could maintain Current + Next shared trust anchor TLSA records (user configurable), e.g. tlsa._dane.example.net. as per the example in Section 5.1 of RFC 7671.

All that sysadmins would have to do for different TLS servers that use the acme.sh provided certificate is set up CNAMEs pointing to the shared trust anchor TLSA record that acme.sh maintains.

This would be a nice-to-have cherry on top, leveraging all the work that has gone into acme.sh DNS API integrations, saving sysadmins from having to figure out how to work their corresponding DNS API themselves with --reloadcmd and supporting/promoting/automating best practice that improves security of the Internet ecosystem overall.

But the key to this all is to start pre-generating future keys in the first place.
Without it can't do Current + Next roll-over even with --reloadcmd.

[Neilpang]

But the key to this all is to start pre-generating future keys in the first place.

The pre-generating is ok, but all the current dns api hooks are just to add/remove TXT record, they are not able to process TLSA record.

[Neilpang]

please try with the tlsa branch.

acme.sh  --upgrade -b tlsa

There is a new env variable Le_Pre_Generated_Key when reloadcmd is run.

Let me know if this is what you want.

[Delicates]

Thanks @Neilpang

I've tested it out and the general gist of it works, but needs some minor polish.

Please see attached the patch with the following minor polish updates:

• _info and _err messages clean up.
• Changed pre-generated key filename from *.key.prekey to *.next.key.
• Replaced $Le_Pre_Generated_Key with $NEXT_KEY_PATH.
• Exported NEXT_KEY_PATH also when running post hook and renew hook.
• Added new info message: Your pre-generated next key for future cert key change is in.
• Preserved permissions of the pre-generated key file if it exists by not removing it.

I've tested it successfully with a reloadcmd script along these lines:

# DANE-EE SPKI SHA2-512 (TLSA 3 1 2) hash generation
TLSA312_CURRENT=$(openssl pkey -in "$CERT_KEY_PATH" -pubout -outform DER 2>/dev/null | sha512sum | cut -f1 -d ' ')
TLSA312_NEXT=$(openssl pkey -in "$NEXT_KEY_PATH" -pubout -outform DER 2>/dev/null | sha512sum | cut -f1 -d ' ')

cat << EOF | nsupdate -k /path/nsupdate.key
update del tlsa._dane.$Le_Domain 60 TLSA
update add tlsa._dane.$Le_Domain 60 TLSA 3 1 2 $TLSA312_CURRENT
update add tlsa._dane.$Le_Domain 60 TLSA 3 1 2 $TLSA312_NEXT
send
EOF

I've also identified some major security issues throughout existing code and raised a separate issue #3127 for it, which also affects this code - so you might want to use this branch for fixing them as well.

Outstanding
A bit of further work is required to fix the unlikely but possible issue with the below code in line with how you decide to fix issue #3127:
cat "$NEXT_KEY_PATH" >"$CERT_KEY_PATH"

acme-tlsa.diff.txt

[Delicates]

Also would be good to export CERT_KEY_PATH and NEXT_KEY_PATH for all different hooks (not just post and renew) and also for all hook calls.

The hooks could do validation of TLSA records against:

• current certificate key
• pre-generated next key
• installed certificates

to make sure nothing got broken during/after acme.sh execution.

Example use case - it would be useful prior to generating a new certificate to run a pre-hook to check if a TLSA record matching the pre-generated next key already exists. If it doesn't exist, the pre-hook could:

• Add missing TLSA record so it is there the next time acme.sh is run.
• Abort new certificate generation to avoid service outage while DNS syncs up the missing entries.
• Send a notification email to sysadmins.

Similarly deployment hook can be used to validate that everything is as it should be and nothing got broken.

I didn't look at all of them until now, and raised a new issue #3128 about hook variables passing inconsistency that needs to be fixed.

[Delicates]

After some further testing - there's an issue.

The key files get rotated even when cert issuance fails.
This would lead to loss of the previously generated key that has been advertised in TLSA, which in turn would lead to an outage when the cert finally does succeed in being generated, until old TLSA record TTL expires and new TLSA records get propagated by DNS.

The pre-generation of new key should be happening after a successful cert issuance.
If cert issuance fails - the old pre-generated key file should be left untouched for the next attempt.

[Eagle3386]

@Delicates I'm not that good at shell scripting/programming, so not capable of doing this myself, yet eagerly waiting to automate TLSA generation/population, too. 😅
So, may I ask if you could achieve any progress since your last comment?

[rdemendoza]

@Neilpang Really nice feature, do you plan to merge it into the master branch?

[Neilpang]

@rdemendoza I need more time to check it.

[Eagle3386]

@Neilpang Almost 1 year later - do you see any chance of getting that "more time to check it" within the next couple of weeks or at least months?
I'm really looking forward to switch from TLSA with 2-1-1 to TLSA's with 3-1-1 without custom post-LE-approval scripting on my box... 😉

[damousys]

I have also updated to the TLSA branche.
Run a --force to renew my cert, but didn't get a TLSA record.
Do I have to do something extra besides running this command ?

"/root/.acme.sh"/acme.sh --cron --home "/root/.acme.sh" --force

[redglobuli]

maybe something could be achieved with this new tool https://letsdns.org/index.html, could be called within a hook.

[Neilpang]

Sorry guys, I will check it soon.