Старые смартфоны PlayStation 3 могут потерять доступ в Интернет; Инструкция по установке и использованию Windows XP;

Что делать, если сайт не открывается на старом компьютере или телефоне?

Решить проблему можно или установкой свежего программного обеспечения (ПО), или покупкой современного устройства. Установить свежее ПО на старую технику не всегда возможно, но зато современные устройства под управлением актуальных операционных систем Windows, iOS, Linux, Android не подвержены описываемой проблеме, так как централизованно обновляются и всегда работают с актуальным списком сертификатов безопасности. Так что обновление техники и программного обеспечения — это наилучший способ даже не знать о существовании такой беды, как невозможность открыть некоторый сайт в браузере из-за проблем с сертификатом безопасности. К тому же, обновление всегда дает значительные преимущества в плане скорости и комфорта работы. Но, к сожалению, обновление техники по совершенно разным причинам доступно  далеко не каждому.

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

К примеру, компания Microsoft прекратила поддержку Windows XP еще в 2005 году (в 2009 году для 64-битной версии, в 2014 — расширенную поддержку, в 2019 — поддержку версии для банкоматов). Поддержка все еще популярной Windows 7 прекращена в 2015 году, расширенная поддержка — в 2020 году.

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

Не совсем по теме

К слову сказать, в качестве небольшого отступления, на тех предприятиях, где я занимаюсь обслуживанием компьютерной техники, на данный момент использование компьютеров более чем 10-летней давности доходит местами до 50%, из них почти половина работает под управлением Windows XP. И это если не считать компьютеры в составе технологического оборудования на производстве. В целом, в моей практике, приходится сталкиваться примерно с 20-30% компьютеров под управлением Windows XP, 50-70% — Windows 7 и 20-30% — Windows 10. Иногда встречаются Windows 8 и Windows 8. 1, а вот Mac и Linux — реально единицы.

Как заставить сайты открываться на старых компьютерах и в старых версиях браузеров?

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

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

Ручное обновление корневых сертификатов

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

Это лишь вариант описания ошибки, текст сообщения о невозможности установки защищенного соединения может быть и другим. Некоторые сервера, например, пишут о возможном несоответствии системного времени на компьютере с реальным временем. Причина заключается в истечении срока действия корневого цифрового сертификата IdenTrust DST Root CA X3, которым подписаны сертификаты от популярного удостоверяющего центра Let’s Encrypt. Им выпущено множество SSL сертификатов (более чем для 250 миллионов доменных имен) для веб-сайтов, почтовых серверов и других служб.

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

• Android 7.1.1 и старше;
• Mozilla Firefox до 50.0;
• MacOS 10.12.0 и старше;
• Windows XP (включая Service Pack 3);
• OpenSSL 1.0.2 и ниже;
• Ubuntu до версии 16.04;
• Debian 8 и старше.

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

Установка корневого сертификата в ОС Windows, iOS, Linux, Android

Итак, вариант первый. Сразу скажу, что этот вариант я пробовал только на виртуальной машине с Windows XP, и он сработал только частично. Описание варианта взято здесь.

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

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

В Linux необходимо сначала удалить старый корневой сертификат DST Root CA X3 из списка доверенных, для чего надо переместить его в директорию /etc/pki/ca-trust/source/blacklist, а затем установить доверие к корневому сертификату ISRG Root X1, для чего перенести его в директорию /etc/pki/ca-trust/source/anchors directory. После этих манипуляций надо обновить списки сертификатов командой update-ca-trust. Это один из способов. Подробности здесь.

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

Дополнение: способ обновления сертификатов на телевизорах LG поду управлением WebOS описан в отдельной статье.

Обновление всех сертификатов безопасности на старых версиях Windows

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

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

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

Быстрый и простой способ обновления сертификатов Windows

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

Описание метода взято с этого ресурса, за что выражаю автору огромную благодарность.

• rvkroots_20211001.exe — самораспаковывающийся архив со списком устаревших небезопасных сертификатов, автоматически удаляет эти сертификаты из списка доверенных при запуске файла;
• rootsupd_20211001.exe — самораспаковывающийся архив со списком актуальных сертификатов, автоматически добавляет эти сертификаты в соответствующие хранилища сертификатов при запуске файла.

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

