1С-ЭДО Цепочка сертификатов не может быть построена до доверенного корневого сертификата

При возникновении ошибки “Цепочка сертификатов не может быть построена до доверенного корневого сертификата.” необходимо выполнить проверку сертификата электронной подписи.

Алгоритм проверки электронной подписи:

В программном продукте 1С необходимо 

1. перейти в раздел “Администрирование” 

2. “Обмен электронными документами”

3. “Настройка электронной подписи и шифрования”

4. На вкладке “Сертификаты” открыть используемый сертификат

5. Нажать на кнопку “Проверить”

6. Ввести пароль закрытой части ключа и нажать “Проверить”

! Обращаем Ваше внимание, что программа сама увеличит количество * в поле “Пароль:” до 16 при проверке. Данное поведение является штатным и выступает дополнительной защитой конфиденциальных данных в виде количества символов в пароле. Проверка будет осуществлена на основании введенных Вами данных.

Если в ходе проверки напротив пункта “Корректность данных сертификата” возникнет сигнализирующий об ошибке красный символ, на него необходимо нажать для открытия технической информации об ошибке.

Если в технической информации об ошибке указано “Цепочка сертификатов не может быть построена до доверенного корневого

сертификата.” это обозначает, что цепочка сертификации выстроена не полностью. Данная ошибка чаще всего встречается при первичной установке сертификата. Для просмотра пути сертификации необходимо сохранить сертификат, указав директорию компьютера, где его можно будет найти. Сделать это можно из программы 1С открыв сертификат в настройках электронной подписи и шифрования и нажать кнопку “Сохранить в файл” и указать директорию операционной системы для сохранения файла.

После сохранения сертификата необходимо открыть его в сохраненной директории.

Открыть сертификат можно дважды нажав на него левой кнопкой мыши или правая кнопка мыши – Открыть.

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

Следующим этапом необходимо перейти во вкладку “Путь сертификации”. Можно заметить, что путь сертификации состоит из одного личного сертификата, а в состоянии сертификата присутствует надпись “Невозможно обнаружить поставщика этого сертификата”. 

В компьютерной безопасности цифровые сертификаты проверяются с помощью цепочки доверия. Сертификаты удостоверяются ключами тех сертификатов, которые находятся выше в иерархии сертификатов. Наивысший сертификат в цепочке называется корневым.

Пример корректного пути сертификации

Решение: Восстановить путь сертификацию

В сертификате необходимо перейти во вкладку “Состав” и в верхнем окне необходимо найти и нажать на поле “Доступ к информации о центрах сертификации”. В нижнем окне сертификата появится информация о доступах к сведениям центра сертификации, в котором необходимо найти ссылку, которая заканчивается на .cer или .crt. Данную ссылку необходимо скопировать от http:// до конца строки не включая
URL=. Копирование производится при помощи комбинации клавиш Ctrl C.

Открыть браузер и вставить скопированное ранее значение в адресную строку, нажать “Перейти” (Enter). Откроется окно просмотра загрузок, в котором браузер предложит сохранить или открыть файл. Необходимо нажать “Сохранить как” и указать директорию, куда произойдёт сохранение.

Произойдет скачивание сертификата удостоверяющего центра, который выдал личный сертификат. После скачивания необходимо перейти в указанную директорию и открыть скаченный сертификат. В нашем примере это сертификат astral-883-2021.

После открытия сертификата удостоверяющего центра необходимо нажать “Установить сертификат”

В открывшемся мастере импорта сертификатов выбрать Расположение хранилища: “Текущий пользователь” и нажать “Далее”.

В следующем окне выбрать “Поместить все сертификаты в следующее хранилище” нажать “Обзор” и выбрать “Доверенные корневые центры сертификации”, нажать “Далее” и завершить установку.

После появится окно предупреждения системы безопасности. Для установки сертификата необходимо нажать “Да”

Затем появится окно, сообщающее о том, что импорт сертификата успешно выполнен.

