Я вроде очень понятный пример привел выше, и обратил внимание, что это на версиях openssl < 1.0.2
Если он есть:
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT
Если его нет, то обработка дальше не идет:
verify error:num=20:unable to get local issuer certificate
SagePtr, итого, самое простое решение для старых систем:
Workaround 0 (on clients with OpenSSL >=0.9.8m)
Modify the "notAfter" date in the expired root certificate (DST Root CA X3) from "Sep 30 14:01:15 2021 GMT" to "Sep 30 18:14:03 2024 GMT" (which is when the new DST->ISRG cross-certificate is due to expire - see [3] and [4]); then, in the OpenSSL-based client application's trust store, replace the expired root certificate with the modified version. Here's one way to create the modified certificate:
cd /etc/pki/ca-trust/source/anchors/
wget -O DSTRootCAX3_Extended.crt "https://crt.sh/?d=8395"
sed -i "s/xMDkzMDE0MDExNVow/0MDkzMDE4MTQwM1ow/g" DSTRootCAX3_Extended.crt
update-ca-trust
Why does this work?
Modifying the expired root certificate obviously invalidates its self-signed signature. However, OpenSSL 0.9.8m and above don't check self-signed signatures by default (due to [5]), which is one factor in why this workaround works (whereas 0.9.8l and below do check self-signed signatures). The other factor is that OpenSSL treats the modified certificate as a root certificate, because the Issuer and Subject Names are identical; since it's not treated as an intermediate certificate, older versions of OpenSSL are able to treat it as a trust anchor even though they lack the "partial chains" functionality that was added in 1.0.2 (see [6]).
It is not necessary to add the new ISRG Root X1 self-signed certificate to the client's trust store for Workaround 0 to work. Note however that Workaround 0 won't work beyond Sep 30 18:14:03 2024 GMT.
SagePtr, по причине разного механизма обработки цепочек сертификатов. Если OpenSSL < 1.0.2 и есть протухший серт в цепочке, то верификация не проходит. Вот пример:
ISRG Root X1 - есть
DST Root CA X3 - нет
[root@sandbox /]# awk -v cmd='openssl x509 -noout -subject' ' /BEGIN/{close(cmd)};{print | cmd}' < /etc/ssl/cert.pem | grep -E "ISRG|DST Root CA X3"
subject= /C=US/O=Internet Security Research Group/CN=ISRG Root X2
subject= /C=US/O=Internet Security Research Group/CN=ISRG Root X1
[root@sandbox /]# /usr/bin/openssl version
OpenSSL 1.0.1e-fips 11 Feb 2013
[root@sandbox /]# /usr/bin/openssl s_client -servername ssltest.${myhost} -connect ssltest.${myhost}:443 -CAfile /etc/ssl/cert.pem
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
0 s:/CN=*.${myhost}
i:/C=US/O=Let's Encrypt/CN=R3
1 s:/C=US/O=Let's Encrypt/CN=R3
i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
2 s:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
i:/O=Digital Signature Trust Co./CN=DST Root CA X3
И теперь с openssl собранным руками:
[root@sandbox /]# /opt/local/bin/openssl version
OpenSSL 1.0.2k-fips 26 Jan 2017
[root@sanbox /]# /opt/local/bin/openssl s_client -servername ssltest.${myhost} -connect ssltest.${myhost}:443 -CAfile /etc/ssl/cert.pem
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = *.${myhost}
verify return:1
---
Certificate chain
0 s:/CN=*.${myhost}
i:/C=US/O=Let's Encrypt/CN=R3
1 s:/C=US/O=Let's Encrypt/CN=R3
i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
2 s:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
i:/O=Digital Signature Trust Co./CN=DST Root CA X3
Пробовал этот кейс, проблема ушла только в контексте openssl и только на версии 1.0.2к собранной руками, на OpenSSL 1.0.1e-fips 11 Feb 2013 не катит, там если есть exp серт в чейне, все - пиши-пропало.
Сейчас пробую пыху руками сбилдить с верными $PATH и закинуть в систему.