Обновление сертификатов проверено на нескольких компьютерах под управлением операционных систем Windos XP SP 3 и Windows 7.

Как еще можно открывать сайты на старых компьютерах и смартфонах?

Для браузеров на основе движка Chromium (а это почти все популярные браузеры, в том числе Opera, Microsoft Edge, Яндекс Браузер и прочие) в сети встречаются рекомендации по сбросу настроек HSTS для отдельных сайтов. Для этого надо в адресной строке браузера набрать команду chrome://net-internals/#hsts и на открывшейся странице настроек ввести адреса нужных сайтов в раздел Delete domain security policies. На практике эту рекомендацию я не проверял.

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

Инструкция по обновлению сертификатов Let’s Encrypt на ТВ LG под управлением WebOS 3. 5 или новее

• Сам телевизор, подключенный к интернету любым способом (WiFi или кабель)
• Компьютер, подключенный к той же локальной сети, что и телевизор
• Программа для подключения по протоколу Telnet или SSH, например, PuTTY

Также узнайте версию WebOS, установленную на ТВ — от нее будут зависеть некоторые дальнейшие действия. Узнать версию можно в меню Настройки -> Расширенные настройки -> Общие -> Сведения о телевизоре -> Информация о телевизоре. Будьте внимательны: на шаге «Сведения о телевизоре» высветится поле «Версия ПО», но это не то, что нам нужно. Версия операционной системы будет в поле «Версия телевизора webOS» и будет выглядеть примерно так: 3. 0-62906.

Получаем root-права

Для того, чтобы иметь возможность что-то исправлять в файловой системе или программном коде телевизора, нам необходимо получить так называемые root-права, то есть права на полный доступ к установленной операционной системе. Без этого ничего сделать с сертификатами мы не сможем.

Коротко о рут-правах

Многие устройства для повседневного использования работают под управлением заложенного в них производителем программного обеспечения (ПО). Как правило, доступ пользователя к программному обеспечению устройства не предусматривается, не говоря уже о возможности его изменения. По этой причине производители всячески стараются защитить устройство от редактирования, а иногда даже и от просмотра его программной начинки. Но в некоторых случаях, например, сервисным инженерам при ремонте прибора требуется полный доступ к ПО. По своей сути, получение root-прав или рутирование устройства — это получение полного доступа к заложенному в нем ПО с возможностью его изменения. В связи с усилиями производителей по защите устройств от взлома получение рут-прав обычно не отличается простотой и зачастую использует найденные уязвимости в защите системы.

В интернете можно найти несколько способов получения root-прав для разных версий WebOS, но самый простой с точки зрения малоподготовленного пользователя — это использование уже готового инструмента. В моем случае это был rootmy. tv, почитать о нем можно здесь (описание на английском). Итак, приступаем:

После этих действий запустится автоматическое получение рут-прав, описание текущих стадий будет отображаться на экране. В процессе работы телевизор будет один или два раза перезагружен. В редких случаях ТВ вместо перезагрузки может выключиться, тогда его надо просто снова включить пультом. Вместе с получением рут-прав на ТВ будет также установлено приложение Homebrew Channel.

Подключаемся к ТВ с компьютера по протоколу SSH

Теперь мы можем управлять нашим ТВ с компьютера. Чтобы получить к нему доступ, делаем следующее:

• Запускаем программу PuTTY на компьютере, подключенном к той же сети, что и ТВ (программу скачиваем здесь).
• Вводим в поле Host Name (or IP address) адрес нашего ТВ, выбираем Connection type SSH (если после получения рут-прав не отключали протокол Telnet на ТВ, то можно выбрать Other — Telnet).
• Нажимаем кнопку Open.

Откроется окно терминала, в котором можно вводить команды для управления телевизором. Первым делом при подключении по SSH необходимо ввести имя пользователя и пароль. По умолчанию после получения рут-прав через rootmy. tv имя пользователя root, пароль alpine. При вводе пароля нажимаемые символы не отображаются, даже в виде «звездочек». Подтверждение набора осуществляем клавишей Enter.

Обновляем сертификаты безопасности на ТВ

