dehydrated issues certificate chains leading to expired root

[minfrin]

Letsencrypt's root expired on 21 September:

https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/

I have discovered a machine that is having letsencrypt certs be renewed, but the chain provided by dehydrated is providing the old cert chain that points at the expired cert.

Systems using old openssl (CentOS7 and below) then break in all sorts of ways.

To fix this, make sure the chain doesn't lead to an expired cert.

[jobe1986]

The chain is supplied by Let's Encrypt not dehydrated. dehydrated simply downloads the default chain Let's Encrypt supplies.

You can select the alternative (short) chain using PREFERRED_CHAIN="ISRG Root X1" in your config file

[AgentOak]

This is the expected behavior as per Lets Encrypt's own documentation, and the very article you linked explains why.

[minfrin]

The chain is supplied by Let's Encrypt not dehydrated. dehydrated simply downloads the default chain Let's Encrypt supplies.

You can select the alternative (short) chain using PREFERRED_CHAIN="ISRG Root X1" in your config file

Alas, no luck.

[root@chestnut ~]# dehydrated -x -c
# INFO: Using main config file /etc/dehydrated/config
# INFO: Using additional config file /etc/dehydrated/conf.d/local.sh
Processing redwax.eu
 + Checking domain name(s) of existing cert... unchanged.
 + Checking expire date of existing cert...
 + Valid till Feb  5 07:35:21 2022 GMT (Longer than 30 days). Ignoring because renew was forced!
 + Signing domains...
 + Generating signing request...
 + Requesting new certificate order from CA...
 + Received 1 authorizations URLs from the CA
 + Handling authorization for redwax.eu
 + 1 pending challenge(s)
 + Deploying challenge tokens...
 + Responding to challenge for redwax.eu authorization...
 + Challenge is valid!
 + Cleaning challenge tokens...
 + Requesting certificate...
ERROR: Alternative chain with CN = ISRG Root X1 not found, available options: issuer= /O=Digital Signature Trust Co./CN=DST Root CA X3, issuer= /C=US/O=Internet Security Research Group/CN=ISRG Root X1

Unfortunately the error message doesn't contain quotes around the values, so it's not clear where the values start and end, or whether they include the "issuer=".

[lukas2511]

I'm guessing you are on the latest release-version of dehydrated? Can you please check if the latest version from master branch works for you? There already should be a fix for the CN extraction (29b67962ac07d5d2b24f69c863a9ef31e8ac53ee).

Other than that what others already reported is correct, dehydrated doesn't generate or actively selects the chain. It uses the default chain pushed by the CA unless given instructions to use a different one.

[mnik247]

The chain is supplied by Let's Encrypt not dehydrated. dehydrated simply downloads the default chain Let's Encrypt supplies. You can select the alternative (short) chain using PREFERRED_CHAIN="ISRG Root X1" in your config file

Alas, no luck.

[root@chestnut ~]# dehydrated -x -c
# INFO: Using main config file /etc/dehydrated/config
# INFO: Using additional config file /etc/dehydrated/conf.d/local.sh
Processing redwax.eu
 + Checking domain name(s) of existing cert... unchanged.
 + Checking expire date of existing cert...
 + Valid till Feb  5 07:35:21 2022 GMT (Longer than 30 days). Ignoring because renew was forced!
 + Signing domains...
 + Generating signing request...
 + Requesting new certificate order from CA...
 + Received 1 authorizations URLs from the CA
 + Handling authorization for redwax.eu
 + 1 pending challenge(s)
 + Deploying challenge tokens...
 + Responding to challenge for redwax.eu authorization...
 + Challenge is valid!
 + Cleaning challenge tokens...
 + Requesting certificate...
ERROR: Alternative chain with CN = ISRG Root X1 not found, available options: issuer= /O=Digital Signature Trust Co./CN=DST Root CA X3, issuer= /C=US/O=Internet Security Research Group/CN=ISRG Root X1

Unfortunately the error message doesn't contain quotes around the values, so it's not clear where the values start and end, or whether they include the "issuer=".

or try PREFERRED_CHAIN="issuer= /C=US/O=Internet Security Research Group/CN=ISRG Root X1"

[loopiv]

Just wanted to add another data point. On CentOS 7 (EL7) systems with dehydrated version 0.7.0 (release-version), I need to use the long version of the chain. On Oracle Linux 8 (EL8) with same dehydrated version, I need to use the short preferred chain string.

Kind of related - any chance of a new release version soon(ish)? In our environment, we usually need to use released versions. That may help with the above for consistency.

[sigprof]

Apparently dehydrated version 0.7.1 had been released, and it fixes this problem on CentOS 7 (PREFERRED_CHAIN="ISRG Root X1" works, while it did not with dehydrated 0.7.0); there is even a new enough dehydrated-0.7.1-1.el7 package in EPEL. So I suppose that this issue can be closed as fixed.