# INFO: Using main config file /etc/dehydrated/config
Dehydrated by Lukas Schauer
https://dehydrated.io
Dehydrated version: 0.7.2
GIT-Revision: unknown
OS: Arch Linux
Used software:
bash: 5.3.3(1)-release
curl: 8.16.0
awk: GNU Awk 5.3.2, API 4.0, PMA Avon 8-g1, (GNU MPFR 4.2.2, GNU MP 6.3.0)
sed: sed (GNU sed) 4.9
mktemp: mktemp (GNU coreutils) 9.8
grep: grep (GNU grep) 3.12-modified
diff: diff (GNU diffutils) 3.12
openssl: OpenSSL 3.6.0 1 Oct 2025 (Library: OpenSSL 3.6.0 1 Oct 2025)
# openssl x509 -checkend $((30 * 86400)) -in /etc/dehydrated/certs/<certificate>
Certificate will not expire
# echo $?
0
# openssl x509 -checkend $((30 * 86400)) -in /etc/dehydrated/certs/<certificate2>
Certificate will expire
# echo $?
0
Originally created by @TB1234 on GitHub (Oct 14, 2025).
Openssl checkend always ended with exit-code 0. So the if does not work, and a certificate is not renewed also when this is required.
The row that created this problem is:
```bash
if ("${OPENSSL}" x509 -checkend $((RENEW_DAYS * 86400)) -noout -in "${cert}" > /dev/null 2>&1); then
```
I replaced it with following one, but that's not translation safe:
```bash
if ("${OPENSSL}" x509 -checkend $((RENEW_DAYS * 86400)) -in "${cert}" 2>/dev/null | grep -q "will not expire"); then
```
So in my case it works.
```
# INFO: Using main config file /etc/dehydrated/config
Dehydrated by Lukas Schauer
https://dehydrated.io
Dehydrated version: 0.7.2
GIT-Revision: unknown
OS: Arch Linux
Used software:
bash: 5.3.3(1)-release
curl: 8.16.0
awk: GNU Awk 5.3.2, API 4.0, PMA Avon 8-g1, (GNU MPFR 4.2.2, GNU MP 6.3.0)
sed: sed (GNU sed) 4.9
mktemp: mktemp (GNU coreutils) 9.8
grep: grep (GNU grep) 3.12-modified
diff: diff (GNU diffutils) 3.12
openssl: OpenSSL 3.6.0 1 Oct 2025 (Library: OpenSSL 3.6.0 1 Oct 2025)
# openssl x509 -checkend $((30 * 86400)) -in /etc/dehydrated/certs/<certificate>
Certificate will not expire
# echo $?
0
# openssl x509 -checkend $((30 * 86400)) -in /etc/dehydrated/certs/<certificate2>
Certificate will expire
# echo $?
0
```
Either way I've decided to implement your suggested workaround in 1dbbc64ce9. I've traced the output in their code history and it seems that for the last 25 years the strings haven't changed and they also don't seem to be localized, so hopefully they don't introduce translations in their next release, or well.. I guess by then I could just revert this commit.
@lukas2511 commented on GitHub (Oct 24, 2025):
Thanks for reporting!
I first thought openssl might have once again silently changed some functionality, but this just seems to be a regression on their end: https://github.com/openssl/openssl/issues/28928
Either way I've decided to implement your suggested workaround in 1dbbc64ce947af000b764e806429e3f87cb3a55e. I've traced the output in their code history and it seems that for the last 25 years the strings haven't changed and they also don't seem to be localized, so hopefully they don't introduce translations in their next release, or well.. I guess by then I could just revert this commit.
As a courtesy, a heads up that I've submitted a PR which addresses the root cause so you can switch back to relying on the return code rather than the printed string. https://github.com/openssl/openssl/pull/29155
@snowdroppe commented on GitHub (Nov 16, 2025):
As a courtesy, a heads up that I've submitted a PR which addresses the root cause so you can switch back to relying on the return code rather than the printed string. https://github.com/openssl/openssl/pull/29155
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @TB1234 on GitHub (Oct 14, 2025).
Openssl checkend always ended with exit-code 0. So the if does not work, and a certificate is not renewed also when this is required.
The row that created this problem is:
I replaced it with following one, but that's not translation safe:
So in my case it works.
@lukas2511 commented on GitHub (Oct 24, 2025):
Thanks for reporting!
I first thought openssl might have once again silently changed some functionality, but this just seems to be a regression on their end: https://github.com/openssl/openssl/issues/28928
Either way I've decided to implement your suggested workaround in
1dbbc64ce9. I've traced the output in their code history and it seems that for the last 25 years the strings haven't changed and they also don't seem to be localized, so hopefully they don't introduce translations in their next release, or well.. I guess by then I could just revert this commit.@snowdroppe commented on GitHub (Nov 16, 2025):
As a courtesy, a heads up that I've submitted a PR which addresses the root cause so you can switch back to relying on the return code rather than the printed string. https://github.com/openssl/openssl/pull/29155