Теперь пошагово в терминале PuTTY задаем приведенные ниже команды и подтверждаем каждую нажатием клавиши Enter. Для ускорения работы и исключения ошибки в написании команд рекомендую полностью копировать текст команды и вставлять его в терминал. Копировать можете любым удобным вам способом (например, Ctrl+V), а вставлять в окно терминала нужно нажатием правой кнопки мыши, так как клавиатурные сокращения в нем не работают. По возможности буду приводить описание действия каждой команды.

Создаем на ТВ новую папку для размещения сертификатов

Копируем все содержимое папки /etc/ в нашу папку

cp -a /etc/ /media/cryptofs/root/

Копируем также папку с сертификатами в нашу папку

Если у вас версия WebOS от 3. 5 до 3. 9 включительно, то копируем отдельно сертификаты браузера. Для других версий WebOS это делать не нужно

Запускаем текстовый редактор vi и открываем в нем файл со списком сертификатов

vi /media/cryptofs/root/etc/ca-certificates. conf

После этого на экране терминала отобразится содержимое файла ca-certificates. conf, а именно список установленных на устройстве сертификатов. Редактирование содержимого ведется почти как в обычном текстовом редакторе, но есть и отличия.

Работа с редактором vi. Прочитайте, если раньше не работали с ним!

Чтобы лучше разобраться с особенностями редактора vi, прочтите небольшую инструкцию. Скорее всего, она вам не понадобится, просто запомните основные действия:

• для перемещения по тексту и прокрутки экрана используем клавиши со стрелками;
• подведя курсор к нужному месту, входим в режим редактирования, нажав клавишу i;
• печатаем нужный текст;
• для выхода из режима редактирования с сохранением надо нажать Esc, а затем ZZ (два раза клавишу z с шифтом);
• для выхода без сохранения нажимаем Esc, затем клавишу : (двоеточие, нажимаем с шифтом, иначе введем точку с запятой), затем q (уже без шифта) и Enter.

Находим в тексте строку DST_Root_CA_X3. crt, переводим курсор в ее начало, нажимаем i для входа в режим редактирования и ставим перед строкой восклицательный знак (должно получиться !DST_Root_CA_X3. crt). Это означает, что сертификат не будет использоваться. Обратите внимание, что некоторые другие сертификаты тоже обозначены восклицательным знаком, то есть уже устарели.

Переходим в конец любой строки, нажимаем Enter для ввода новой строки и в ней печатаем:

Редактирование файла закончено, нажимаем Esc и ZZ для сохранения и выхода из редактора.

Скачиваем из интернета новый сертификат безопасности и помещаем его в нашу папку с сертификатами

Подключаем наши новые папки вместо старых

Задаем команду для принудительного обновления сертификатов

Если у вас версия WebOS от 3. 5 до 3. 9 включительно, то:

переходим в папку с сертификатами браузера

удаляем старый сертификат

rm DST_Root_CA_X3. crt

закачиваем в папку новый сертификат

Теперь нужно отредактировать скрипт, который выполняется каждый раз при включении ТВ. Для этого снова используем редактор vi

vi /media/cryptofs/apps/usr/palm/services/com. palmdts. devmode. service/start-devmode

Устанавливаем курсор клавишами со стрелками  после строки /bin/bash или в другое выбранное место скрипта (подробности под спойлером), нажимаем i для входа в режим редактирования и добавляем код:

Куда именно вставлять код?

Будьте внимательны: при получении рут-прав через rootmy. tv, отключении автообновлений системы и применении прочих настроек через приложение Homebrew Channel содержимое скрипта меняется. В частности, там могут присутствовать условные операторы ветвления if, и в зависимости от условия код в разных местах скрипта будет работать или игнорироваться. Поэтому необходимо правильно выбрать место для вставки команды на использование обновленных сертификатов.

Вставку новых команд желательно сделать перед строкой telnetd -l /bin/sh, но таких строк в скрипте может быть несколько. Поэтому можно либо вставить перед каждой найденной, либо найти нужную и вставить только перед ней. Или еще лучше — вставить команды до оператора if, сразу после строки /bin/bash.

Если у вас версия WebOS от 3. 5 до 3. 9 включительно, добавляем после указанных выше строк еще две:

Пример добавления строк