После установки сертификата удостоверяющего центра путь сертификации будет состоять уже из двух сертификатов: личного сертификата сотрудника организации, который ссылается на доверенный сертификат удостоверяющего центра, который выдал данному сотруднику сертификат.

Сертификат удостоверяющего центра не может сослаться на вышестоящий сертификат Головного удостоверяющего центра в виду его отсутствия на рабочем месте.

Для установки сертификата Головного удостоверяющего центра необходимо открыть сертификат удостоверяющего центра и перейти во вкладку “Состав”. В верхнем окне выбрать поле “Идентификатор ключа центра сертификатов”, а затем в нижнем окне скопировать серийный номер сертификата (Ctrl C).

Для скачивания нужного сертификата Головного удостоверяющего центра необходимо перейти на Портал уполномоченного федерального органа в области использования электронной подписи и перейти на вкладку “ГОЛОВНОЙ УЦ” https://e-trust.gosuslugi.ru/#/portal/mainca

Далее, используя сочетание клавиш Ctrl F необходимо вызвать окно поиска и вставить в него скопированный серийный номер из сертификата удостоверяющего центра. Из представленного на сайте перечня сертификатов отобразиться тот, чей серийный номер совпадает. Именно данный сертификат Головного удостоверяющего центра нужно скачать. Для скачивания необходимо нажать на гиперссылку в строке “Отпечаток”.

После нажатия на отпечаток произойдет скачивание сертификата Головного удостоверяющего центра. Необходимо нажать “Сохранить как” и выбрать необходимую директорию для сохранения сертификата Головного удостоверяющего центра.

Необходимо перейти в директорию, куда был скачан сертификат и открыть его.

В открывшемся сертификате необходимо нажать “Установить сертификат”

В мастере импорта сертификатов необходимо выбрать “Текущий пользователь” и нажать “Далее”

В следующем окне необходимо выбрать “Поместить все сертификаты в следующее хранилище”, нажать “Обзор”. В окне выбора хща сертификата необходимо поставить галочку “Показать физические хранилища”, затем развернуть “Доверенные корневые центры сертификации” нажатием на ” ” и выбрать “Локальный компьютер” и нажать “ОК”. Завершить установку сертификата.

После установки сертификата Головного удостоверяющего центра путь сертификации личного сертификата восстановлен.

После восстановления пути сертификации ошибка не воспроизводится.

Однако потом что-то пошло не так, кто-то оказался не готов, и использование ГОСТ Р 34.10-2001 продлили на 2021 год. Но вдруг все бросились переводить УЦ на ГОСТ Р 34.10-2021, а простых граждан переводить на новые сертификаты. У людей на руках стало по нескольку сертификатов. При проверки сертификатов или электронной подписи стали возникать вопросы, а где взять корневые сертификаты, чтобы установить в хранилища доверенных корневых сертификатов.

Это касается как хранилища сертификатов в Windows, так и хранилища сертификатов в браузерах Firefox и Google Chrome, GnuPG, LibreOffice, почтовых клиентах и даже OpenSSL. Конечно, надо было озаботиться этим при получении сертификата в УЦ и записать цепочку сертификатов на флешку. А с другой стороны у нас же цифровое общество и в любой момент должна быть возможность получить эту цепочку из сети. Как это сделать на страницах Хабра показалsimpleadmin. Однако для рядового гражданина это все же сложновато (особенно, если иметь ввиду, что абсолютное их большинство сидит на Windows): нужно иметь «какой-то» openssl, утилиту fetch, которой и у меня не оказалось на компьютере, и далеко не каждый знает, что вместо нее можно использовать wget. А сколько действий нужно выполнить. Выход конечно есть, написать скрипт, но не просто скрипт поверх openssl и иже с ним, а упакованный в самодостаточный выполняемый модуль для различных платформ.

На чем писать никаких сомнений не было – на Tcl и Python. И начинаем с Tcl и вот почему:

