Old

I'll put the link to the new repo here. This repo then will be archived.

This here is based on the ACMEv1 variant of dehydrated.

• In 2019-10 it stopped working for new accounts.
• In 2020-06 it will stop working for new domains on existing accounts.
• In 2021-06 it will stop working for existing domains.

Hence I need to replace it. Currently I have no idea of the outcome.

But I have no plan to update this here from upstream, as reviewing it is probably as much work as creating my own variant out of something else. Hence this here is considered EOL, do not use!

LetsEncrypt lists shell based ACMEv2 alternatives:

• 2603 lines getssl
• 7111 lines acme.sh
• 1802 lines dehydrated.sh
• 1078 lines letsencrypt.sh
• 0435 lines bacme no DNS, no account-reuse

My requirements:

• Must be reliable
• DRY (Don't Repeat Yourself)
• Must be reliable
• KISS (Keep it stupid simple)
• Must be reliable
• ACMEv2
• Must be reliable
• Secure (never run on the web service host itself!)
• Must be reliable
• Support for redundant machines (deploy to moving fleets of machines)
• Must be reliable
• Some machines may be down while while issuing/updating certificates
• Must be reliable
• Wildcards (hence DNS validation)
• Must be reliable
• Configurable
• Must be reliable
• Re-use account information
• Must be reliable
• As few (readable!) lines as possible
• Must be reliable

Following path is likely:

Step 1: Replace dehydrated with a workaround

• Start out with a copy of the most simple client found (bacme) to replace this here.
• Hack it to continue to use the existing account.
• Attach it to the existing deployment scripts
• This will give me something which works as today, but uses ACMEv2, with a much simpler code base.
• This probably will be done on demand as soon as I need a Domain not yet present

Step 2: Extend it to Wildcards

• Whatever is needed for this is probably taken out of some other of the scripts found out there
• This probably will be done on demand as soon as I need a Wildcard Domain
• I currently have no idea how to support DNS validation, as my DNS is based on very static zone files

Step 3: Add account creation plus revoking

• As this is probably important
• This probably will be needed as soon as Disaster Recovery Documentation is updated on how to revoke Certs

Step 4: Remove traces of other code

• This stops including other code fragments, so it becomes a single file
• This also refactors the code to make it more simple
• This then is WiP for the future

Notes:

• "readable" means readable for me, not for you
• "KISS" means easy for me, not for you
• "DRY" means ultra-dry. 2 similar lines are ok. 3 similar lines or 2 equal lines are a definitive no-go
• "secure" means not "protecting itself" but "not requiring any security holes anywhere"
• "secure" means it can be run in a DMZ or Intranet
• "secure" means no dangerous code
• "secure" means no dangerous operations
• "configurable" means very easy configuration, best: for each single thing there is a single configuration file plus a directory to split such a config into it's disjunct administrative parts if needed.
• "configurable" means that configuration can be kept in a separate git repository
• "configurable" means that it can be adapted to new needs easily
• "redundant" you must be able to restart from scratch on a new machine without losing anything
• "redundant" also means, that some machines to update might be down
• "down" means, that renew must work if a single service machine is up, running and reachable