На скриншотах видно, что в скрипте имеются операторы ветвления, так что надо правильно выбрать место вставки. Например, в самом начале скрипта идет проверка на наличие файла-флага, используемого для восстановления работы ТВ при сбое в работе скрипта. Соответственно, команды между строками if и else будут выполнены только в случае сбоя.

Вставленные команды будут срабатывать при каждом включении телевизора и монтировать созданные нами папки с сертификатами в качестве стандартных системных папок.

Не забываем сохранить изменения в скрипте и выйти из редактора vi нажатием последовательности Esc + ZZ.

Вводим команду на перезагрузку ТВ

После перезагрузки телевизора открываем на нем браузер и вводим адрес сайта, который раньше выдавал ошибку из-за просроченного сертификата безопасности. Если сайт открывается, поздравляю: все прошло удачно!

На тематических форумах, где обсуждалась описываемая проблема, встречаются рекомендации по установке еще двух сертификатов — ISRG_Root_X2. crt и Lets_Encrypt-R3. crt, но никто пока не сталкивался с тем, чтобы без них проблема не исчезала. Поэтому их не добавляем.

Если у вас возникают какие-то вопросы, почитайте источники, ссылки на которые приведены в начале статьи.

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

За время, прошедшее с момента написания этой статьи, у меня появилась новая информация о некоторых особенностях добавления сертификатов на телевизоры LG. Этой информацией я решил поделиться с читателями.

Дополнительная информация (добавлено 3. 2022)

После получения рут-прав через сервис rootmy. tv мой телевизор два раза переходил в режим восстановления. Оба раза это случалось после отключения электропитания. В режиме восстановления на экране ТВ каждые 15 секунд появляется сообщение

Failsafe mode! Open telnet and remove /var/luna/preferences/webosbrew_failsafe

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

Запускаете PuTTY и подключаетесь к ТВ через протокол Telnet (SSH в режиме восстановления не работает).

и жмете на Enter. Таким образом удаляется файл, служащий признаком режима восстановления.

и жмете на Enter. Телевизор перезагрузится, сообщение о режиме восстановления должно исчезнуть.

Можно также отключить режим восстановления через меню приложения Homebrew.

Также на некоторых моделях ТВ LG с версией WebOS 3. 9 и меньше невозможно найти и заменить сертификаты браузера. В результате команды, описанные в пунктах 3. 1 или 11. 1 этой статьи, выполняются с ошибкой и реальная замена сертификатов не происходит. Дело в том, что нужные папки создаются динамически только при запуске браузера, поэтому при закрытом браузере подменить сертификаты не удается. В качестве решения предлагается добавить в стартовый скрипт команду запуска браузера в скрытом режиме, что позволяет затем проделать вышеописанные манипуляции для подмены сертификатов.

То есть, если при выполнении пункта 3. 1 этой статьи вы получили сообщение об ошибке, то продолжайте выполнять остальные команды, а в пункте 11 самой первой командой вставьте

и потом все остальные, которые там приведены.

После этого перезапустите ТВ и повторите выполнение пунктов 3. 1 и 10 (со всеми подпунктами). Затем снова перезагрузите ТВ.

На практике данную рекомендацию я не проверял, сведения взяты из этого источника.

Root Certificates

Our roots are kept safely offline. We issue end-entity certificates to subscribers from the intermediates in the next section. For additional compatibility as we submit our new Root X2 to various root programs, we have also cross-signed it from Root X1.

• Active
  ISRG Root X1 (RSA 4096, O = Internet Security Research Group, CN = ISRG Root X1)
  Self-signed: der, pem, txtCross-signed by DST Root CA X3: der, pem, txt
• ISRG Root X1 (RSA 4096, O = Internet Security Research Group, CN = ISRG Root X1)
  Self-signed: der, pem, txtCross-signed by DST Root CA X3: der, pem, txt
• Self-signed: der, pem, txt
• Cross-signed by DST Root CA X3: der, pem, txt
• Active, limited availability
  ISRG Root X2 (ECDSA P-384, O = Internet Security Research Group, CN = ISRG Root X2)
  Self-signed: der, pem, txtCross-signed by ISRG Root X1: der, pem, txt
• ISRG Root X2 (ECDSA P-384, O = Internet Security Research Group, CN = ISRG Root X2)
  Self-signed: der, pem, txtCross-signed by ISRG Root X1: der, pem, txt
