certbot

20 Commits 1 Branch 0 Tags

2 Commits

Author	SHA1	Message	Date
bitdeals	e8204bbb4d	fix: the certificate follows CERTBOT_DOMAIN, on every pass A pass branched on whether /etc/letsencrypt/live/<first-name> existed: present, it ran `certbot renew`; absent, it handed over to the creation script. Only the second path was ever told the names to ask for, so after the first issuance CERTBOT_DOMAIN stopped reaching certbot altogether -- renew takes the names off the certificate it already holds. Editing the variable did nothing, silently, and the README documented the manual issuance needed to work around it. The branch is gone. Every pass now runs certonly with the names spelled out, and certbot decides what that means: same names, not due -> "Certificate not yet due for renewal; no action taken", no connection opened, nothing spent against the rate limits name added or removed -> reissued with exactly the requested set due for renewal -> renewed --keep-until-expiring is what makes the first line true, and --cert-name (already passed) is what keeps a changed list updating the existing lineage instead of starting a second one beside it. No --expand is needed to add a name once the lineage is named. All three decisions were checked against the live stands: the no-op one with a real run on testnet2, the other two as dry runs on testnet1 and testnet2. With the branch removed, 1-renew-cert.sh is a pass-through and the numbering finally matches the order things run in -- 0-create-cert.sh used to execute after 1-renew-cert.sh. So: 1-renew-cert.sh deleted, 0-create-cert.sh renamed to 1-ensure-cert.sh, which is what it now does. Claude-Session: https://claude.ai/code/session_01BvgYcYPWd1KGABLKViVPSk	2026-08-24 13:13:03 +00:00
bitdeals	36e1865e37	feat: CERTBOT_DOMAIN may name several domains Build docker image and push to registry.bitdeals.org / main-build-job (push) Successful in 30s Details certbot's own -d already takes a comma-separated list and puts every name in the certificate's Subject Alternative Names, so `-d "$CERTBOT_DOMAIN"` needed no change at all. What assumed a single domain was everything that treated the variable as a file name: --cert-name, and the two scripts that address the lineage under /etc/letsencrypt/live. Certbot names a lineage after the first domain of the list, so all three now take ${CERTBOT_DOMAIN%%,*} instead of the whole string -- otherwise a two-domain value asks for a lineage literally called "a.org,b.org" and the renewal pass looks for a directory nobody made. One certificate with several names rather than several lineages: HAProxy binds a single site.pem, and a second lineage would have nowhere to go. Adding a domain to CERTBOT_DOMAIN on a machine that already holds a certificate still needs one manual issuance -- `certbot renew` reads the names off the certificate it has and never looks at the variable. The README says so, and gives the command.	2026-08-20 11:53:12 +00:00

Author

SHA1

Message

Date

bitdeals

e8204bbb4d

fix: the certificate follows CERTBOT_DOMAIN, on every pass

A pass branched on whether /etc/letsencrypt/live/<first-name> existed:
present, it ran `certbot renew`; absent, it handed over to the creation
script. Only the second path was ever told the names to ask for, so
after the first issuance CERTBOT_DOMAIN stopped reaching certbot
altogether -- renew takes the names off the certificate it already holds.
Editing the variable did nothing, silently, and the README documented the
manual issuance needed to work around it.

The branch is gone. Every pass now runs certonly with the names spelled
out, and certbot decides what that means:

  same names, not due    -> "Certificate not yet due for renewal; no
                            action taken", no connection opened, nothing
                            spent against the rate limits
  name added or removed  -> reissued with exactly the requested set
  due for renewal        -> renewed

--keep-until-expiring is what makes the first line true, and --cert-name
(already passed) is what keeps a changed list updating the existing
lineage instead of starting a second one beside it. No --expand is
needed to add a name once the lineage is named.

All three decisions were checked against the live stands: the no-op one
with a real run on testnet2, the other two as dry runs on testnet1 and
testnet2.

With the branch removed, 1-renew-cert.sh is a pass-through and the
numbering finally matches the order things run in -- 0-create-cert.sh
used to execute after 1-renew-cert.sh. So: 1-renew-cert.sh deleted,
0-create-cert.sh renamed to 1-ensure-cert.sh, which is what it now does.

Claude-Session: https://claude.ai/code/session_01BvgYcYPWd1KGABLKViVPSk

2026-08-24 13:13:03 +00:00

bitdeals

36e1865e37

feat: CERTBOT_DOMAIN may name several domains

Build docker image and push to registry.bitdeals.org / main-build-job (push) Successful in 30s

Details

certbot's own -d already takes a comma-separated list and puts every name
in the certificate's Subject Alternative Names, so `-d "$CERTBOT_DOMAIN"`
needed no change at all. What assumed a single domain was everything that
treated the variable as a *file name*: --cert-name, and the two scripts
that address the lineage under /etc/letsencrypt/live. Certbot names a
lineage after the first domain of the list, so all three now take
${CERTBOT_DOMAIN%%,*} instead of the whole string -- otherwise a two-domain
value asks for a lineage literally called "a.org,b.org" and the renewal
pass looks for a directory nobody made.

One certificate with several names rather than several lineages: HAProxy
binds a single site.pem, and a second lineage would have nowhere to go.

Adding a domain to CERTBOT_DOMAIN on a machine that already holds a
certificate still needs one manual issuance -- `certbot renew` reads the
names off the certificate it has and never looks at the variable. The
README says so, and gives the command.

2026-08-20 11:53:12 +00:00