Certbot dst root ca x3

30 сентября 2021 14:01:15 GMT оканчивается срок действия корневого сертификата IdenTrust DST Root CA X3.

Это событие достойно вашего внимания по той причине, что после наступления этого момента ряд устаревших систем перестанут доверять сертификатам, выпущенным центром сертификации Let’s Encrypt. С учётом того, что на текущий момент Let’s Encrypt предоставляет бесплатные криптографические сертификаты примерно для 250 миллионов доменных имен, а «устаревшие системы» — это порой системы возрастом всего 5-6 лет, вряд ли окончание срока действия сертификата DST Root CA X3 пройдёт для всех гладко и незаметно. В чём причина, кого конкретно это затронет, и что можно сделать?

Which generates the certificate and saves it to:

• /etc/letsencrypt/live/sub.domain.com/fullchain.pem
• /etc/letsencrypt/live/sub.domain.com/privkey.pem

SSLCertificateFile /etc/letsencrypt/live/sub.domain.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/sub.domain.com/privkey.pem

When I browse to https://sub.domain.com I am getting an error that the certificate is not valid (due to expiration).

I have checked the certificate with openssl:

openssl x509 -in /etc/letsencrypt/live/sub.domain.com/fullchain.pem -noout -text

    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, O=Let's Encrypt, CN=R3
        Validity
            Not Before: Dec 15 09:48:49 2021 GMT
            Not After : Mar 15 09:48:48 2022 GMT

            Authority Information Access: 
                OCSP - URI:http://r3.o.lencr.org
                CA Issuers - URI:http://r3.i.lencr.org/

So the certificate itself is not expired, but the intermediate Root X3 is expired, but why is the Root X3 certificate still being used?

My ca-certificates package is up to date (ca-certificates-2021.2.50-72.el7_9.noarch).

/etc/pki/tls/certs/ca-bundle.crt does not contain the Root X3 anymore. It does contain the ISRG Root X1 certificate.

What am I mising?

/ Ошибка установки SSL-соединения с сертификатом Let’s Encrypt

Начиная с сегодняшнего дня, 30 сентября 2021 года при попытке соединения с сервером по шифрованным протоколам SSL/TLS могут возникать ошибки:

SSL error 0x80090325 Цепочка сертификатов выпущена центром сертификации, не имеющим доверия.

или другая аналогичная, сообщающая о невозможности установки защищённого соединения. Причина заключается в истечение сегодня срока действия корневого цифрового сертификата IdenTrust DST Root CA X3, которым подписаны сертификаты от популярного удостоверяющего центра (УЦ) Let’s Encrypt. Этим УЦ выпущено множество SSL сертификатов (более чем для 250 миллионов доменных имён), используемых в сети на веб-сайтах, почтовых серверах и других сервисах. Так как срок действия сертификата действителен не позднее 30 сентября 2021 14:01:15 GMT, после этой даты устройства и программы более не могут доверять ему и соединения не будут устанавливаться.

Для решения проблемы Let’s Encrypt уже более 5 лет использует подпись корневым сертификатом ISRG Root X1, действующим до 2035 года. Однако, устройства и операционные системы, не получающие обновления цепочки сертификатов, могут не иметь его в списке доверенных и столкнутся с ошибками SSL соединения. Список такого ПО и операционных систем:

• Android до версии 7.1.1;
• Mozilla Firefox до 50.0;
• MacOS 10.12.0 и старше;
• Windows до XP Service Pack 3;
• iOS-устройств до версии iOS 10;
• OpenSSL 1.0.2 и ниже;
• Ubuntu до версий 16.04;
• Debian 8 и старше.

Для восстановления возможности работы устаревшего устройства или программного обеспечения следует обновить операционную систему или добавить SSL-сертификат ISRG Root X1 в список доверенных.

I have a C# api running on a aws S3 with ubuntu.
This API is use by a website, a windows application and a xamarin app deployed on Samsung android devices.

Since today 16:00 (paris time), the android part is not working anymore, I have a «trust issue».
Clearly it seems to be related with DST Root CA X3 Expiration (No release on my side and the timing is perfect).

1. SSL certificate

I checked my SSL certificate and regarding let’sencrypt forums, I have one of the path base on «ISRG Root X1». The second one is base on «DST Root CA X3» (expired).
I renew them anyway to be sure, but still the same certificate path. (and no problem for chrome to contact them).