• Cross-signed by ISRG Root X1: der, pem, txt

We’ve set up websites to test certificates chaining to our active roots.

• ISRG Root X1
  ValidRevokedExpired
• Valid
• Revoked
• Expired
• ISRG Root X2
  ValidRevokedExpired

Under normal circumstances, certificates issued by Let’s Encrypt will come from “R3”, an RSA intermediate. Currently, issuance from “E1”, an ECDSA intermediate, is possible only for ECDSA subscriber keys for allowlisted accounts. In the future, issuance from “E1” will be available for everyone.

Our other intermediates (“R4” and “E2”) are reserved for disaster recovery and will only be used should we lose the ability to issue with our primary intermediates. We do not use the X1, X2, X3, and X4 intermediates anymore.

IdenTrust has cross-signed our RSA intermediates for additional compatibility.

• Active
• Active, limited availability
• Backup
• Retired

Cross Signing

Each of our intermediates represents a single public/private
key pair. The private key of that pair generates the signature for all end-entity
certificates (also known as leaf certificates), i. the certificates we issue
for use on your server.

Our RSA intermediates are signed by ISRG Root X1. ISRG Root X1 is widely trusted at this
point, but our RSA intermediates are still cross-signed by IdenTrust’s “DST Root CA X3”
(now called “TrustID X3 Root”) for additional client compatibility. The IdenTrust
root has been around longer and thus has better compatibility with older devices
and operating systems (e. Windows XP, Android 7). You can download “TrustID X3 Root” from
IdenTrust (or, alternatively,
you can download a copy from us).

Having cross-signatures means that each of our RSA intermediates has two
certificates representing the same signing key. One is signed by DST Root
CA X3 and the other is signed by ISRG Root X1. The easiest way to distinguish
the two is by looking at their Issuer field.

When configuring a web server, the server operator configures not only the
end-entity certificate, but also a list of intermediates to help browsers verify
that the end-entity certificate has a trust chain leading to a trusted root
certificate. Almost all server operators will choose to serve a chain including
the intermediate certificate with Subject “R3” and
Issuer “ISRG Root X1”. The recommended Let’s Encrypt client software,
Certbot, will make this configuration seamlessly.

Roots

Similar to intermediates, root certificates can be cross-signed, often to increase client
compatibility. Our ECDSA root, ISRG Root X2 was generated in fall 2020 and is the root
certificate for the ECDSA hierarchy. It is represented by two certificates: one that is
self-signed and one that is signed by ISRG Root X1.

All certificates signed by the ECDSA intermediate “E1” will come with a chain including an intermediate
certificate whose Subject is “ISRG Root X2” and whose Issuer is “ISRG Root X1”. Almost all server operators
will choose to serve this chain as it offers the most compatibility until ISRG Root X2
is widely trusted.

OCSP Signing Certificate

This certificate is used to sign OCSP responses for the Let’s Encrypt Authority
intermediates, so that we don’t need to bring the root key online in order to
sign those responses. A copy of this certificate is included automatically in
those OCSP responses, so Subscribers don’t need to do anything with it. It is
included here for informational purposes only.

Our newer intermediates do not have OCSP URLs (their revocation information is
instead served via CRL), so we have not issued an OCSP Signing Cert from ISRG Root X2.

Certificate Transparency

We are dedicated to transparency in our operations and in the certificates we
issue. We submit all certificates to Certificate Transparency
logs as we issue them. You can view all
issued Let’s Encrypt certificates via these links:

• Issued by Let’s Encrypt Authority X1
• Issued by Let’s Encrypt Authority X3
• Issued by E1
• Issued by R3

Корневые сертификаты

Наши корневые сертификаты хранятся в надёжном месте и недоступны онлайн. Мы выпускаем сертификаты для пользователей на основе промежуточных сертификатов из следующего раздела. Для дополнительной совместимости с новым Root X2 с различными корневыми хранилищами, мы также подписали его с Root X1.

• Активные
  ISRG Root X1 (RSA 4096, O = Internet Security Research Group, CN = ISRG Root X1)
  Самоподписанный: der, pem, txtКросс подписанный DST Root CA X3: der, pem, txt
• ISRG Root X1 (RSA 4096, O = Internet Security Research Group, CN = ISRG Root X1)
  Самоподписанный: der, pem, txtКросс подписанный DST Root CA X3: der, pem, txt