* охренительной вики, где есть даже игрушки (там можно подсмотреть интересное 🙂
* шпаргалки
* нормальные сборки tclkit (1.5 — 2 Мб как плата за реальную кросс-платформенность)
* и моя любимая сборка eTcl от Evolane (бережно сохранённая с умершего сайта 🙁
сохраняют высокий рейтинг Tcl/Tk в моём личном списке инструментария
и, да, wiki.tcl.tk/16867 (мелкий web-сервер с cgi на Tcl, периодически используется с завидным постоянством под tclkit)
а ещё — это просто красиво и красиво 🙂

К этому бы я добавил наличии утилиты

freewrap

, которая нам и поможет собрать автономные (standalone) утилиты для Linux и MS Windows. В результате мы будем иметь утилиту chainfromcert:

bash-4.3$ ./chainfromcert_linux64  
Copyright(C)2021 
Usage: 
chainfromcert <file with certificate> <directory for chain certificate> 
Bad usage! 
bash-4.3$

В качестве параметров утилите задаются файл с пользовательским сертификатом (как в формате PEM, так и формате DER) и каталог, в котором будут сохранены сертификаты УЦ, входящие в цепочку:

bash-4.3$ ./chainfromcert_linux64  ./cert_test.der /tmp
Loading file: cert_test.der 
Directory for chain: . 
cert 1 from http://ca.ekey.ru/cdp/ekeyUC2021.cer 
cert 2 from http://reestr-pki.ru/cdp/guc_gost12.crt 
Goodby! 
Length chain=2 
Copyright(C) 2021
bash-4.3$

А теперь рассмотрим как работает утилита.

Информация о центре сертификации, выдавшем сертификат пользователю, хранится в расширении с oid-ом 1.3.6.1.5.5.7.1.1. В этом расширении может хранится как о местонахождении сертификата УЦ (oid 1.3.6.1.5.5.7.48.2), так и информация о службе OCSP УЦ (oid 1.3.6.1.5.5.7.48.1):

А информация, например, о периоде использования ключа электронной подписи хранится в расширении с oid-ом 2.5.29.16.

Для разбора сертификата и доступа к расширениям сертификата воспользуемся пакетом pki:

#!/usr/bin/tclsh -f
package require pki

Нам также потребуются пакет base64:

package require base64

Пакет pki, а также подгружаемые им пакет asn, и пакет base64 и помогут нам преобразовывать сертификаты из PEM-кодировки в DER-кодировку, разобрать ASN-структуры и собственно получить доступ к информации о местонахождении сертификатов УЦ.

Работа утилиты начинается с проверки параметров и загрузки файла с сертификатом:

proc usage {use } {
    puts "Copyright(C)  2021-2021"
    if {$use == 1} {
	puts "Usage:nchainfromcert <file with certificate> <directory for chain certificate>n"
    }
}
if {[llength $argv] != 2 } {
    usage 1
    puts "Bad usage!"
    exit
}
set file [lindex $argv 0]
if {![file exists $file]} {
    puts "File $file not exist"
    usage 1
    exit
}
puts "Loading file: $file"
set dir [lindex $argv 1]
if {![file exists $dir]} {
    puts "Dir $dir not exist"
    usage 1
    exit
}
puts "Directory for chain: $dir"
set fd [open $file]
chan configure $fd -translation binary
set data [read $fd]
close $fd
if {$data == "" } {
    puts "Bad file with certificate=$file"
    usage 1
    exit
}

Здесь все понятно и отметим только одно – файл с сертификатом рассматривается как бинарный файл:

chan configure $fd -translation binary

Это связано с тем, что сертификат может хранится как в формате DER (двоичный код), так и в формате PEM (base64 — кодировка).

После того как файл загружен вызывается процедура chainfromcert:

set depth [chainfromcert $data $dir]

которая собственно и загружает корневые сертификаты:

proc chainfromcert {cert dir} {
    if {$cert == "" } {
	exit
    }
    set asndata [cert_to_der $cert]
    if {$asndata == "" } {
#Файл содержит все что угодно, только не сертификат
	return -1
    }
    array set cert_parse [::pki::x509::parse_cert $asndata]
    array set extcert $cert_parse(extensions)
    if {![info exists extcert(1.3.6.1.5.5.7.1.1)]} {
#В сертификате нет расширений
	return 0
    }
    set a [lindex $extcert(1.3.6.1.5.5.7.1.1) 0]
#    if {$a == "false"} {
#	puts $a
#    }
#Читаем ASN1-последовательность расширения в Hex-кодировке
    set b [lindex $extcert(1.3.6.1.5.5.7.1.1) 1]
#Переводим в двоичную кодировку
    set c [binary format H* $b]
#Sequence 1.3.6.1.5.5.7.1.1
    ::asn::asnGetSequence c c_par_first
#Цикл перебора значений в засширении 1.3.6.1.5.5.7.1.1
    while {[string length $c_par_first] > 0 } {
#Выбираем очередную последовательность (sequence)
	::asn::asnGetSequence c_par_first c_par
#Выбираем oid из последовательности
	::asn::asnGetObjectIdentifier c_par c_type
	set tas1 [::pki::_oid_number_to_name $c_type]
#Выбираем установленное значение
	::asn::asnGetContext c_par c_par_two
#Ищем oid с адресом корневого сертификата
	if {$tas1 == "1.3.6.1.5.5.7.48.2" } {
#Читаем очередной корневой сертификат
	    set certca [readca $c_par $dir]
	    if {$certca == ""} {
#Прочитать сертификат не удалось. Ищем следующую точку с сертификатом
		continue
	    } else {
		global count
#Сохраняем корневой сертификат в указанном каталоге
		set f [file join $dir [file tail $c_par]]
		set fd [open $f w]
		chan configure $fd -translation binary
		puts -nonewline $fd $certca 
		close $fd
		incr count
		puts "cert $count from $c_par"
#ПОДЫМАЕМСЯ по ЦЕПОЧКЕ СЕРТИФИКАТОВ ВВЕРХ
		chainfromcert $certca $dir
		continue
	    }
	} elseif {$tas1 == "1.3.6.1.5.5.7.48.1" } {
#	    puts "OCSP server (oid=$tas1)=$c_par"
	}
    }
# Цепочка закончилась
    return $count
}

К комментариям добавить нечего, но у нас осталась не рассмотренной процедура readca:

proc readca {url dir} {
    set cer ""
#Читаем сертификат в бинарном виде
    if {[catch {set token [http::geturl $url -binary 1]
#получаем статус выполнения функции
	set ere [http::status $token]
	if {$ere == "ok"} {
#Получаем код возврата с которым был прочитан сертификат
	    set code [http::ncode $token]
	    if {$code == 200} {
#Сертификат успешно прочитан и будет созвращен
                set cer [http::data $token]
    	    } elseif {$code == 301 || $code == 302} {
#Сертификат перемещен в другое место, получаем его 
         		set newURL [dict get [http::meta $token] Location]
#Читаем сертификат с другого сервера
          		set cer [readca $newURL $dir]
    	    } else {
#Сертификат не удалось прочитать
        	set cer ""
    	    }
        } 
    } error]} {
#Сертификат не удалось прочитать, нет узла в сети
	set cer ""
    }
    return $cer
}

Это процедура построена на использовании пакета http:

package require http

Для чтения сертификата мы используем следующую функцию:

set token [http::geturl $url -binary 1]

Назначение остальных используемых функции понятно из комментариев. Дадим только расшифровку кодов возврата для функции http::ncodel:

200 Запрос успешно выполнен
206 Запрос успешно выполнен, но удалось скачать только часть файла
301 Файл перемещен в другое место
302 Файл временно перемещен в другое место
401 Требуется аутентификация на сервере
403 Доступ к этому ресурсу запрещен
404 Указанный ресурс не может быть найден
500 Внутренняя ошибка

Осталось не рассмотренной одна процедура, а именно cert_to_der:

proc cert_to_der {data} {
    set lines [split $data n]
    set hlines 0
    set total 0
    set first 0
#Ищем PEM-сертификат в файле
    foreach line $lines {
        incr total
        if {[regexp {^-----BEGIN CERTIFICATE-----$} $line]} {
            if {$first} {
                incr total -1
                break
            } else {
                set first 1
                incr hlines
            }
        }        
        if {[regexp {^(.*):(.*)$} $line ]} {
            incr hlines
        } 
    }
    if { $first == 0 && [string range $data 0 0 ] == "0" } {
#Очень похоже на DER-кодировку "0" == 0x30 
	return $data
    }
    if {$first == 0} {return ""}
    set block [join [lrange $lines $hlines [expr {$total-1}]]]
#from PEM to DER
    set asnblock [base64::decode $block]
    return $asnblock
}

Схема процедуры очень простая. Если это PEM-файл с сертификатом («—–BEGIN CERTIFICATE—– »), то выбирается тело этого файла и преобразуется в бинаоный код:

set asnblock [base64::decode $block]

Если это не PEM-файл, то проверяется это «похожесть» на asn-кодировку (нулевой бит должен быть равен 0x30).

Вот собственно и все, осталось добавить завершающие строки:

if {$depth == -1} {
    puts "Bad file with certificate=$file"
    usage 1
    exit
}
puts "Goodby!nLength chain=$depth"
usage 0
exit

Теперь все собираем в один файл с именем

Проверить работу этого файла можно с помощью интерпретарора tclsh:

$ tclsh ./chainfromcert.tcl cert_orlov.der /tmp 
Loading file: cert_test.der 
Directory for chain: /tmp 
cert 1 from http://ca.ekey.ru/cdp/ekeyUC2021.cer 
cert 2 from http://reestr-pki.ru/cdp/guc_gost12.crt 
Goodby! 
Length chain=2 
Copyright(C) 2021 
$

В результате работы мы получили цепочку из двух сертификатов в каталоге /tmp.

Но мы хотели получить выполняемые модули для платформ Linux и Windowsи и чтобы пользователи не задумывались о каких-то интерпретаторах.

Для этой цели мы воспользуемся утилитой freewrapTCLSH. С помощью этой утилиты мы сделаем выполняемые модули нашей утилиты для платформ Linux и Windows как 32-х разрядных так и 64-х. Сборку утилит можно проводить для всех платформ на любой из платформ. Извините за тавтологию. Я буду собирать на linux_x86_64 (Mageia).

Для сборки потребуется:

1. Утилита freewrapTCLSH для платформы linux_x86_64;
2. Файл freewrapTCLSH с этой утилитой для каждой платформы:
— freewrapTCLSH_linux32
— freewrapTCLSH_linux64
— freewrapTCLSH_win32
— freewrapTCLSH_win64
3. Исходный файл нашей утилиты: chainfromcert.tcl

Итак, собираемый выполняемый файл chainfromcerty_linuxx86 для платформы Linux x86:

$freewrapTCLSH chainfromcert.tcl –w freewrapTCLSH_linux32 –o chainfromcerty_linuxx86
$

Сборка утилиты для платформы Windows 64-х битного выглядит так:

$freewrapTCLSH chainfromcert.tcl –w freewrapTCLSH_win64 –o chainfromcerty_win64.exe
$

И т.д. Утилиты готовы к использованию. Все необходимое для их работы они вобрали в себя.

Аналогичным образом пишется код и на Python-е.

В ближайшие дни я думаю дополнить пакет fsb795 (а он написан на Python-е) функцией получения цепочки корневых сертификатов.

Чтобы браузер мог аутентифицировать веб-сайт, тот представляет себя действительной цепочкой сертификатов. Типичная цепочка показана сверху, в ней может быть больше одного промежуточного сертификата. Минимальное количество сертификатов в действительной цепочке равно трём.

Корневой сертификат — сердце центра сертификации. Он буквально встроен в вашу ОС или браузер, он физически присутствует на вашем устройстве. Его не поменяешь со стороны сервера. Нужно принудительное обновление ОС или встроенного ПО на устройстве.

Специалист по безопасности Скотт Хельме (Scott Helme) пишет, что основные проблемы возникнут у центра сертификации Let’s Encrypt, потому что сегодня это самый популярный ЦС в интернете, а его корневой сертификат скоро «протухнет». Смена корня Let’s Encrypt назначена на 8 июля 2020 года.

Конечные и промежуточные сертификаты удостоверяющего центра (CA) доставляются клиенту с сервера, а корневой сертификат у клиента уже есть, поэтому с помощью этой коллекции сертификатов можно построить цепочку и аутентифицировать веб-сайт.

Проблема заключается в том, что у каждого сертификата есть срок действия, после чего он нуждается в замене. Например, с 1 сентября 2020 года в браузере Safari планируют ввести ограничение на срок действия серверных TLS-сертификатов максимум 398 дней.

Это значит, что всем нам придётся заменять серверные сертификаты по крайней мере каждые 12 месяцев. Это ограничение распространяется только на сертификаты сервера, оно не распространяется на корневые сертификаты CA.

Сертификаты CA регулируются другим набором правил, поэтому имеют разные ограничения на срок действия. Очень часто встречаются промежуточные сертификаты со сроком действия 5 лет и корневые сертификаты со сроком службы даже 25 лет!

С промежуточными сертификатами обычно нет проблем, потому что они поставляются клиенту сервером, который сам гораздо чаще меняет свой собственный сертификат, так что просто в ходе этой процедуры заменяет и промежуточный. Его довольно легко заменить вместе с сертификатом сервера, в отличие от корневого сертификата CA.

Как мы уже говорили, корневой CA встроен непосредственно в само клиентское устройство, в ОС, в браузер или другое программное обеспечение. Изменение корневого CA веб-сайт не может контролировать. Здесь требуется обновление на клиенте, будь то обновление ОС или софта.

Некоторые корневые CA существуют уже очень давно, речь о 20-25 годах. Скоро некоторые из самых старых корневых CA приблизятся к концу своей естественной жизни, их время почти истекло. Для большинства из нас это вообще не будет проблемой, потому что CA создали новые корневые сертификаты, и они уже много лет распространяются по всему миру в обновлениях ОС и браузеров. Но если кто-то очень давно не обновлял ОС или браузер, это своего рода проблема.

Такая ситуация возникла 30 мая 2020 года в 10:48:38 GMT. Это точное время, когда протух корневой сертификат AddTrust от центра сертификации Comodo (Sectigo).

Он использовался для перекрёстной подписи, чтобы обеспечить совместимость с устаревшими устройствами, в хранилище которых нет нового корневого сертификата USERTrust.

К сожалению, проблемы возникли не только в устаревших браузерах, но и в небраузерных клиентах на базе OpenSSL 1.0.x, LibreSSL и GnuTLS. Например, в телевизионных приставках Roku, сервисе Heroku, в приложениях Fortinet, Chargify, на платформе .NET Core 2.0 под Linux и многих других.

Предполагалось, что проблема затронет только устаревшие системы (Android 2.3, Windows XP, Mac OS X 10.11, iOS 9 и т.п.), поскольку современные браузеры могут задействовать второй корневой сертификат USERTRust. Но по факту начались сбои в сотнях веб-сервисов, которые использовали свободные библиотеки OpenSSL 1.0.x и GnuTLS. Безопасное соединение перестало устанавливаться с выводом ошибки об устаревании сертификата.

Ещё один хороший пример предстоящей смены корневого CA — центр сертификации Let’s Encrypt. Ещё

в апреле 2021 года

они планировали перейти с цепочки Identrust на собственную цепочку ISRG Root, но этого

не произошло

.

«Из-за опасений по поводу недостаточного распространения корня ISRG на устройствах Android мы решили перенести дату перехода к собственному корню с 8 июля 2021 года на 8 июля 2020 года», — сказано в официальном сообщении Let’s Encrypt.

Дату пришлось перенести из-за проблемы, которую называют «распространением корня» (root propagation), а точнее, отсутствием распространения корня, когда корневой CA не слишком широко распространён на всех клиентах.

Сейчас Let’s Encrypt использует перекрёстно подписанный промежуточный сертификат с цепочкой до корня IdenTrust DST Root CA X3. Этот корневой сертификат был выдан ещё в сентябре 2000 года и истекает 30 сентября 2021 года. До этого времени Let’s Encrypt планирует перейти на собственный самоподписанный корень ISRG Root X1.

Корень ISRG выпущен 4 июня 2021 года. После этого начался процесс его утверждения в качестве центра сертификации, который завершился 6 августа 2021 года. С этого момента корневой CA был доступен всем клиентам через обновление операционной системы или программного обеспечения. Всё, что нужно было сделать, — это установить обновление.

Но в этом и проблема.

Если ваш мобильный телефон, телевизор или другое устройство не обновлялось два года — как оно узнает о новом корневом сертификате ISRG Root X1? А если его не установить в системе, то все серверные сертификаты Let’s Encrypt ваше устройство признает недействительными, как только Let’s Encrypt перейдёт на новый корень. А в экосистеме Android много устаревших устройств, которые давно не обновлялись.

Экосистема Android

Вот почему Let’s Encrypt отложил переход к собственному корню ISRG и всё ещё использует промежуточное звено, которое спускается к корню IdenTrust. Но переход в любом случае придётся сделать. И датой смены корня назначено 8 июля 2020 года.

Для проверки, что на вашем устройстве (телевизор, приставка или другой клиент) установлен корень ISRG X1, откройте тестовый сайт https://valid-isrgrootx1.letsencrypt.org/. Если не появляется предупреждение безопасности, то обычно всё в порядке.

Let’s Encrypt не единственный, кому предстоит решить проблему с переходом на новый корень. Криптографию в интернете начали использовать чуть более 20 лет назад, так что как раз сейчас наступает момент окончания действия многих корневых сертификатов.

С такой проблемой могут столкнуться владельцы умных телевизоров, которые много лет не обновляли программное обеспечение Smart TV. Например, новый корень GlobalSign R5 Root выпущен в 2021 году, и после некоторые старые Smart TV не могут построить цепочку к нему, потому что этот корневой CA у них просто отсутствует. В частности, эти клиенты не могли установить защищённое соединение с сайтом bbc.co.uk. Чтобы решить проблему, админам BBC пришлось пойти на хитрость: они построили для этих клиентов альтернативную цепочку через дополнительные промежуточные сертификаты, задействуя старые корни R3 Root и R1 Root, которые ещё не протухли.

www.bbc.co.uk (Leaf)
GlobalSign ECC OV SSL CA 2021 (Intermediate)
GlobalSign Root CA - R5 (Intermediate)
GlobalSign Root CA - R3 (Intermediate)

Это временное решение. Проблема никуда не уйдёт, если не обновить клиентское ПО. Умный телевизор — это по сути ограниченный в функциональности компьютер под Linux. И без обновлений его корневые сертификаты неизбежно протухнут.

Это касается всех устройств, не только телевизоров. Если у вас любое устройство, которое подключено к интернету и которое рекламировали как «умный» девайс, то проблема с протухшими сертификатами почти наверняка касается его. Если устройство не обновляется, то корневое хранилище CA со временем устареет, и в конечном итоге проблема всплывёт на поверхность. Как скоро возникнет проблема, зависит от времени последнего обновления корневого хранилища. Это может быть за несколько лет до даты реального выпуска устройства.

Кстати, в этом проблема, почему некоторые крупные медиаплатформы не могут использовать современные автоматизированные центры сертификации типа Let’s Encrypt, пишет Скотт Хельме. Для умных ТВ они не подходят, и количество корней слишком мало, чтобы гарантировать поддержку сертификата на устаревших устройствах. В противном случае ТВ просто не сможет запустить современные стриминговые сервисы.

Последний инцидент с AddTrust показал, что даже крупные IT-компании бывают не готовы к тому, что у корневого сертификата заканчивается срок действия.

Решение проблемы только одно — обновление. Разработчики умных устройств должны заранее обеспечить механизм обновления программного обеспечения и корневых сертификатов. С другой стороны, производителям невыгодно обеспечивать работу своих устройств по окончании срока гарантии.