2. Internet with https is working

I can reach internet with a webview inside the app (to my website in https)

3. Can’t connect using restsharp

When I use RestSharp to contact my server, I have the trust issue.

My android devices are all the same: Samsung A7 tab, half up to date, the other half was update in august, all of them with Android 11. So theorically they are «not concerned» with this certificate expiration.

Can the problem come from Xamarin or RestSharp ? Maybe my server certificate ?

• Can I force RestSharp to use a certificate more than another ?
• Is it just because Android know the expiration date is 30/09 and still use it because we are still the 30/09 and everythin will work Tomorow ?

EDIT 2 resolved.

Thx to all of you, sorry I should have been able to validate this answer before some post, but stackoverflow was on readonly mode this night and I fall asleep after that.

What I did (not sure if all step are mandatory).

1/ I updated the certbot since mine was < 1 (check with certbot —version)

sudo apt-get remove -y certbot python3-certbot-apache
sudo snap install certbot --classic
sudo ln -s /snap/bin/certbot /usr/bin/certbot

update-ca-certificates

3/ I made a cert-sync to synchronise Ubuntu and Mono certificates (if it’s working as i undertand it)

4/ I renew my SSL certificate to remove the CA X3 since it’s no longer in my server certificates

sudo certbot renew --force-renewal --preferred-chain "ISRG Root X1"

SSlabs to check, the path with the old certifcate is removed and RestSharp work as previously.

Thx for the help everything were usefull !

Если при заходе на сайт появляется предупреждение с красным значком «Подключение не защищено, срок действия сертификата истек» – тогда возможно причина в том, что устарел сертификат IdenTrust DST Root CA X3 на Вашем устройстве. Особенно это актуально для старых устройств, например, для ПК с системой Windows XP или Windows 7.

В новых устройствах сертификаты обновлены или же там нет такой необходимости, а некоторые старые устройства попросту игнорируют проверку срока действия сертификатов, например, некоторые версии системы Android. Даже довольно новые умные телевизоры могут столкнуться с этой ошибкой, если разработчики их ПО не позаботились об обновлении сертификатов — тогда потребуется обновление прошивки ТВ или ручная замена сертификатов. Например, в смарт-ТВ LG стандартный браузер может не открывать сайты с сертификатами от Let’s Encrypt по этой причине.

Еще проблема может возникнуть у систем, которые используют версию OpenSSL, меньшую чем 1.1.0 — это происходит потому, что происходит проверка всех сертификатов и присутствие просроченного дает отказ в проверке безопасности соединения. Стоит упомянуть, что некоторые браузеры имеют свое хранилище сертификатов и поэтому могут открывать сайты без ошибок, несмотря на истекший сертификат. Например, браузер Mozilla Firefox.

Всё вышеописанное стало актуально 30.09.2021, когда заканчивается срок действия сертификата IdenTrust DST Root CA X3. Это корневой сертификат, который используется для формирования защищенных подключений. Особенно это важно для сайтов, использующих бесплатные сертификаты Let’s Encrypt. Эти бесплатные сертификаты ссылаются на корневой IdenTrust DST Root CA X3, так как он присутствует в большинстве ОС. Хотя для Let’s Encrypt создан свой корневой сертификат ISRG Root X1, но пока набиралась популярность бесплатных Let’s Encrypt, он не мог быстро попасть во все системы.

Как исправить проблему с истекшим сертификатом? Для этого потребуется удалить старый сертификат и установить новый. Выполнить данную операцию можно на тех устройствах, которые позволяют это сделать. Например, на ПК с MS Windows 7.

Скачивать потребуется сертификат под названием ISRG Root X1, желательно только с официального сайта letsencrypt.org. Сертификат имеет полное название ISRG Root X1 (RSA 4096, O = Internet Security Research Group, CN = ISRG Root X1) и доступен по ссылкам:

— https://letsencrypt.org/certs/isrgrootx1.der, в формате DER;

— https://letsencrypt.org/certs/isrgrootx1.pem, в формате PEM.

Также возможно понадобится сертификат Let’s Encrypt R3 (RSA 2048, O = Let’s Encrypt, CN = R3), доступный по ссылкам ниже:

— https://letsencrypt.org/certs/lets-encrypt-r3.der, в формате DER;