• Самоподписанный: der, pem, txt
• Кросс подписанный DST Root CA X3: der, pem, txt
• Действующий, с ограничениями
  ISRG Root X2 (ECDSA P-384, O = Internet Security Research Group, CN = ISRG Root X2)
  Самоподписанный: der, pem, txtКросс-подписанный ISRG Root X1: der, pem, txt
• ISRG Root X2 (ECDSA P-384, O = Internet Security Research Group, CN = ISRG Root X2)
  Самоподписанный: der, pem, txtКросс-подписанный ISRG Root X1: der, pem, txt
• Кросс-подписанный ISRG Root X1: der, pem, txt

Мы создали сайты для проверки цепочки сертификатов вплоть до активных корневых.

• ISRG Root X1
  ДействительныйОтозванныйСрок действия истёк
• Действительный
• Отозванный
• Срок действия истёк
• ISRG Root X2
  ДействительныйОтозванныйСрок действия истёк

Промежуточные сертификаты

Как правило, сертификаты, выпущенные Let’s Encrypt, создаются на основе “R3”, промежуточного RSA. В настоящее время выпуск сертификатов из “E1”, промежуточного ECDSA-сертификата, возможен только для ключей ECDSA из разрешенных аккаунтов. В будущем выпуск сертификатов из “Е1” будет доступен для всех.

Дополнительные промежуточные сертификаты (“R4” и “E2”) зарезервированы для восстановления после стихийных бедствий, и будут использованы только в том случае, если мы потеряем доступ к нашими основным межуточным сертификатам. Мы больше не используем промежуточные сертификаты X1, X2, X3 и X4.

IdenTrust кросс-подписал наши промежуточные сертификаты RSA для дополнительной совместимости.

• Активные
• Действующий, с ограничениями
• Резервное копирование
• Неиспользуемые

Каждый из наших промежуточных сертификатов представляет собой одну публичную/частную ключевую пару. Это позволяет всем основным браузерам принимать наши сертификаты с нашим же корневым сертификатом.

Кросс-подпись означает, что каждый из наших промежуточных сертификатов имеет два сертификата, представляющих один и тот же ключ подписи. Один подписан DST Root CA X3, другой подписан ISRG Root X1. Самый простой способ отличить их — посмотреть на поле “Issuer” (издатель).

При настройке web-сервера, администратор указывает не только листовые сертификаты, но и список промежуточных сертификатов. Это помогает браузеру проверить, входит ли листовой сертификат в цепочку доверия, ведущую к корневому сертификату. Почти все операторы серверов будут выбирать для обслуживания цепочку, включающую промежуточный сертификат с субъектом “R3” и издателем “ISRG Root X1”. Рекомендуемое клиентское программное обеспечение Let’s Encrypt, Certbot, выполнит эту задачу без затруднений.

Как и промежуточные сертификаты, корневые сертификаты могут быть кросс-подписаны, часто для увеличения клиентской совместимости. Наш корневой ECDSA-сертификат, ISRG Root X2 был создан осенью 2020 года и является корневым сертификатом для иерархии ECDSA. Он представлен двумя сертификатами: самоподписанным и подписанным ISRG Root X1.

Все сертификаты, подписанные промежуточным ECDSA-сертификатом “E1”, будут иметь цепочку с промежуточным сертификатом, у которого субъект “ISRG Root X2”, а издатель “ISRG Root X1”. Почти все сервера выберут для обслуживания эту цепочку, поскольку она обеспечивает наибольшую совместимость до тех пор, пока ISRG Root X2 не получит широкого доверия.

Сертификат подписания ответов OCSP

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

У наших новых промежуточных сертификатов нет OCSP URL-адресов (их информация об отзыве вместо этого используется CRL), поэтому мы не выпустили сертификат подписи OCSP от ISRG Root X2.

Прозрачность сертификата

В Let’s Encrypt мы в нацелены на прозрачность в наших процессах и в сертификатах, которые выпускаем. Мы записываем сертификаты в журнал Certificate Transparency сразу, как только выпускаем их. Все наши сертификаты доступны по ссылкам:

