CentOS 6.10 и протухший недавно DST Root CA X3 — пляски с бубном, а есть ли варианты?

Question

[smart85]

Коллеги, приветствую!
Так исторически сложилось, что трудится несколько тачек под CentOS 6.10 + php + php-fpm
Обновить всю беду возможности пока нет, и не факт, что будет.
С 30 сентября ловлю проблемы с SSL - error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Все из-за протухшего DST Root CA X3
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.2k 26 Jan 2017, удалил i:/O=Digital Signature Trust Co./CN=DST Root CA X3 и собственно в контексте openssl хендшейк удался, но это только для openssl. А мне нужно едрить это из пыхи, а пыха, что не удивительно - видит старый openssl:
php -i | grep OpenSSL
OpenSSL support => enabled
OpenSSL Library Version => OpenSSL 1.0.1e-fips 11 Feb 2013
OpenSSL Header Version => OpenSSL 1.0.1e-fips 11 Feb 2013
Native OpenSSL support => enabled

Отсюда вопрос, а как бы и пыхе подкинуть новый openssl ?

Спасибо за внимание к моему вопросу.

Comments

[smart85]

Итого, нашел решение https://mta.openssl.org/pipermail/openssl-users/20...

Answer 1

[Ищю в поисковиках]

Я удалил этот серт из файлов

/usr/share/pki/ca-trust-source/ca-bundle.trust.p11-kit 
/etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt
/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem

А потом раскатил на остальные сервера и проблемы нет

Есть ещё питоновские / php либы, которые его используют, там тоже нужно выпилить/обновить.

Ну и у wordpress, как оказалось, есть корневые сертификаты.

Про подкинуть новый openssl - чтобы выстрел в ногу был безболезненным - лучше обновить. А так, можно попробовать либы позаменять, но там ещё больше шансов что-то сломать из-за обратной совместимости.

Comments

[smart85]

Спасибо за ответ!

Пробовал этот кейс, проблема ушла только в контексте openssl и только на версии 1.0.2к собранной руками, на OpenSSL 1.0.1e-fips 11 Feb 2013 не катит, там если есть exp серт в чейне, все - пиши-пропало.

Сейчас пробую пыху руками сбилдить с верными $PATH и закинуть в систему.

Answer 2

[SagePtr]

В пыхе можно через php.ini задать путь к ca bundle для функций openssl и curl.
Нужный ca bundle взять с сайта curl.

Comments

[smart85]

На версиях OpenSSL < 1.0.2 это не прокатит

[SagePtr]

smart85, по какой причине не прокатит? В cacert.pem от curl отсутствует истёкший DST Root CA X3, и присутствует ISRG Root X1

[smart85]

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

[smart85]

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]

smart85, и откуда этот протухший сертификат возьмётся, если его в этом бандле нет, а в цепочке сервер тоже его не передаёт? Он будет восприниматься просто как отсутствующий, а не как протухший, потому обработка просто пойдёт дальше.

[smart85]

Я вроде очень понятный пример привел выше, и обратил внимание, что это на версиях 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]

smart85, забавно, что у меня с той же версией на Centos 6.10 всё прекрасно работает)

openssl

OpenSSL support => enabled
OpenSSL Library Version => OpenSSL 1.0.1e-fips 11 Feb 2013
OpenSSL Header Version => OpenSSL 1.0.1e-fips 11 Feb 2013

При этом с https://badssl.com/ проверки не проходят, как и полагается, когда я их дёргаю точно также из того же скрипта.

[smart85]

SagePtr, каким образом осуществляется проверка?

[SagePtr]

smart85, простейшим скриптом проверял:

<?php

$curl = curl_init('https://letsencrypt.org/');
curl_setopt($curl, CURLOPT_RETURNTRANSFER, true);
curl_setopt($curl, CURLOPT_SSL_VERIFYPEER, true);
curl_setopt($curl, CURLOPT_SSL_VERIFYHOST, true);
echo '<div style=color:green>' . htmlspecialchars(curl_exec($curl)) . '</div>' . PHP_EOL;
echo '<div style=color:red>' . curl_error($curl) . '</div>' . PHP_EOL;