— https://letsencrypt.org/certs/lets-encrypt-r3.pem, в формате PEM.

Установка сертификата достаточно проста:

1. Открыть скачанный сертификат и нажать «Установить сертификат».

3. Последний этап — нажать кнопку «Готово», что приведет к добавлению сертификата в устройство.

Управление сертификатами в MS Windows производится при помощи специальной программы, которую можно запустить следующим образом: нажать сочетание клавиш Win + R и написать certmgr.msc, после чего нажать Enter.

Это понадобится для того, чтобы вручную удалить истекший сертификат IdenTrust DST Root CA X3, а также для контроля успешности операции добавления новых сертификатов – они должны появиться в разделе «Доверенные корневые центры сертификации», подраздел «Сертификаты».

Там же необходимо найти старый сертификат и выполнить его удаление.

После этих процедур можно выполнить перезагрузку ПК или сразу проверить работу ранее неоткрывавшихся сайтов с ошибкой SSL. Сайты должны открываться, но время их открытия может стать немного большим, так как при каждом запросе происходит поиск нового сертификата в хранилище.

Таким образом, проблема с открытием сайтов решается установкой нового сертификата.

I am aware that Let’s Encrypt made changes that may impact older clients because a root certificate would expire. See DST Root CA X3 Expiration (September 2021).

However, I didn’t think this could impact me because my development machine is up-to-date.

But since today I get the message while doing a git pull:

fatal: unable to access 'https://git.company.tld/project.git/': SSL certificate problem: certificate has expired

I just downloaded the newest Git for Windows (2.33.0) and confirmed that the built-in OpenSSL is up-to-date (OpenSSL 1.1.1k 25 Mar 2021) which should be good.

OpenSSL Client Compatibility Changes for Let’s Encrypt Certificates

But the error seems to stay.

openssl s_client -showcerts -connect git.company.tld:443

CONNECTED(000001A0)
---
Certificate chain
 0 s:CN = git.company.tld
   i:C = US, O = Let's Encrypt, CN = R3
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:O = Digital Signature Trust Co., CN = DST Root CA X3
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
---
Server certificate
subject=CN = git.company.tld

issuer=C = US, O = Let's Encrypt, CN = R3

---
No client certificate CA names sent
Peer signing digest: SHA512
Peer signature type: RSA
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3058 bytes and written 443 bytes
Verification error: certificate has expired
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: ...
    Session-ID-ctx:
    Master-Key: ...
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1632982992
    Timeout   : 7200 (sec)
    Verify return code: 10 (certificate has expired)
    Extended master secret: no
---

The problem is not with the issued certificate itself which is not expired and accepted by Chrome (Windows certificate store) and Firefox.

asked Sep 30, 2021 at 6:27

24 gold badges118 silver badges188 bronze badges

sudo rm /usr/share/ca-certificates/mozilla/DST_Root_CA_X3.crt
sudo update-ca-certificates

On my Mac OS X 10.13.6 (High Sierra) machine, cURL (and therefore Git) rely on the /etc/ssl/cert.pem file for root CA verification.