• Выпущены Let’s Encrypt Authority X1
• Выпущены Let’s Encrypt Authority X3
• Выпущены Е1
• Выпущены R3

Platforms that trust ISRG Root X1

Browsers (Chrome, Safari, Edge, Opera) generally trust the same root certificates as the operating system they are running on. Firefox is the exception: it has its own root store. Soon, new versions of Chrome will also have their own root store.

Platforms that trust DST Root CA X3 but not ISRG Root X1

These platforms would have worked up to September 2021 but will no longer
validate Let’s Encrypt certificates.

Known Incompatible

• Android < v2.3.6
• Nintendo 3DS
• Windows XP prior to SP3
  cannot handle SHA-2 signed certificates
• cannot handle SHA-2 signed certificates
• Java 8 < 8u101
• Windows Live Mail (2012 mail client, not webmail)
  cannot handle certificates without a CRL
• cannot handle certificates without a CRL
• PS3 game console

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

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

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

• Windows &gt;= XP SP3
• macOS (большинство версий)
• iOS (большинство версий)
• Android &gt;= v2.3.6
• Mozilla Firefox &gt;= v2.0
• Java 8 &gt;= 8u101
• Java 7 &gt;= 7u111
• NSS &gt;= v3.11.9
• Amazon FireOS (Silk Browser)
• Cyanogen &gt; v10
• Jolla Sailfish OS &gt; v1.1.2.16
• Kindle &gt; v3.4.1
• PS4 game console with firmware &gt;= 5.00

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

• Windows &gt;= XP SP3 (при условии, что производилось автоматическое обновление корневых сертификатов)
• Mozilla Firefox &gt;= 50.0
• Ubuntu &gt;= xenial / 16.04 (с установленными обновлениями)
• Java 8 &gt;= 8u141
• Java 7 &gt;= 7u151

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

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

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

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

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

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

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

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

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

curl: (60) server certificate verification failed.

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

• Ваша система доверяет ISRG Root X1
• Вы не пользуетесь устаревшей версией OpenSSL

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

Например, Ubuntu 16. 04 xenial и Debian 8 jessie доверяют ISRG Root X1, но при этом поставляются с OpenSSL 1. 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. 0 или новее.

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

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

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

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

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

Для тех случаев, когда используется совсем старый openssl (версии меньше 1. 1p и 1. 2d, но новее 0. 8m), или по иной причине не срабатывает метод с изъятием из доверенных сертификата DST Root CA X3, можно воспользоваться еще одним методом, предложенным в статье Scott’а Helme. Метод основан на том, что OpenSSL, начиная с версии 0. 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

Открыть скачанный файл, в открывшемся окне выбрать «Установить сертификат

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

Выбрать «Поместить все сертификаты в следующее хранилище», в диалоге выбора хранилища, открывающемся по кнопке «Обзор. «, выбрать «Доверенные корневые центры сертификации»:

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

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

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

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

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

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

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

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

Следующий — Let’s Encrypt

Ещё один хороший пример предстоящей смены корневого CA — центр сертификации Let’s Encrypt. Ещё в апреле 2019 года они планировали перейти с цепочки Identrust на собственную цепочку ISRG Root, но этого не произошло.

«Из-за опасений по поводу недостаточного распространения корня ISRG на устройствах Android мы решили перенести дату перехода к собственному корню с 8 июля 2019 года на 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 июня 2015 года. После этого начался процесс его утверждения в качестве центра сертификации, который завершился 6 августа 2018 года. С этого момента корневой CA был доступен всем клиентам через обновление операционной системы или программного обеспечения. Всё, что нужно было сделать, — это установить обновление.

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

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

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

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

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

www. bbc. uk (Leaf)
GlobalSign ECC OV SSL CA 2018 (Intermediate)
GlobalSign Root CA — R5 (Intermediate)
GlobalSign Root CA — R3 (Intermediate)

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

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

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

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

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

Что делать?

На некоторых устройствах Android могут возникать проблемы, поэтому Let’s Encrypt рекомендует пользователям Android (Lollipop) 5. 0 установить браузер Firefox: «Для встроенного браузера телефона Android список доверенных корневых сертификатов поступает из операционной системы, которая на этих старых телефонах устарела. Однако Firefox в настоящее время является уникальным среди браузеров — он поставляется со своим собственным списком доверенных корневых сертификатов».