The solution was to remove the DST Root CA X3 certificate, which expired today, from the file:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            44:af:b0:80:d6:a3:27:ba:89:30:39:86:2e:f8:40:6b
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3
        Validity
            Not Before: Sep 30 21:12:19 2000 GMT
            Not After : Sep 30 14:01:15 2021 GMT
        Subject: O=Digital Signature Trust Co., CN=DST Root CA X3
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:df:af:e9:97:50:08:83:57:b4:cc:62:65:f6:90:
                    82:ec:c7:d3:2c:6b:30:ca:5b:ec:d9:c3:7d:c7:40:
                    c1:18:14:8b:e0:e8:33:76:49:2a:e3:3f:21:49:93:
                    ac:4e:0e:af:3e:48:cb:65:ee:fc:d3:21:0f:65:d2:
                    2a:d9:32:8f:8c:e5:f7:77:b0:12:7b:b5:95:c0:89:
                    a3:a9:ba:ed:73:2e:7a:0c:06:32:83:a2:7e:8a:14:
                    30:cd:11:a0:e1:2a:38:b9:79:0a:31:fd:50:bd:80:
                    65:df:b7:51:63:83:c8:e2:88:61:ea:4b:61:81:ec:
                    52:6b:b9:a2:e2:4b:1a:28:9f:48:a3:9e:0c:da:09:
                    8e:3e:17:2e:1e:dd:20:df:5b:c6:2a:8a:ab:2e:bd:
                    70:ad:c5:0b:1a:25:90:74:72:c5:7b:6a:ab:34:d6:
                    30:89:ff:e5:68:13:7b:54:0b:c8:d6:ae:ec:5a:9c:
                    92:1e:3d:64:b3:8c:c6:df:bf:c9:41:70:ec:16:72:
                    d5:26:ec:38:55:39:43:d0:fc:fd:18:5c:40:f1:97:
                    eb:d5:9a:9b:8d:1d:ba:da:25:b9:c6:d8:df:c1:15:
                    02:3a:ab:da:6e:f1:3e:2e:f5:5c:08:9c:3c:d6:83:
                    69:e4:10:9b:19:2a:b6:29:57:e3:e5:3d:9b:9f:f0:
                    02:5d
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            X509v3 Subject Key Identifier:
                C4:A7:B1:A4:7B:2C:71:FA:DB:E1:4B:90:75:FF:C4:15:60:85:89:10
    Signature Algorithm: sha1WithRSAEncryption
         a3:1a:2c:9b:17:00:5c:a9:1e:ee:28:66:37:3a:bf:83:c7:3f:
         4b:c3:09:a0:95:20:5d:e3:d9:59:44:d2:3e:0d:3e:bd:8a:4b:
         a0:74:1f:ce:10:82:9c:74:1a:1d:7e:98:1a:dd:cb:13:4b:b3:
         20:44:e4:91:e9:cc:fc:7d:a5:db:6a:e5:fe:e6:fd:e0:4e:dd:
         b7:00:3a:b5:70:49:af:f2:e5:eb:02:f1:d1:02:8b:19:cb:94:
         3a:5e:48:c4:18:1e:58:19:5f:1e:02:5a:f0:0c:f1:b1:ad:a9:
         dc:59:86:8b:6e:e9:91:f5:86:ca:fa:b9:66:33:aa:59:5b:ce:
         e2:a7:16:73:47:cb:2b:cc:99:b0:37:48:cf:e3:56:4b:f5:cf:
         0f:0c:72:32:87:c6:f0:44:bb:53:72:6d:43:f5:26:48:9a:52:
         67:b7:58:ab:fe:67:76:71:78:db:0d:a2:56:14:13:39:24:31:
         85:a2:a8:02:5a:30:47:e1:dd:50:07:bc:02:09:90:00:eb:64:
         63:60:9b:16:bc:88:c9:12:e6:d2:7d:91:8b:f9:3d:32:8d:65:
         b4:e9:7c:b1:57:76:ea:c5:b6:28:39:bf:15:65:1c:c8:f6:77:
         96:6a:0a:8d:77:0b:d8:91:0b:04:8e:07:db:29:b6:0a:ee:9d:
         82:35:35:10
-----BEGIN CERTIFICATE-----
MIIDSjCCAjKgAwIBAgIQRK+wgNajJ7qJMDmGLvhAazANBgkqhkiG9w0BAQUFADA/
MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMT
DkRTVCBSb290IENBIFgzMB4XDTAwMDkzMDIxMTIxOVoXDTIxMDkzMDE0MDExNVow
PzEkMCIGA1UEChMbRGlnaXRhbCBTaWduYXR1cmUgVHJ1c3QgQ28uMRcwFQYDVQQD
Ew5EU1QgUm9vdCBDQSBYMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AN+v6ZdQCINXtMxiZfaQguzH0yxrMMpb7NnDfcdAwRgUi+DoM3ZJKuM/IUmTrE4O
rz5Iy2Xu/NMhD2XSKtkyj4zl93ewEnu1lcCJo6m67XMuegwGMoOifooUMM0RoOEq
OLl5CjH9UL2AZd+3UWODyOKIYepLYYHsUmu5ouJLGiifSKOeDNoJjj4XLh7dIN9b
xiqKqy69cK3FCxolkHRyxXtqqzTWMIn/5WgTe1QLyNau7Fqckh49ZLOMxt+/yUFw
7BZy1SbsOFU5Q9D8/RhcQPGX69Wam40dutolucbY38EVAjqr2m7xPi71XAicPNaD
aeQQmxkqtilX4+U9m5/wAl0CAwEAAaNCMEAwDwYDVR0TAQH/BAUwAwEB/zAOBgNV
HQ8BAf8EBAMCAQYwHQYDVR0OBBYEFMSnsaR7LHH62+FLkHX/xBVghYkQMA0GCSqG
SIb3DQEBBQUAA4IBAQCjGiybFwBcqR7uKGY3Or+Dxz9LwwmglSBd49lZRNI+DT69
ikugdB/OEIKcdBodfpga3csTS7MgROSR6cz8faXbauX+5v3gTt23ADq1cEmv8uXr
AvHRAosZy5Q6XkjEGB5YGV8eAlrwDPGxrancWYaLbumR9YbK+rlmM6pZW87ipxZz
R8srzJmwN0jP41ZL9c8PDHIyh8bwRLtTcm1D9SZImlJnt1ir/md2cXjbDaJWFBM5
JDGFoqgCWjBH4d1QB7wCCZAA62RjYJsWvIjJEubSfZGL+T0yjWW06XyxV3bqxbYo
Ob8VZRzI9neWagqNdwvYkQsEjgfbKbYK7p2CNTUQ
-----END CERTIFICATE-----

After removing the entire code snippet above from the file and saving it, the error went away.

answered Sep 30, 2021 at 17:19

I had the same issue because I was running an old version of Git for Windows (2.15.0). After updating Git to the latest version (2.33) the problem was fixed.

Reason: Older versions of Git would not accept the expired root certificate from Let’s Encrypt.

answered Sep 30, 2021 at 16:45

I faced the same problem on an Ubuntu 14.04 LTS (Trusty Tahr) server.

This problem affected cURL calls from PHP, etc.

Example: from a simple curl on the command line,

curl https://curl.se/ca/cacert.pem

I was getting the certificate expired message. It was due to the old Let’s Encrypt certificate expiration. dst-root-ca-x3-expiration-september-2021

So, here is a simple working solution:

Edit the file /etc/ca-certificates.conf.

Find and comment the lines with ! like this:

!mozilla/DST_Root_CA_X3.crt

sudo sed -i -e 's/mozilla\/DST_Root_CA_X3\.crt/!mozilla\/DST_Root_CA_X3\.crt/g' /etc/ca-certificates.conf

Save the file

sudo update-ca-certificates

answered Oct 1, 2021 at 0:17

On our Windows test clients we had to update Git to the latest version.

Since Git 2.16.1(2) you can use

git update-git-for-windows

In version between 2.14.2 and 2.16.1, the command was

git update

See also: How to upgrade Git on Windows to the latest version

answered Oct 4, 2021 at 11:46

6 gold badges27 silver badges52 bronze badges

For those who have servers running on Ubuntu, with Certbot managing certificates, I have forced the renewals using ISRG Root X1. This way, new certificates don’t contain the chain of DST Root CA X3, and this did the trick for us.

To do that, first check if your Certbot version is < 1:

sudo certbot --version

If so, you have to remove it and reinstall using Snap:

sudo apt-get remove -y certbot python3-certbot-apache
sudo snap install certbot --classic
sudo ln -s /snap/bin/certbot /usr/bin/certbot

After reinstalling, or if your Certbot version is > 1, force the renewal:

sudo certbot renew --force-renewal --preferred-chain "ISRG Root X1"

I also have used DigiCert SSL Installation Diagnostics Tool to check my certificates, before and after renewing, to verify if the DST X3 chain was removed.

answered Oct 1, 2021 at 14:52

Felix Runye

1 gold badge19 silver badges20 bronze badges

Apparently this is not a client issue, but the Let’s Encrypt certificate being served by a Sophos UTM WAF (latest version, 9.707-5).

The same certificate served from an Apache web server works fine (and the openssl s_client -showcerts response looks different -> more entries in the certificate chain). So this is not a client-related problem.

Android

Устройства с версиями ОС Android до 7.1.1 также не поддерживают корневой сертификат ISRG Root X1. Однако, Let’s Encrypt удалось договориться с IdenTrust о выпуске на 3 года кросс-подписи истекшего DST Root CA X3. Таким образом, устройства даже с устаревшими версиями Android не будут сообщать об ошибке как минимум до 2024 года. Действий с ними не требуется.

При перепубликации статьи установка активной индексируемой
гиперссылки на источник — сайт обязательна!

Что со всем этим делать?