Удалить настройки HSTS для Яндекс браузера, Edge, Opera, Амиго

Большинство браузеров построены на движке Chromium, среди них можно выделить:

• Microsoft Edge
• Яндекс браузер
• Opera
• Амиго

Так как у них движок такой же. как и у Google Chrome, то к ним будет применен и актуален такой же метод, что мы делали выше, а именно через удаление домена на специальной странице:

Как очистить или отключить HSTS в Firefox

По сравнению с Chrome, Firefox имеет несколько способов очистки или отключения настроек. Для начала автоматический метод.

Автоматический метод отключения HSTS в Mozilla

• Откройте Firefox и убедитесь, что все открытые вкладки или всплывающие окна закрыты.
• Нажмите Ctrl + Shift + H (или Cmd + Shift + H на Mac), чтобы открыть меню библиотеки .
• Найдите сайт, для которого вы хотите удалить настройки HSTS. Вы можете упростить для себя, используя панель поиска в верхнем правом углу.
• Как только вам удастся найти веб-сайт, для которого вы пытаетесь очистить настройки HSTS, щелкните по нему правой кнопкой мыши и выберите  Забыть об этом сайте . Это очистит настройки HSTS и другие кэшированные данные для этого конкретного домена.

Ручной метод для Firefox

Данный метод можно еще назвать методом очистки HSTS путем очистки настроек сайта.

• Откройте Firefox, нажмите на значок «Библиотека» и выберите «Журнал»
• Далее выберите пункт «Удалить историю»
• В окне «Удаление всей истории» установите в раскрывающемся меню «Диапазон времени» значение «Все». Затем разверните меню «Данные» и снимите все флажки, кроме «Настройки сайта»  и нажмите «Удалить сейчас», чтобы очистить все настройки сайта, включая настройки HSTS . Далее перезагрузите Firefox и посмотрите, была ли проблема решена при следующем запуске.

Windows 7

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

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

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

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

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

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

Срок действия корневого сертификата Let’s Encrypt истек. Миллионы устройств останутся без интернета

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

Решение проблемы

• DigiCert Assured ID Root CA
• GlobalSign Root CA

Для версии 6. 0 необходимы следующие сертификаты:

• Сertum Trusted Network CA
• Digicert Assured ID Root CA

Для их установки достаточно просто раcпаковать приложенный архив для 5. 0(Файл:Certificates for XP and Server 2003 2021-01-15. zip) или 6. 0 (Файл:Certificates for XP and Server 2003 2021-02-16 v6. zip) и установить сертификаты следующим способом:

• Запустить mmc.exe.
• В появившемся окне нажать кнопку «Добавить».
• Выбрать пункт «Сертификаты» и нажать кнопку «Добавить».
• Выбрать пункт «Учетной записи компьютера» и нажать «Далее»
• Выбрать пункт «Локальным компьютером» и нажать «Готово»
• Добавиться оснастка сертификаты. Открыть папку «Сертификаты (локальный компьютер)/Доверенные корневые центры сертификации/Сертификаты».
• Выбрать пункт меню «Действие» — «Все задачи» — «Импорт».
• Поочередно импортировать все требующиеся сертификаты.

Как добавить сертификат в Trusted Root?

Чтобы установить корневой сертификат , сделайте следующее: Сделайте правый щелчок по Trusted Root Certification Authorities, выберите All Tasks, после чего Import. Выберите корневой сертификат и щелкните Next

Как установить сертификат из браузера?

Установить скачанный сертификат в систему. Для этого нажмите сочетание кнопок Win +R и введите команду certmgr. msc — OK. В открывшемся центре сертификатов в Windows откройте вкладку «Доверенные корневые центры сертификации / сертификаты » — клик правой кнопкой мыши — выберите «Все задачи — импорт»

Как добавить сертификат в XP?

Выбрать пункт меню «Консоль» — » Добавить или удалить оснастку. В появившемся окне нажать кнопку » Добавить «. Выбрать пункт » Сертификаты » и нажать кнопку » Добавить «

Как добавить ISRG root X1 в доверенные сертификаты?

В приложении «Связка ключей» на Mac нажмите « Сертификаты » списке «Категория», затем дважды нажмите сертификате, который нужно проверить