На стороне клиента

Linux

Для того, чтобы проверить, как поведёт себя ваша система при обращении к сайтам, использующим сертификаты Let’s Encrypt, после 30 сентября, можно воспользоваться утилитой faketime. В Debian и Ubuntu она доступна в пакете faketime.

Если всё в порядке, curl вернёт содержимое страницы, если же нет — выдаст сообщение об ошибке:

curl: (60) server certificate verification failed.

В этом случае нужно убедиться, что:

1. Ваша система доверяет ISRG Root X1 

2. Вы не пользуетесь устаревшей версией OpenSSL

Проверка доверия к ISRG Root X1

Например, Ubuntu 16.04 xenial и Debian 8 jessie доверяют ISRG Root X1, но при этом поставляются с OpenSSL 1.0.x, поэтому проблема их может коснуться.

Чтобы проверить наличие сертификата ISRG Root X1 в числе доверенных: 

В выводе команды в обоих случаях должно присутствовать:

subject= /C=US/O=Internet Security Research Group/CN=ISRG Root X1

Если такой строчки нет, то нужно добавить ISRG Root X1 в доверенные. В Debian/Ubuntu:

добавить в файл /etc/ca-certificates.conf строчку:

и выполнить комнаду

Проверка версии OpenSSL

Если система доверяет ISRG Root X1, нужно проверить версию OpenSSL

В выводе должна быть версия 1.1.0 или новее.

Если используется OpenSSL 1.0.x, то достаточным решением проблемы будет удалить из доверенных сертификат DST Root CA X3 (это решение может не сработать для openssl версий <1.0.1p и <1.0.2d). Это можно сделать, не дожидаясь 30 сентября.

В файле /etc/ca-certificates.conf нужно найти строчку:

и поставить в начало сроки символ «!»:

Далее, необходимо выполнить команду:

Локальное продление срока действия сертификата DST Root CA X3

Для тех случаев, когда используется совсем старый openssl (версии меньше 1.0.1p и 1.0.2d, но новее 0.9.8m), или по иной причине не срабатывает метод с изъятием из доверенных сертификата DST Root CA X3, можно воспользоваться еще одним методом, предложенным в статье Scott’а Helme. Метод основан на том, что OpenSSL, начиная с версии 0.9.8m, не проверяет сигнатуру сертификатов, хранящихся в локальном защищенном хранилище. Таким образом, можно изменить время действия сертификата в защищенном хранилище, при этом модифицированный сертификат будет по-прежнему восприниматься OpenSSL как валидный. Для того, чтобы продлить для OpenSSL на системе срок действия сертификата DST Root CA X3 еще на три года можно выполнить следующие команды:

sudo sed -i "s/xMDkzMDE0MDExNVow/0MDkzMDE4MTQwM1ow/g" /etc/ssl/certs/DST_Root_CA_X3.pem

sudo sed -i "s/xMDkzMDE0MDExNVow/0MDkzMDE4MTQwM1ow/g" /etc/ssl/certs/ca-bundle.crt

Не забудьте проверить так же все ваши контейнеры!!! У них свои хранилища корневых сертификатов и могут использоваться другие версии openssl

Windows

В мастере импорта сертификатов выбрать «Локальный компьютер»:

На последнем шаге мастера нажать кнопку «Готово».

После выполнения этой последовательности шагов, сертификат должен появиться в защищенном хранилище. Чтобы проверить это, нужно нажать комбинацию клавиш «Win+R», откроется диалог «Выполнить», в котором нужно ввести certmgr.msc

В открывшемся окне в подразделе «Сертификаты» раздела «Доверенные корневые центры сертификации» в списке должен появиться сертификат ISRG Root X1:

На стороне сервера 

На стороне сервера от вас мало что зависит. Если вы используете сертификаты от Let’s Encrypt на своем сервере, то должны понимать, что после 30 сентября 2021 14:01:15 GMT к вашему серверу смогут без проблем подключиться только клиенты, доверяющие ISRG Root X1 (см. список выше), а также использующие Android >= v2.3.6. При этом, если клиенты используют OpenSSL, то они должны пользоваться версией OpenSSL >= 1.1.0. 

При этом, у вас есть выбор — ценой отказа от поддержки старых Android (оставив поддержку Android >= 7.1.1), вы можете сохранить поддержку OpenSSL 1.0.x без манипуляций на стороне клиента.

Для этого нужно использовать предлагаемую Let’s Encrypt альтернативную цепочку доверия для своих сертификатов. В этой цепочке исключен DST Root CA X3 и выглядит она так: 

ISRG Root X1 -> Let’s Encrypt R3 -> Конечный сертификат пользователя

Для переключения на альтернативную цепочку нужно воспользоваться документацией вашего ACME-клиента. В частности, в certbot за возможность выбора альтернативной цепочки отвечает параметр  —preferred-chain.

Что произойдет 30 сентября?

Срок действия DST Root CA X3 подходит к концу 30 сентября 2021 14:01:15 GMT, что произойдет после этого?

Те системы, которые не доверяют ISRG Root X1, перестанут доверять сертификатам, выпущенным Let’s encrypt (системы будут выдавать предупреждения при посещении сайтов, использующих сертификаты Let’s Encrypt). За исключением Android >= v2.3.6, т.к. Android не учитывает срок действия своих доверенных корневых сертификатов. 

Проблема с доверием возникнет также у систем, использующих OpenSSL версии меньше 1.1.0. Даже если у таких систем ISRG Root X1 входит в список доверенных сертификатов, особенность проверки сертификата в OpenSSL 1.0.x приведёт к тому, что наличие в цепочке истекшего DST Root CA X3, несмотря на наличие доверия к ISRG Root X1, будет приводить к отрицательному результату проверки на доверие. Аналогичная проблема у OpenSSL 1.0.x возникла 20 мая 2020 года с истекшим сертификатом AddTrust External CA Root.

Немного теории и истории

Не углубляясь в детали, пару слов для неспециалистов, почему окончание срока действия сертификата DST Root CA X3 повлияет на сертификаты, выпущенные Let’s Encrypt. У каждой системы, проверяющей сертификат на валидность, есть своё хранилище доверенных корневых сертификатов. Система при проверке будет доверять сертификатам, которые подписаны с использованием закрытого ключа одного из этих корневых сертификатов. Сами корневые сертификаты как правило имеют длительные сроки действия, меняются редко и не используются при формировании сертификатов конечного субъекта (в данном случае, сертификатов для доменных имен), вместо этого инфраструктура открытых ключей, предполагает использование цепочек доверия  — корневые сертификаты применяются для подписания промежуточных сертификатов, а уже с использованием них подписываются сертификаты конечного субъекта (сертификаты для доменов). При этом, для того, чтобы система доверяла конечному сертификату, она должна быть способна проследить всю цепочку от этого сертификата до одного из корневых сертификатов, которым она доверяет. 

После появления проекта Let’s Encrypt, его корневой сертификат ISRG Root X1 (как и любой новый корневой сертификат) не мог быстро попасть в хранилища доверенных сертификатов заметного количества систем. При этом для успешного функционирования проекта выданным сертификатам с самого начала должно было доверять максимальное количество систем «из коробки» (без дополнительных действий со стороны пользователей этих систем). В связи с этим, для сертификатов Let’s Encrypt стала использоваться цепочка доверия, ведущая к корневому сертификату DST Root CA X3, который признается большинством систем:

К настоящему моменту корневой сертификат ISRG Root X1 существует уже более 5 лет и за это время попал в доверенные в большинстве современных систем, ему доверяют:

• Windows >= XP SP3 (при условии, что производилось автоматическое обновление корневых сертификатов)

• macOS >= 10.12.1

• iOS >= 10 

• Android >= 7.1.1 

• Mozilla Firefox >= 50.0

• Ubuntu >= xenial / 16.04 (с установленными обновлениями)

• Debian >= jessie / 8 (с установленными обновлениями)

• Java 8 >= 8u141

• Java 7 >= 7u151

• NSS >= 3.26

Для сертификатов Let’s Encrypt по умолчанию в данный момент предлагается такая цепочка доверия: 

IdenTrust’s DST Root CA X3 -> ISRG Root X1 -> Let’s Encrypt R3 -> Конечный сертификат пользователя

Windows

В Windows установить корневой сертификат ISRG Root X1 можно запустив оснастку «Сертификаты» командой:

и импортировав в корневые сертификаты учётной записи компьютера файл сертификата.

IOS (iPhone и iPad с ОС до 10 версии)

1. Скачайте файл сертификата ISRG Root X1 на устройство.
2. Перейдите в «Настройки» -> «Основные» -> «Профили и управление устройством» выберите сертификат ISRG Root X1 и нажмите «Установить».
3. В Настройки» -> «Основные» -> «Доверие сертификатов» включите «Доверять корневым сертификатам полностью».

Update

Client requests worked instantly.

Thanks to VolkerZier in the Sophos forum for giving the hint. See (in German) Let’s Encrypt Root Zertifikat gültig bis 30.09.2021 (alte R3 / X3 Zertifikatskette).

answered Sep 30, 2021 at 12:55

24 gold badges118 silver badges188 bronze badges

For applications based on OpenSSL <= 1.0.2 such as Ubuntu 12.04 (Precise Pangolin), you need to allow OpenSSL to use the alternate chain path to trust the remote site.

First you need to install the ISRG_Root_X1.crt certificate and remove the expired one from the trusted store: DST_Root_CA_X3.crt

This will allow that clients using OpenSSL like Wget, cURL, etc. to work again. The steps are:

To install the ISRG_Root_X1 certificate:

sudo wget http://launchpadlibrarian.net/482351465/ca-certificates_20190110~12.04.1_all.deb
sudo dpkg -i ca-certificates_20190110~12.04.1_all.deb

To disable the DST_Root_CA_X3 certificate:

sudo vi /etc/ca-certificates.conf

Then set: !mozilla/DST_Root_CA_X3.crt

Note: In this file, when the line begins with # is comment. When the line begins with ! is certificate filename to be deselected.

And finally run:

sudo update-ca-certificates

After that, wget and curl will not complain any more.

The best explanation I’ve found out there is the video DST Root CAX3 Expiration Sept 2021 (34 minutes).

answered Oct 1, 2021 at 12:19

I was facing a similar issue with DevOps build agents. But I can access the DevOps server web interface without any issue.

To solve this,

• I updated my Let’s Encrypt client (I’m using Certify The Web)
• I have renewed my certificate

After that, the DevOps agent is able to do a Git pull.

answered Sep 30, 2021 at 9:29

Verify the version of GnuTLS (libgnutls). The issue with alternate chains was fixed in 3.6.13-4. So updating GnuTLS to a version above this might solve the issue for Git.

(On Debian systems at least) curl/wget uses libssl/OpenSSL and Git uses libgnutls30 via libcurl3-gnutls.

answered Oct 11, 2021 at 6:22

Vipin Menon

4 gold badges18 silver badges32 bronze badges

I (as will many in the Third World), have several Windows XP 32/64-bit machines. They are since Friday giving me the «YOUR CLOCK IS AHEAD» error, which is part, I believe, of this SSL certificate lapse. (They were all flawless, universally across the web with Chrome previously).

Many websites (~40%) I visit on the Windows XP machines (handy for legacy software, etc), all give the same TIME error-msg.

My instinct tells me:

answered Oct 2, 2021 at 17:56

The same issue here. For me, it helps to update Visual Studio 2017.

answered Oct 5, 2021 at 11:40

curl: (60) SSL certificate problem: certificate has expired
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

(TLS SFTP SCP) By default, every secure connection curl makes is verified to be secure before the transfer takes place. This option makes curl skip the verification step and proceed without checking. curl/manpage

answered Jun 24, 2022 at 1:09

1 gold badge18 silver badges18 bronze badges

Итоги

30 сентября после окончания срока действия сертификата DST Root CA X3 часть пользователей старых устройств столкнутся с тем, что не смогут корректно открывать сайты, использующие сертификаты Let’s Encrypt. Я бы выделил в первую очередь пользователей старых устройств Apple, для которых нет возможности обновиться хотя бы на iOS 10. Кроме того, под раздачу могут попасть различные устройства IoT, старые телевизоры и подобные им устройства, для которых не существует обновлений с новыми корневыми сертификатами.

В то же время, для администраторов серверов с не очень современным софтом, которые могут взаимодействовать с сервисами, использующими сертификаты Let’s Encrypt, еще есть несколько дней на то, чтобы всё проверить и подготовиться к часу X.

Update: Добавил важное дополнение про необходимость проверки всех используемых контейнеров

Update3: Еще один метод решения проблемы для старых OpenSSL, процедура по добавлению сертификата ISRG Root X1 в доверенные в Windows для тех, кто еще не разобрался