30 сентября 2021 14:01:15 GMT оканчивается срок действия корневого сертификата IdenTrust DST Root CA X3.
Это событие достойно вашего внимания по той причине, что после наступления этого момента ряд устаревших систем перестанут доверять сертификатам, выпущенным центром сертификации Let’s Encrypt. С учётом того, что на текущий момент Let's Encrypt предоставляет бесплатные криптографические сертификаты примерно для 250 миллионов доменных имен, а "устаревшие системы" - это порой системы возрастом всего 5-6 лет, вряд ли окончание срока действия сертификата DST Root CA X3 пройдёт для всех гладко и незаметно. В чём причина, кого конкретно это затронет, и что можно сделать?
Немного теории и истории
Не углубляясь в детали, пару слов для неспециалистов, почему окончание срока действия сертификата DST Root CA X3 повлияет на сертификаты, выпущенные Let's Encrypt. У каждой системы, проверяющей сертификат на валидность, есть своё хранилище доверенных корневых сертификатов. Система при проверке будет доверять сертификатам, которые подписаны с использованием закрытого ключа одного из этих корневых сертификатов. Сами корневые сертификаты как правило имеют длительные сроки действия, меняются редко и не используются при формировании сертификатов конечного субъекта (в данном случае, сертификатов для доменных имен), вместо этого инфраструктура открытых ключей, предполагает использование цепочек доверия - корневые сертификаты применяются для подписания промежуточных сертификатов, а уже с использованием них подписываются сертификаты конечного субъекта (сертификаты для доменов). При этом, для того, чтобы система доверяла конечному сертификату, она должна быть способна проследить всю цепочку от этого сертификата до одного из корневых сертификатов, которым она доверяет.
После появления проекта Let's Encrypt, его корневой сертификат ISRG Root X1 (как и любой новый корневой сертификат) не мог быстро попасть в хранилища доверенных сертификатов заметного количества систем. При этом для успешного функционирования проекта выданным сертификатам с самого начала должно было доверять максимальное количество систем "из коробки" (без дополнительных действий со стороны пользователей этих систем). В связи с этим, для сертификатов Let's Encrypt стала использоваться цепочка доверия, ведущая к корневому сертификату DST Root CA X3, который признается большинством систем:
Windows >= XP SP3
macOS (большинство версий)
iOS (большинство версий)
Android >= v2.3.6
Mozilla Firefox >= v2.0
Ubuntu >= precise / 12.04
Debian >= squeeze / 6
Java 8 >= 8u101
Java 7 >= 7u111
NSS >= v3.11.9
Amazon FireOS (Silk Browser)
Cyanogen > v10
Jolla Sailfish OS > v1.1.2.16
Kindle > v3.4.1
Blackberry >= 10.3.3
PS4 game console with firmware >= 5.00
К настоящему моменту корневой сертификат 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 -> Конечный сертификат пользователя
Что произойдет 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.
Что со всем этим делать?
На стороне клиента
Linux
Для того, чтобы проверить, как поведёт себя ваша система при обращении к сайтам, использующим сертификаты Let's Encrypt, после 30 сентября, можно воспользоваться утилитой faketime. В Debian и Ubuntu она доступна в пакете faketime.
faketime -f '@2021-10-01 00:00:00' curl https://letsencrypt.org/
Если всё в порядке, 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.0.x, поэтому проблема их может коснуться.
Чтобы проверить наличие сертификата ISRG Root X1 в числе доверенных:
в Debian/Ubuntu:
awk -v cmd='openssl x509 -noout -subject' ' /BEGIN/{close(cmd)};{print | cmd}' < /etc/ssl/certs/ca-certificates.crt | grep "ISRG Root X1"
в CentOS:
awk -v cmd='openssl x509 -noout -subject' ' /BEGIN/{close(cmd)};{print | cmd}' < /etc/ssl/certs/ca-bundle.crt | grep "ISRG Root X1"
В выводе команды в обоих случаях должно присутствовать:
subject= /C=US/O=Internet Security Research Group/CN=ISRG Root X1
Если такой строчки нет, то нужно добавить ISRG Root X1 в доверенные. В Debian/Ubuntu:
curl -k https://letsencrypt.org/certs/isrgrootx1.pem.txt | sudo tee /usr/share/ca-certificates/mozilla/ISRG_Root_X1.crt
добавить в файл /etc/ca-certificates.conf строчку:
mozilla/ISRG_Root_X1.crt
и выполнить комнаду
sudo update-ca-certificates
Проверка версии OpenSSL
Если система доверяет ISRG Root X1, нужно проверить версию OpenSSL
openssl version
В выводе должна быть версия 1.1.0 или новее.
Если используется OpenSSL 1.0.x, то достаточным решением проблемы будет удалить из доверенных сертификат DST Root CA X3 (это решение может не сработать для openssl версий <1.0.1p и <1.0.2d). Это можно сделать, не дожидаясь 30 сентября.
В Debian/Ubuntu:
В файле /etc/ca-certificates.conf нужно найти строчку:
mozilla/DST_Root_CA_X3.crt
и поставить в начало сроки символ "!":
!mozilla/DST_Root_CA_X3.crt
Далее, необходимо выполнить команду:
sudo update-ca-certificates
В CentOS
Выполнить команды:
trust dump --filter "pkcs11:id=%c4%a7%b1%a4%7b%2c%71%fa%db%e1%4b%90%75%ff%c4%15%60%85%89%10" | openssl x509 | sudo tee /etc/pki/ca-trust/source/blacklist/DST-Root-CA-X3.pem
sudo update-ca-trust
Локальное продление срока действия сертификата 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 еще на три года можно выполнить следующие команды:
Debian/Ubuntu:
sudo sed -i "s/xMDkzMDE0MDExNVow/0MDkzMDE4MTQwM1ow/g" /etc/ssl/certs/DST_Root_CA_X3.pem
sudo update-ca-certificates
CentOS:
sudo sed -i "s/xMDkzMDE0MDExNVow/0MDkzMDE4MTQwM1ow/g" /etc/ssl/certs/ca-bundle.crt
sudo update-ca-trust
Не забудьте проверить так же все ваши контейнеры!!! У них свои хранилища корневых сертификатов и могут использоваться другие версии openssl
Windows
Для пользователей, у которых не подключены автоматические обновления корневых сертификатов, можно добавить сертификат ISRG Root X1 вручную. Для этого нужно скачать сертификат с сайта LetsEncrypt по ссылке https://letsencrypt.org/certs/isrgrootx1.der.
Открыть скачанный файл, в открывшемся окне выбрать "Установить сертификат...":
В мастере импорта сертификатов выбрать "Локальный компьютер":
Выбрать "Поместить все сертификаты в следующее хранилище", в диалоге выбора хранилища, открывающемся по кнопке "Обзор...", выбрать "Доверенные корневые центры сертификации":
На последнем шаге мастера нажать кнопку "Готово".
После выполнения этой последовательности шагов, сертификат должен появиться в защищенном хранилище. Чтобы проверить это, нужно нажать комбинацию клавиш «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 часть пользователей старых устройств столкнутся с тем, что не смогут корректно открывать сайты, использующие сертификаты Let's Encrypt. Я бы выделил в первую очередь пользователей старых устройств Apple, для которых нет возможности обновиться хотя бы на iOS 10. Кроме того, под раздачу могут попасть различные устройства IoT, старые телевизоры и подобные им устройства, для которых не существует обновлений с новыми корневыми сертификатами.
В то же время, для администраторов серверов с не очень современным софтом, которые могут взаимодействовать с сервисами, использующими сертификаты Let's Encrypt, еще есть несколько дней на то, чтобы всё проверить и подготовиться к часу X.
Update: Добавил важное дополнение про необходимость проверки всех используемых контейнеров
Update2: Добавил, как добавить ISRG Root X1 в доверенные сертификаты в Debian/Ubuntu, спасибо @Kenshouten
Update3: Еще один метод решения проблемы для старых OpenSSL, процедура по добавлению сертификата ISRG Root X1 в доверенные в Windows для тех, кто еще не разобрался
Комментарии (244)
Alexsey
27.09.2021 03:40+1Этот DST Root CA X3 это какая-то катастрофа. Я так и не смог заставить .net core на ubuntu 21.04 доверять сертификатам let's encrypt после того как его из ca-certificates убрали. Орет что недоверяет одному из сертификатов в цепочке и все. Пришлось накатывать предыдущую версию ca-certificates пока DST Root CA X3 не истечет.
Alexey2005
27.09.2021 03:49-51Только мне кажется, что пользователям от всей этой дебильной криптографии больше проблем, чем пользы? HTTPS по сравнению с простым HTTP защищает разве только от подмены пакетов провайдером, и то лишь до поры до времени. А вот проблем с этими уродскими сертификатами выше крыши.
youngmysteriouslight
27.09.2021 04:27+22Спрашиваю как человек с предметными знаниями чуть выше абсолютного нуля: разве HTTPS не предполагает шифрование пакетов, и почему подмена в конечном счёте возможна и реализуема?
HTTP, как я понимаю, абсолютно беззащитен перед любым агентом, который может вклиниться между клиентом и сервером.
DreamingKitten
27.09.2021 04:55-10и почему подмена в конечном счёте возможна и реализуема?
Возможна, но только в некоторых, очень отдельных случаях.
Такая вот штука есть, например -- https://www.telerik.com/fiddler (но не только она, есть и аналогичные решения)
Это, среди прочего, дебаггер HTTPS-сессий в виде сквозного прокси. Он подставляет самоподписанные сертификаты на целевой домен. Конечно же, такой сертификат не имеет цепочки доверия до корневого и браузер сразу покажет, что там что-то не то. Но для отладки сгодится (если воткнуть в доверенное хранилище сертификат самого fiddler или отключить проверку).
Также это прокатывает, если влазят в трафик не браузера, а какой-нибудь игры или клиентского приложения, которое общается с сервером по HTTPS. Разработчикам обычно влом реализовывать как certificate pinning, так и жалобы на отсутствие цепочки доверия.
bgBrother
27.09.2021 08:24+9Разработчикам обычно влом реализовывать как certificate pinning, так и жалобы на отсутствие цепочки доверия
Будет возможность перечислить несколько относительно популярных приложений или игр, которые пропускают MITM без уведомления или «падения»? Если о certificate pinning еще можно допустить, то о работе кода с отключенной проверкой цепочки доверия слова звучат не совсем убедительными.DreamingKitten
27.09.2021 10:45-2Во времена бурной молодости.... Ну то есть, до середины 2016 года примерно, разрабатывал я эмулятор Ingress путём реверса его протокола. Почти ничего сложного не было, там внутри такой себе json-rpc на стероидах. Но приходилось очень плотно сидеть в дебаггере https, на что клиент игры и ухом не моргнул, не смотря на то, что я никаких посторонних сертификатов ему не пихал.
bgBrother
27.09.2021 13:36+3Возможно, вы добавляли сертификаты в ПК или смартфон когда-либо ранее, перед работой с Ingress?
DreamingKitten
27.09.2021 13:43Вот вы спросили, и я уже засомневался :(
За давностью лет технических подробностей не помню, к сожалению. Может и добавлял. А может и нет, судя по тому, что я сейчас не знаю, как это делается.
farafonoff
27.09.2021 14:15+1В нынешнее время может не прокатить, набирает популярность ssl-pinning, а также всякая обфускация кода приложения, чтобы пиннинг нельзя было просто снять. Например Instagram применяет кастомный ssl стек, внутри которого ходит кастомный бинарный протокол.
BuCeFaL
27.09.2021 14:14Скорее всего там использовалась переменная окружения в windows SSLKEYLOGFILE которая сохраняет ключи во время рукопожатия, что позволяет дебагерам читать весь стрим. Это не MITM, так как дебагер на стороне, которой пакет и предназначался.
DreamingKitten
27.09.2021 14:19Нет, фиддлер в данном случае работал как HTTPS прокси, а запросы шли на сервер игры (не локальный)
hedger
01.10.2021 21:04Старый клиент никак и не боролся с чтением траффика. Но вот подменить что-либо существенное в исходящих пакетах, не словив бан, было нельзя из-за шифованного блоба с «подписью» пакета, clientBlob. Вот разломать его на порядок сложнее, чем поставить доверенный серт и mitm-ать траффик.
DreamingKitten
01.10.2021 21:32-1Про clientBlob я в курсе. Разломать его не удалось ни мне, ни минскому аэроклубу, евпочя. Это смогли только покемонщики.
Тем не менее, мой эмулятор более-менее успешно работал, подставляя рандомно один из ранее заснифаных клиент-блобов. Видимо, проверка валидности клиент-блоба была включена не на всех функциях, а только на самых критичных, типа чтения карты с произвольным cellID или транзакции с глифами. На остальных он до 2016 года не проверялся. А потом как начал :( И проект пришлось прикрыть.
hedger
01.10.2021 22:15У покемонов был другой блоб, ощутимо проще. А ингрессовский таки был разломан, и успешно эксплуатировался в определённых кругах до смерти апи старого сканера.
DreamingKitten
01.10.2021 22:23-2Мой эмуль был уникальным в том что он не через интел работал, а через betaspike API, то есть эмулил сам клиент :) Умел сам качаться, сносить, деплоить, поля крыть... Эх, времена.
MDSN650
29.09.2021 19:44Мобильный банкинг Белинвестбанка. Пример только один, но он непростителен для банковского приложения. Причем пароль передается в открытом виде, а не хотя бы хэш с солью.
Последний раз проверял году в 2019, тогда еще не было исправлено. Подозреваю и до сих пор не исправлено, но следует снова перепроверить.
MzCartman
29.09.2021 23:27Last Epoch из актуального. Умельцами под черным флагом альтернативная авторизация на серверах игры реализована как раз через Fiddler
iliar
27.09.2021 11:08+10То есть чтобы реализовать такую подмену нужно получить доступ к пользовательской системе и прописать сертификат фейкового центра сертификации в качестве корневого и доверенного. Встаёт вопрос, а почему бы тогда за одно ещё не поставить парукейлогеров и не настроить вебку вещать напрямую в оранжевый ютуб. Раз у нас уже есть доступ, то что мелочиться.
DreamingKitten
27.09.2021 11:14-9Я отвечал на вопрос, при каких условиях MITM с https может работать. То, что для этого требуется предварительный админский доступ к машине жертвы -- ну да, а вы чего ожидали? Готового эксплойта а-ля «Взломщик Интернета», что ли?
Нетхак он такой. На 99% состоит из эксплуатации человеческой тупости, и только на 1% -- из эксплуатации технических недостатков IT систем.
Aelliari
27.09.2021 15:52-1Или получить доступ к сертификату СА, который в доверенных по умолчанию. Менее реалистично, но возможно
Balling
30.09.2021 10:50-1Это невозможно так как их «нет», они в 7 нм чипе зашиты.
Aelliari
30.09.2021 13:29+1Категорически странное заявление. В каком чипе? Почему они там зашиты? Почему именно 7 нм? Чипе расположенном где? Кто имеет доступ к этому чипу? Вы наверняка можете гарантировать в рамках всех компаний занимающихся выпуском сертификатов выполняться все заявленные вами требования и никто, и ни при каких обстоятельствах не сможет получить доступ к приватному ключу сертификата?
Balling
30.09.2021 13:44-1Существуют правила. Root ключи держат отключенными от интернета в криптомодуле. Можно гарантировать, так как тибериумный реверсинг уничтожит чип.
Aelliari
30.09.2021 15:35Для начала, есть правило запрещающее переходить дорогу на красный свет, и?
Ну держат CA свои приватные ключи отдельно от интернета в криптомодуле, дальше что? Механизм взаимодействия есть, просто потому что их используют для подписи других сертификатов. Ты можешь гарантировать что завтра в офис не придут люди с автоматами и не потребуют доступа к модулю? Или просто, сотрудник получавший соответствующий доступ не подпишет какой то левый сертификат с своими, сомнительными целями?
Pas
30.09.2021 18:17Как минимум такие случаи были и в наше время выявляются достаточно быстро через тот же Transparency Log. Собственно, кейс с сертом гугла фактически показал, как быстро теряется доверие к CA. В будущем действующая иерархическая модель PKI может вообще исчезнуть, уступив место тому же DANE (там тоже есть иерархия, но на уровне DNS).
YouROK
27.09.2021 08:30-13Мне тоже эти https не очень. Да есть шифрование, но смысл от него, если провайдер захочет вставить прокси со своим сертификатом, то как я смогу отказаться от этого? Придется пользоваться и разрешать подмену.
В http сами авторы сайта делали шифрование своих данных, кто хотел. Я вот на своем простеньком сайте сделал логин и регистрацию через rsa и aes, кто-то сделает еще как-то, третий сделает своим способом. Чтобы сломать, нужно ломать каждого по отдельности, а https один раз сломать и всё открыто, авторы не заморачиваются с защитой и шифрованием, оно же есть
NikitaCartes
27.09.2021 10:12+9если провайдер захочет вставить прокси со своим сертификатом, то как я смогу отказаться от этого?
Перейти к другому провайдеру.
Lopar
27.09.2021 12:50+1Перейти к другому провайдеру.
Иногда для этого надо менять район проживания.
farafonoff
27.09.2021 14:16+10Лучше сразу страну
ScreamPassion
30.09.2021 18:03+2Подскажете на какую, и желательно чтоб с гарантией что ее тоже вскоре не придется менять)
Egor_Malashevsky
30.09.2021 18:21+2Простите, что я отвечаю, а не @farafonoff. Например, можно переехать в Исландию, Норвегию, Швецию, Швейцарию, Нидерланды, Польшу, Канаду, США и т.д.
ScreamPassion
01.10.2021 14:25Да неважно кто отвечает, важно какие гарантии что вскоре ее не придется менять, и на сколько эти гарантии. Вот кстати на счет сша я бы не был так уверен... Шестое чувство)
Egor_Malashevsky
01.10.2021 15:04Тогда куда-нибудь в страны Евросоюза. Или в Канаду. Не знаю, стоит ли оно того, но есть ещё возможность в страны Восточной Азии, например, Японию, Тайвань, Гонконг, Южную Корею. Хотя все же Европа лучше.
sashok724
27.09.2021 10:16+14Если провайдер (хотя скорее всего государство через провайдера) захочет вставить прокси со своим сертификатом, то это уже политическая проблема, а не техническая, решать которую надо тоже политическими методами, а не техническими.
vsb
27.09.2021 10:53+3Технически эту проблему тоже можно пытаться решать до определённого момента. Наглядный пример - Казахстан. Они проводили "учения" в рамках которых часть пользователей была подвергнута MITM-атаке. Популярные браузеры достаточно быстро заблокировали корневой сертификат, которым были подписаны подменённые ответы. Предположительно из-за этого данная инициатива дальше разовых акций не пошла, т.к. стало понятно, что в борьбе между казахстанским правительством и Google на данный момент победителя не будет.
Balling
30.09.2021 10:52Он и до бликировки не работал. Доверие не проходило.
vsb
30.09.2021 11:47До блокировки его можно было добавить в список доверенных согласно инструкциям на сайтах провайдеров. После блокировки это уже не помогало.
logran
04.10.2021 09:04В теории, согласно инструкциям провайдера можно и открывающий интернет «правильный» браузер на базе хромиума с сайта провайдера скачать, который не будет левый сертификат блокировать. Так что казахстанское правительство пока что просто не особо сильно хотело и старалось.
vsb
04.10.2021 10:46+1Пупок развяжется собирать и поддерживать правильные браузеры для всех платформ. Тем более, что там и Windows может начать помечать этот браузер, как вредоносное ПО, ОС тоже "правильную" собирать будем? Китай или РФ такое сможет провернуть, Казахстан, думаю, не сможет.
Anrikigai
05.10.2021 08:56Не браузером единым.
Facebook как приложение тоже поменяете? Или только через православный браузер смотреть всем придется?И обратите внимание, сколько у вас именно приложений на смартфоне лезут к своим серверам. Подавляющему большинству пофиг на вручную добавленные сертификаты, они знают свой собственный, и по цепочкам доверия лазить им никакой нужды нет.
Условно говоря, на сайт банка вы через браузер худо-бедно сможете зайти. Но вот с мобильным приложением (клиент-банк) облом выйдет.
cypma5
27.09.2021 12:20+2Это не так. Смотря что вы подразумеваете под один раз сломать.
Во первых есть наборы шифров которые не подвержены MITM атакам.
EDHE например.Если вы раскроете приватный ключ как владелец сайта это уже другой вопрос.
Напомню что у провайдеров стоят железки из ФСБ которые анализируют весь трафик. в случае https они видят куда вы ходите не видя содержимого. В случае http они видят всё.И я честный мне нечего скрывать тут не канает. У нас в стране за мемчики сажают, репосты, и смайлики
YouROK
27.09.2021 12:39Я думал про чебуреки и государственный сертификат. А неугодных банить. Слышал что уже и закон хотят или хотели выпустить для бана програм, впн тоже хотят банить, сайты уже банят. Все идет к чебурнету, там и государственный сертификат могут придумать. Хотя при таком раскладе шифрование будет уже меньшим из зол и сайты будут сами выдавать все логи по первому запросу, иначе бан.
Я в этой теме не сильно хорош, может и чушь написал и такое невозможно сделать чисто технически
Balling
30.09.2021 10:55Никто не банит VPN. Это невозможно, это как сказать забанить командную строку. Как они собируются банить VPN в локальной сети без Интернета вообще, например?
goldrobot
30.09.2021 20:57Китай справился с VPN. С огромным пингом и ограничением до 64кб/с даже ssh не сильно приятно использовать)
Balling
30.09.2021 22:501) Компании, которым нужен VPN это не ограничивают
2) Есть VPN и в китае, где скорость норм. Да и закона о VPN нет на самом деле. Это миф.goldrobot
30.09.2021 22:54Вы говорите о "зарегистрированном" VPN. Я не уверен что подконтрольный VPNы, это то что вы хотели бы использовать для задач, где вам он собственно и нужен.
vikarti
27.09.2021 14:56Не сможете вы разрешить подмену во многих случаях:
- кнопку "разрешить" потихоньку прячут.
- есть HSTS (и в том числе HSTS preload) — с ним кнопки просто не будет. вообще.
- разрешить методом установки указанного провайдером сертификата — а ничего что например на андроид начиная с 7 — куча ПО просто проигнорирует такую установку и будет вопить про неработу сети. Удачи провайдеру объяснять клиентам что это гугл виноват а не провайдер.
- если разработчики браузеров посчитают что в данном случае не провайдера идея а государственная и кто-то оборзел — в браузеры прилетит бан конкретного вот этого сертификата провайдера — см например https://www.opennet.ru/opennews/art.shtml?num=54284
Arioch
27.09.2021 17:00+2в браузеры прилетит бан конкретного вот этого сертификата
И будет провайдер раздавать своим клиентам не Хром, а Яндекс или Спутник, как когда-то делал AOL
Balling
30.09.2021 10:57Яндекс это же Chrome.
Arioch
30.09.2021 11:07+3Изменённый. Как и Спутник/Амиго.
В нём Яндекс много своего добавил - от своих около-поисковых штучек и пользовательского интерфейса типа "Я Табло", до более низкоуровневых штучек типа выделения-копирования текста ссылок, Opera Turbo и шифрование ГОСТ в TLS.
Добавит он в свою ветку (git branch) ещё одно изменение - удаление из исходников конкретного "бана конкретного сертификата" - и всё, можно раздавать.
P.S. а AOL Browser тоже не в America onLine разрабатывался, а был перекрашенным MSIE, а потом перекрашенным NN, так что я его не просто так напомнил.
Anrikigai
27.09.2021 23:00если провайдер захочет вставить прокси со своим сертификатом, то как я смогу отказаться от этого?
А вы только браузером пользуетесь? Никаких клиентов типа Яндекс.Диск, OneDrive и прочего?
Такого рода клиента обычно точно знают сертификат сервера, к которому подключаются, и не смотрят на вами формируемое хранилище доверенных УЦ. Даже не столько для борьбы с MITM, сколько им просто не нужна вся эта история с тем, что кто-то кому-то должен подтвердить доверие. Они верят зашитому в них корпоративному сертификату (фингерпринт и т.п.)
Так что отвалится слишком много чего. Особенно на мобильных устройствах.
richman1000000
27.09.2021 09:34+4Нет. HTTPS предлагает систему шифрования, а систему доверия предлагает PKI.
Вот с PKI и HTTPS взаимодействии как раз таки проблемка. PKI нужно обновлять постоянно, а HTTPS - это просто протокол
radroxx
27.09.2021 14:57+4А как это защитит от подмены сертификата людьми у которых есть доступ хотя бы к одному из удостоверяющих центров ?
Если у правительства или сотрудника удостоверяющего центра будет надобность не что не мешает выпустить и подписать такой же сертификат на любой домен (при том что прецедент уже был https://habr.com/ru/company/infopulse/blog/255251/), с любыми данными в полях но с другим приватным клюем и сделать MitM, единственно что будет не совпадать с оригиналом сертификата это хеш и цепочка доверия все остальное будет 1 в 1 и все будут ему доверять.
К тому же в СМИ не разу не говорили что какой-то из центров отказался выполнять решение суда и выпустить поддельный сертификат. И я уже молчу о том что некоторые центры в рамках удобного упрощения присылают сразу пару серт с ключиком 1-м архивом, и как то не кто не кричит налево и направо что это не безопасно и так делать нельзя в принципе, а отрыть мануал как правильно самостоятельно генерировать crt тот еще квест и куда потом его засылать на сайте этого самого центра.
И если бы не Let's Encrypt мне вообще не понятно почему я должен платить кому-то, выглядит это как нарко кортель или крыша, мы вот свой корневой просунули в разные системы, а теперь если ты хочешь шифрование давай плати нам или иди лесом, а не шифрование тебе, при этом компания держатель корневого сертификата не несет по сути не каких издержек каждый платеж чистая прибыль. И тут можно сказать что у них сайт у них там сервис проверки на отозванные сертификаты но это все не работает по большому счету https://habr.com/ru/post/332730/. Так что если ваш приватный ключик скомпрометировали (ну случилось так сам лопух) то вам не кто не поможет и вашим старым сертификатом будут пользоваться до окончания его срока действия. Ну и что то я не разу не слышал что бы центр выплатил страховку, которую они так любят везде рекламировать, из за неработающего механизма отзыва сертификата.
pansa
28.09.2021 22:43+3Для защиты от недобросовестных CA сообщество (по-моему, собственно, гугл был во главе после инцидента, на который вы сослались) породило Certificate Transparency. Грубо: публичный глобальный лог всех выпускаемых сертификатов (публичных, конечно). Вы можете даже настроить нотификации, и вам будут приходить извещения при регистрации там каждого сертификата, отвечающего заданным критериям (например, с доменом для вашей организации). Такой сервис есть у фейсбука, например. Сертификаты, которых не будет в этом публичном логе, скорее всего являются поддельными. Примерно так задумано.
vikarti
30.09.2021 22:35Кстати — не только "публичных" в смысле доступных всем. tailscale вот умеет выпускать сертификаты на machine-name.generated-subdomain.ts.net, подразумевается что их увидят только те кто могут попасть к конкретной внутренней сетке tailscale. но при этом прямо выдается предупреждение что если machine-name это сама по себе какая то секретная инфа — то не надо этой функцией пользоваться потому что все уйдет в transparency log
artchalet
28.09.2021 23:41+1"выглядит это как нарко кортель или крыша "
полностью согласен, и кроме того всё сделано так, что каждый раз при обновлении (платном) - то нет чтобы в два клика продлить срок действия, а выполняешь целую вереницу действий по новой установке сертификатов - причем в каждый сервис в каком либо особом формате. То каждый год на то, что должно быть в два клика (продолжить действие сертификата) тратишь кучу времени чтобы во всех подсистемах заново прописать.
Balling
30.09.2021 10:59+1Никто не пользуется сертификатом для шифрования. Только для подписи, ключи эфемерны ECDHE
FODD
27.09.2021 04:36+3Я скажу больше - конечный пользователь видит пресловутый значок замочка и думает, что его данные в безопасности. И он не понимает, что у него в системе может быть установлен корневой сертификат от товарища майора, или что сайт sberPank dot ru не является безопасным, несмотря на замочек.
DreamingKitten
27.09.2021 04:57или что сайт sberPank dot ru не является безопасным, несмотря на замочек.
Ну, в теории-то удостоверяющий центр должен прищемить такой сертификат за использование в мошеннических целях.
iliar
27.09.2021 11:18Вопрос популярности. Я как то в качестве первоапрельской шутки создал фейковый сайт. Несмотря на то, что далеко не все оценили шутку и было много бугурта в сообществе. Домен всё ещё живёт и сертификат регулярно обновляется.
Я думаю чтобы центр сертификации почесался бы блокировкой должна накопиться какая то критическая масса жалоб. Для сайтов однодневок она может просто не успеть набраться. А за это время будет обмануто много людей.
vikarti
27.09.2021 15:01Ну если это широко известно — прикрывают
Причем даже если сертификат формально выдан по правилам
см например https://www.bleepingcomputer.com/news/security/extended-validation-ev-certificates-abused-to-create-insanely-believable-phishing-sites/ — история с EV-сертификатом для Stripe, Inc (Имена компаний — НЕ глобально уникальны).
bgBrother
27.09.2021 12:50Chrome в новых версиях изменит замочек на стрелочку в виде неполного треугольника. К сожалению, подтверждение сейчас не нашёл, но информация подлинная.
dartraiden
27.09.2021 15:02+3На мой взгляд, имеет смысл вообще отказаться от показа значка, так как соединение должно быть защищено по умолчанию, это обычное и нормальное состояние, зачем об этом сигнализировать. Сигнализировать имеет смысл о том, что что-то не так (проблемы с защищённым соединением, включая его отсутствие), либо о том, что подлинность ресурса подтверждена.
Показ «замочка» это наследие времён, когда большая часть соединений шла в незашифрованном виде, а безопасные соединения были чем-то таким, что выделялось на общем фоне.
farafonoff
27.09.2021 14:39Проблема решится сама собой, когда будет 100% хттпс, и замочек можно будет убрать
DreamingKitten
27.09.2021 04:48+2Не только от подмены. Ещё он удостоверяет сервер. Конечно, если пользователь не полный дурак и умеет читать хотя бы.
Dotarev
27.09.2021 07:43+5А ещё можете пояснить, как можно по сертификату убедиться, что зашел на официальный сайт госуслуг?
Немного пояснения. Если зайти на сайт того же Сбера и посмотреть сертификат, там ясно написано: Страна:Ru, Организация:Sberbank of Russia PJSC и т.д.
А вот в сертификате gosuslugi.ru ничего такого нет; есть только общее имя, и с моей точки зрения он ничем не примечательнее сертификата того же dosuslugi.ru или gоsuslugi.ru (кстати, последний продается :=()
Goodwinnew
27.09.2021 09:51+1у Сбера сертификат выдан на организацию (как и должно собственно быть в большом бизнесе), а на госуслугах сертификат выдан просто на домен, как у любого простого частного сайта...Причем у Сбера сертификаты отдельные на все их поддомены (сервисы), а на госуслугах - один общий на всё
CN = *.gosuslugi.ru
----
CN = sberbank.ru
O = Sberbank of Russia PJSC
L = Moscow
S = Moscow
C = RU
Dotarev
27.09.2021 09:57+2на госуслугах сертификат выдан просто на домен, как у любого простого частного сайта...
Вот и я о том же...
NikitaCartes
27.09.2021 10:16+2на госуслугах сертификат выдан просто на домен, как у любого простого частного сайта
А так какая в итоге разница, если это для конечного пользователя оба сертификата выглядят абсолютно одинаково? Раньше была плашка об организации, да, но сейчас её уже убрали.
Goodwinnew
27.09.2021 11:12Да, теперь пользователю нужно делать дополнительные усилия (клац-клац мышкой) и смотреть свойства сертификата :(
Egor_Malashevsky
27.09.2021 20:57Если бы там стоял бесплатный сертификат от Let's Encrypt, тогда это были бы не госуслуги, а мошеннический сайт. Так как на госуслугах стоит платный сертификат от Sectigo сроком на 1 год, пусть и всего лишь DV, а не OV или EV. Плюс ещё в домене нужно проверять каждый символ, чтобы было именно gosuslugi.ru или esia.gosuslugi.ru, но не никак не gOsusSlugi.ru Конечно, на государственном портале должен быть как минимум Organization Validation- сертификат, но лучше Extended Validation, то есть на организацию, а не просто на домен. Но что имеем то и имеем, к сожалению :(
Pas
30.09.2021 22:29Ну если заполнен признак O, то это уже не DV, а OV. Другое дело, что и DV и OV для внешнего наблюдателя выглядят практически одинаково.
tonhead
27.09.2021 10:50-4Вот тоже интересно, на что обращать внимание. Для меня признак мошеннического сайта - это краткосрочность действия его сертификата (3 месяца), но я видел нормальные сайты с короткоживущими сертификатами.
Survtur
27.09.2021 10:58+17Let's encrypt даёт сертификат на 3 месяца, так что критерий мошенничества как-то не очень.
bgBrother
27.09.2021 12:55+3Для меня признак мошеннического сайта — это краткосрочность действия его сертификата (3 месяца)
Сайт с меньшим временем действия сертификата при прочих равных наоборот может быть более безопасным — меньший шанс использования того же сертификата после утечки.Вот тоже интересно, на что обращать внимание
На тип сертификата, на домен, на подключаемые из CDN фронт-енд библиотеки и наличие указанных слепков подписи для них, прочее.
iliar
27.09.2021 11:20+3Это вопрос к владельцу сайта. Какой уровень подтверждения он хочет.Задача самого простого сертификата подтверждать только то, что заходя на gosuslugi.ru ты получаешь данные именно от gosuslugi.ru, а не от какого то другого.
Survtur
27.09.2021 11:34Вот кстати, все ли браузеры покажут url как https://www.xn--gsuslugi-nbh.ru/ ? Или кто-то напишет "gоsuslugi.ru"?
Rsa97
27.09.2021 11:45Многие DNS-регистраторы просто не разрешат регистрировать idn-имя, если в какой-либо его части встречаются одновременно символы нескольких алфавитов.
elfukado
27.09.2021 08:31+14Конечно, если пользователь не полный дурак
Мой опыт сисадмина-эникейщика в неайтишных предприятиях подсказывает, что ваши ожидания сильно завышены.
Ziptar
27.09.2021 11:52+2Подтверждаю. Большинство пользователей не просто не умеют читать, но даже не считают нужным это делать. Любое сообщение об ошибке вызывает два типа реакции: либо ступор, либо, в большинстве случаев, желание поскорее сообщение закрыть.
SergeKh
27.09.2021 08:25+13Подмена пакетов провайдером - это далеко не иллюзорная опасность. В РФ очень многие провайдеры подменяют код HTTP-сайтов и вклинивают в них свою рекламу. В результате у владельца сайта во-первых сразу падает выручка от рекламы, потому что кликают не по его баннеру а по провайдерскому, во-вторых браузерное ПО Яндекса и гугла детектирует аггресивную рекламу на сайте, стучит об этом хозяину и сайт получает пессимизацию в поиске вплоть до бана.
gameplayer55055
28.09.2021 17:34Безопасность это не хуй собачий. И нужно шифровать. А с ESNI и DoH пакеты провайдер не поменяет. А без сертификатов никуда, или надо будет изобретать блокчейн интернет
svasva
03.10.2021 10:57-1Алексей, вам ничего не кажется. Вы всё правильно понимаете, но посмотрите сколько недоразвитых вас минусует... Вот в этом вся проблема. Поэтому вечно будут что-то вводить или отменять и, разумеется, всё это будет для "нашей с вами безопасности" :))
ttys
06.10.2021 10:09-2Проблемы в основном у любителей халявы. Там где покупные сертификаты пока всё работает отлично.
ALexhha
06.10.2021 10:20Проблемы в основном у любителей халявы. Там где покупные сертификаты пока всё работает отлично.
ага, конечно - https://www.opennet.ru/opennews/art.shtml?num=31678Epic fails того же Verisign загуглите сами
blind_oracle
27.09.2021 08:50+6Этот зоопарк с кучей корневых сертификатов в текущем виде будет всегда проблемой.
Сейчас TLS есть даже в чайниках и лампочках, а кто будет обновлять в них список доверенных сертификатов? Производитель про них через пару лет забудет.
И хорошего выхода не видно... Есть DANE, но там те же проблемы почти - ключ корня DNS нужно тоже иногда обновлять, хоть это и попроще чем сотни корневых.
Smashrock
27.09.2021 10:59+1Замену DANE можно скриптом автоматизировать, если используете Cloudflare. Блин, Cloudflare хоть и гигантская монополистическая машина, но такая, зараза, удобная. А, к сожалению, DANE сам не живой :( Ну только если в почте живёт, но и даже там некоторые почтовые серверы его не проверяют.
sashok724
27.09.2021 13:26Замену DANE можно вообще не делать если менять только сертификат, не меняя пару ключей из которого он получается (опция --reuse-key в certbot)
Pendel
27.09.2021 11:41Как производитель я бы "надеялся" на то, что срок службы таких чайников и лампочек окажется меньше срока действительности сертификата.
Balling
30.09.2021 11:04В корне DNS 2 ключа минимум или 3 при ролловере. Конечно, важен только KSK но все же.
muxa_ru
30.09.2021 20:55+4Сейчас TLS есть даже в чайниках и лампочках, а кто будет обновлять в них список доверенных сертификатов?
А вот это даже хорошо, ибо если лампочка не можем законектица на удалённый сервер, то она не является уязвимостью :)
tormozillo
27.09.2021 10:49-44Let's Encrypt является профанацией безопасности, когда любой желающий без всяких даже намёков на подтверждение получает сертификат подлинности, как у настоящих подлинных сайтов. Либо скоро брузеры начнут банить такие сайты, либо сервис круто поменяется и начнет закручивать гайки. Я думаю эта вакханалия возможна только из-за переходного периода и всеобщего желания отказаться от незашифрованного http
Rsa97
27.09.2021 10:59+23Let's Encrypt выдаёт DV-сертификаты. Для них достаточно подтверждения владения доменом через размещение на своём сайте служебного файла или создания в своём DNS служебной записи.
Но получить совершенно произвольный сертификат не получится, попробуйте, например, получить там сертификат для habr.com.tormozillo
27.09.2021 11:10-26В плане информационной безопасности вы очень узко мыслите. Домены-близнецы регистрировать ничего не мешает.
Rsa97
27.09.2021 11:13+16Так и OV- или EV-сертификат для домена-близнеца получить можно, было бы желание и деньги.
tormozillo
27.09.2021 11:25-36Вы мысль мою не улавливаете совсем. До пусть кто угодно что угодно регистрирует и используетс в свих целях, да это удобный сервис, просто в условном стоковом браузере Firefox или Chrome не должно быть корневого сертификата этого сервиса.
Rsa97
27.09.2021 11:52+25С чего бы это? DV-сертификат от Let's Encrypt технически ничем не отличается от DV-сертификата любого другого удостоверяющего центра.
pae174
27.09.2021 13:24+7Но получить совершенно произвольный сертификат не получится
Это у Васи Пупкина в интернете не получится. У товарища майора в чебурнете очень даже получится - с помощью НСДИ. Если авторитативный NS атакуемого домена находится в чебурнете то запросы от LE к нему проходят через НСДИ, которая может сформировать такие ответы, которые LE будет считать подтверждением того, что запрос на серт пришёл от админа домена.
farafonoff
27.09.2021 14:44+2тут в дело вроде бы должен вступить certificate transparency
pae174
27.09.2021 15:05+1CT это только мониторинг. То есть он в принципе не предотвращает выдачу более одного сертификата на один и тот же домен а только ведёт логи выданных сертификатов. Подавляющее большинство админов не только не смотрит эти логи, но и вообще ничего не знает о существовании CT.
farafonoff
27.09.2021 16:05+1Не все так просто. Веб-сервер должен регулярно ходить в CT, и убеждаться что его сертификат - актуальный сертификат для домена. Подписанный ответ прикладывается к сертификату, и отдается браузеру. На сколько я понимаю, в хроме уже реализована проверка этого. (Сложно сказать как оно сработает, проверить это полностью для меня слишком трудоемко).
(В браузере в просмотре сертификата смотреть в сторону SCT Version 1, Log Operator: Lets Encrypt; детальная инфа тут https://crt.sh/?q=habr.com)
pae174
27.09.2021 16:34Описанное вами "хождение сервера в CT" называется OCSP stampling и никак не предотвращает выдачу более одного сертификата на один домен.
Простановка штампа на стороне сервера позволяет разгрузить сервера сертификационных центров. Если браузер получает от сервера сертификат без штампа то он гипотетически должен запросить у сертификационного центра, не был ли этот сертификат отозван досрочно. Это создаёт сильную нагрузку на инфраструктуру сертификационных центров.
OCSP stampling позволяет посылать такие запросы только со стороны вебсервера и только по расписанию. Ответы (так называемые штампы, они подписаны центром сертификации), действительно передаются браузеру. Если браузер получает от сервера сертификат со штампом, то он просто проверяет дату/время штампа и никаких запросов в сертификационный центр не делает.
farafonoff
29.09.2021 09:30Certificate Transparency другая технология, хотя и работает похожим образом. OCSP проверяет отзыв, а CT Log проверяет уникальность.
iliar
27.09.2021 11:04+5Какие подтверждения нужны для получения сертификата удостоверяющего исключительно домен, кроме как подтверждение владения доменом?
tormozillo
27.09.2021 11:12-18вот так любой ботнет этим и пользуется: зарегят свой левый домен, разошлют спам со ссылкой, юзер открывает, а брузер говорит ему что всё ок, сертификат годный. Это только спецы понимают что надо читать сертификат и смотреть на строку адреса, а типовой рядовой пользователь, коих 99% когда видит зеленый щит в строке браузера - для него это значит что сайт подлинный.
Survtur
27.09.2021 11:28+11вот так любой ботнет этим и пользуется: зарегят свой левый домен, разошлют спам со ссылкой, юзер открывает, а в заголовке страницы написано "Сбербанк". Это только спецы понимают что надо смотреть на строку адреса, а типовой рядовой пользователь, коих 99%, когда видит название фирмы на сайте - для него это значит что сайт подлинный.
DaemonGloom
27.09.2021 12:49+5А когда вы последний раз обновили свой браузер? Уже давно https помечается просто серым значком, а скоро и его планируют убрать.
Нет замочка — нет проблем, так ведь?
Themen
27.09.2021 11:23+29Надо просто понять одну простую вещь, что когда вы заходите на какой-то сайт, то замочек в адресной строке вовсе не означает, что сайт не мошеннический. Замочек означает только одно, что вы зашли ровно на тот сайт, адрес которого написан в адресной строке. Другими словами, что вам не подменили трафик. И всё! Это ровно то, чем занимается Let's Encrypt и это никакая не профанация. А то, что написано в адресной строке вы должны читать сами.
tormozillo
27.09.2021 11:28-29Вы тоже мыслите как нуб. Типичная ошибка равнять всех людей под себя. Любому профессиональный безопасник чётко понимает что не все умные и предпринимает действия чтобы не открывать окно возможностей для скама. Существует огромный пласт пользователей пожилого возраста, которых вынудили во всякие госуслуги, но на них всем как обычно насрать.
Themen
27.09.2021 11:38+25Почему вы решили, что проблемой скама нужно заниматься на уровне SSL? У него одна задача, не дать подменить трафик. А то, по вашему выходит, что Let's Encrypt должен решать, что тому можно сделать свой бложик, а вот тот выглядит подозрительно, ему нельзя? Вам не кажется, что это должно быть сделано как-то иначе, а не уровне шифрования трафика? У меня есть бложик, и я хочу, чтобы трафик там был зашифрован, иначе провайдер просто подсовывает в трафик свою рекламу. Почему я должен собирать какие-то документы, платить деньги, ждать чьего-то решения? Я просто хочу, чтобы трафик шифровался, и его не подменяли, и всё.
tormozillo
27.09.2021 14:54-23Специально для таких существуют самоподписанные сертификаты, чтобы никому ничего не платить. Ой что я слышу? Браузеры не пускают юзеров на твой бложик из-за соображений безопасности? Ай-яй-яй, вот идиоты и параноики эти хромы, эджи и фаерфоксы (как и я). А давай подпишем сервисом, который безотказен и его сертификат внедрен в любой браузер и проблема безопасности обойдена. Уловил теперь суть проблемы? Этот сервис тупо протащил в браузеры сертификаты по уровню доверия аналогичные самоподписанным.
Themen
27.09.2021 15:28+18Вы путаете. Самоподписанный сертификат не может гарантировать, что я посещаю именно ту страницу, которая у меня написана в адресной строке. Именно поэтому браузер и ругается на такие сертификаты. Когда появился Let's Encrypt, то общая безопасность повысилась, т.к. стало возможным использовать шифрование для всех и при этом будет гарантироваться отсутствие подмены трафика.
Ещё раз, я считаю, что технология, обеспечивающая шифрование не должна заниматься аудитом. Этим могут заниматься:
а) правоохранительные органы;
б) регистраторы домена;
в) специализированное ПО на компьютере пользователя;
г) придумайте что-то своё
Считать, что шифрование должно быть только для избранных - это заблуждение. К этому уже пришли в Гугл, которые иногда порываются вообще запретить в Хроме http трафик.
Color
27.09.2021 13:57+6Как это с шифрованием трафика связано? И с проверкой того, что трафик пришел от того же домена, который указан в адресной строке?
Проблемы скама это совершенно никак не транспортный уровень. Многие браузеры реализуют предупреждения о том, что данный сайт "плохой", а яндекс браузер (насколько читал) прям какой-то серьезный инструмент для этого реализовал. Ставьте своим пользователям пожилого возраста яндеск браузер или поставьте фаервол с фильтрацией по белым спискам, но при чем тут сертификаты их валидация?
Это как пытаться решить проблему вопровства тем, что не выдавать ворам паспорт, чтобы они не могли на него симку зарегистрировать. Вот только нужно как-то понять, что человек вор, на момент выдачи паспорта - но это же не наша проблема, правда?
AlexVWill
27.09.2021 11:41+16Прошу прощение, вы путаете теплое и мягкое, Let's Encrypt (равно как и любой другой центр сертификации) не занимается аудитом контента, он лишь удостоверяет владение доменом, а вопрос безопасности контента на совести либо адекватности пользователя, либо антивирусных и антиспаммерских и антифишинговых программ (польза которых без адекватности пользователя тоже весьма иногда сомнительна).
tormozillo
27.09.2021 12:20-25Комменты отлично демонстрируют розовые сопли и деградацию "спецов". Со временем только хуже будет.
Lopar
27.09.2021 12:57+4Ну безопасники это какая-то мифическая ниша. Я из сетевика как-то хотел переквалифицироваться в безопасника, но.. я тупо не нашёл ни самих безопасников, ни каких-либо внятных мануалов. Вся ниша очень сильно закуклена саму на себя: всё как-бы есть, но только для участников. 120% шапошно-знакомых людей пролезших в кибербез подтвердили, что их туда звали, а не они сами это нашли: кого отличником из вуза дёрнули, кого знакомые подтянули.
Может поэтому и деградация спецов налицо: если свежей кровью хрен разбавишь - будет застой.
Harliff
27.09.2021 16:09+1Не могли бы Вы так же привести соответствующие команды для Windows?
Alexsey
27.09.2021 16:22Сертификаты посмотреть, добавить, удалить можно запустив certmgr.msc. DST Root CA X3 лежит в доверенных корневых центрах сертификации.
Не факт только что современные браузеры (firefox, chrome) берут сертификаты из хранилища винды.
Egor_Malashevsky
28.09.2021 16:25+1Google Chrome, а также Опера, Яндекс Браузер, Microsoft Edge, и т.д., используют сертификаты из системного хранилища Windows. Можете сами в этом убедиться, нажав на замок в адресной строке, а потом посмотрев информацию о сертификате. А Firefox использует свое хранилище сертификатов.
fLegmatik
30.09.2021 06:56+1День Икс настал и на работе обнаружились несколько WinXP SP3 с изначально отключенным механизмом автообновлений. Также есть несколько WinXP SP3, которые без проблем подключаются к веб-серверу с сертификатом LE. Кто-нибудь уже нашёл, какое конкретно обновление надо установить и где его можно скачать?
Отдельное спасибо автору статьи за инструкцию для debian jessie, такая тоже ещё работает.
Tippy-Tip
30.09.2021 23:33+2У Вас немного устаревшая информация. В Firefox есть параметр security.enterprise_roots.enabled (тип булево)
Начиная с Firefox версии 68, когда возникает ошибка TLS-соединения, Firefox автоматически активирует параметр Enterprise Roots и пытается подключиться снова. Если проблема устранена, то параметр Enterprise Roots остаётся включённым.
Egor_Malashevsky
30.09.2021 23:43Понял. А каким образом благодаря этому параметру исправляется данная ошибка? Он заставляет Firefox использовать системное хранилище сертификатов в Windows вместо собственного? P. S Я не программист и не айтишник, и в этом плохо разбираюсь. Уж извините(
Egor_Malashevsky
01.10.2021 00:02А, все, я уже узнал, за что отвечает этот параметр- благодаря нему Firefox импортирует сертификаты из хранилища Windows,в собственное хранилище сертификатов, чтобы устранять те самые ошибки безопасного соединения.
rantal Автор
27.09.2021 16:30Скажем так, если у вас в Windows установлены обновления (а конкретно, обновления корневых сертификатов), то практически наверняка проблема не должна вас коснуться. Если только вы не пользователь чего-либо более старого, чем Windows XP SP3. Но в последнем случае современный HTTPS в любом случае не для вас, т.к. тогда у вас просто не будет поддержки кучи используемых сейчас в HTTPS шифров и т.п.
Тем не менее, если есть желание проверить и убедиться, то есть программа RunAsDate, аналог faketime для Windows.
kuskus
01.10.2021 10:21+1Для Windows 7 (на не обновленной отваливаются сайты в хроме, файрфокс работает норм)
Control Panel -> Internet Options -> Content -> Certificates -> Trusted Root Certification Authorities -> Import
сертификат лежит тут letsencrypt.org/certs/isrgrootx1.der
там же удалить DST Root CA X3
pcdesign
02.10.2021 14:05Спасибо. Заработало на старой 7-ке. А обязательно удалять DST Root CA X3? Там кнопка для удаления не активна.
kuskus
02.10.2021 21:28Не проверял. Сделал как написано в рекомендациях. На что влияет хз(по идее сертификат и так не используется т.к. уже не валиден, возможно это приходится проверять каждый раз и будет медленнее), если и так работает то не надо :). Странно что кнопка не активна — может зайти под админом?
roweo
03.10.2021 20:11извините, я плохо разбираюсь в пк, могли бы подсказать, где именно найти это - Control Panel -> Internet Options -> Content -> Certificates -> Trusted Root Certification Authorities -> Import, и какие действия нужно выполнить? Установил обновления UpdatePack7R2-21.9.15, всё работает, но ноутбук у меня старенький и после этого обновления он что-то тормозить начал. Хочу откатить всё назад. Было бы здорово, если можно было бы обновить только сам сертификат, а не всю систему. Благодарю!
SagePtr
03.10.2021 20:44Предположительно вот это обновление должно помочь: https://support.microsoft.com/en-us/topic/support-for-urgent-trusted-root-updates-for-windows-root-certificate-program-in-windows-a4ac4d6c-7c62-3b6e-dfd2-377982bf3ea5
lucky_slav
02.10.2021 15:29+1У нас установлен WAMP для Windows, который используем для синхронизации с сайтом с помощью cURL.
Решить проблему помогла эта статья https://insidert.medium.com/fix-curl-error-60-in-wamp-server-a0ffff8dbb29
Просто скачал со страницы https://curl.haxx.se/docs/caextract.html актуальный файл cacert.pem, положил в корень WAMP и все заработало.
Kenshouten
27.09.2021 16:31+4Не совсем понятно из статьи, а что делать, если система старая и не доверяет ISRG Root X1 (ну, не всегда есть возможность взять и всё обновить, к сожалению).
В моем случае надо было решить проблему на Ubuntu Server 14.04.
curl https://letsencrypt.org/certs/isrgrootx1.pem.txt | sudo tee /usr/share/ca-certificates/mozilla/ISRG_Root_X1.crt(Либо
curl -k, если DST_Root_CA_X3.crt уже снесли)Потом дописываем
mozilla/ISRG_Root_X1.crtв/etc/ca-certificates.confи делаемsudo update-ca-certificates
Tufed
28.09.2021 01:27У меня на Ubuntu Server 14 sertbot перестал работать. Ругается что эта устаревшая система больше не поддерживается. Перевыпустить сертификат на ней теперь нельзя.
Kenshouten
28.09.2021 03:24Хм, у меня, вроде, работает на
Ubuntu 14.04.5 LTS (GNU/Linux 3.19.0-43-generic x86_64)У меня там недавно сертбот отваливался, потому что я его вовремя на ACME2 не перевёл, и он не смог обновить сертификат.
Я это починил вот этой командой:
sudo certbot renew --apache --agree-tos --force-renewal --email support@example.com --server https://acme-v02.api.letsencrypt.org/directoryПосле этого
sudo certbot renew --apacheработает в штатном режиме.$ certbot --version
certbot 0.22.2
Maxim_Q
27.09.2021 19:01Сейчас попробовал обновить сертификал от Let's Encrypt и они выдают мне сертификат подписывая его старым Root CA X3 который закончится через 2 дня. Так и задумано или где-то проблема?
rantal Автор
27.09.2021 19:53Так и задумано, основная цепочка останется IdenTrust’s DST Root CA X3 -> ISRG Root X1 -> Let's Encrypt R3 -> Конечный сертификат пользователя. Это сделано для того, чтобы сохранить совместимость со старыми Android (версии < 7.1.1), которые не знают про ISRG Root X1, но продолжат доверять DST Root CA X3 даже после его истечения (особенность работы с корневыми сертификатами в Android).
Comraddm
28.09.2021 20:44+5Утилита faketime в Fedora / Centos находится в пакете libfaketime.
Причем в Centos 6.10 бинарника faketime в этом пакете нет.
Вместо этого его ридми рекомендует несколько иной синтаксис работы, например:
LD_PRELOAD=/usr/lib64/libfaketime/libfaketime.so.1 FAKETIME="+15d" curl https://letsencrypt.org/В данном примере время листается вперед на 15 дней и запускается curl.
В старенькой же Fedora 22 корневые сертификаты устарели, в них нет корневого сертификата от Let's Encrypt: ISRG Root X1, и openssl старой версии 1.0.1k-fips.
Я сделал так:
1) забэкапил папку /etc/pki, несмотря на то, что это вроде как и необязательно, но так спокойнее.
2) скачал бандл свежих корневых сертификатов:
curl https://curl.se/ca/cacert.pem -o /etc/pki/ca-trust/source/anchors/ca-bundle.crtЕсли курл уже не работает, то можно ручками скачать на другой системе и подложить в
/etc/pki/ca-trust/source/anchors/ca-bundle.crt3) отредактировал скачанный
ca-bundle.crt, вырезав в нем абзац, касаемыйDST Root CA X3:DST Root CA X3 ============== -----BEGIN CERTIFICATE----- MIIDSjCCAjKgAwIBAgIQRK+wgNajJ7qJMDmGLvhAazANBgkqhkiG9w0BAQUFADA/MSQwIgYDVQQK ExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMTDkRTVCBSb290IENBIFgzMB4X DTAwMDkzMDIxMTIxOVoXDTIxMDkzMDE0MDExNVowPzEkMCIGA1UEChMbRGlnaXRhbCBTaWduYXR1 cmUgVHJ1c3QgQ28uMRcwFQYDVQQDEw5EU1QgUm9vdCBDQSBYMzCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAN+v6ZdQCINXtMxiZfaQguzH0yxrMMpb7NnDfcdAwRgUi+DoM3ZJKuM/IUmT rE4Orz5Iy2Xu/NMhD2XSKtkyj4zl93ewEnu1lcCJo6m67XMuegwGMoOifooUMM0RoOEqOLl5CjH9 UL2AZd+3UWODyOKIYepLYYHsUmu5ouJLGiifSKOeDNoJjj4XLh7dIN9bxiqKqy69cK3FCxolkHRy xXtqqzTWMIn/5WgTe1QLyNau7Fqckh49ZLOMxt+/yUFw7BZy1SbsOFU5Q9D8/RhcQPGX69Wam40d utolucbY38EVAjqr2m7xPi71XAicPNaDaeQQmxkqtilX4+U9m5/wAl0CAwEAAaNCMEAwDwYDVR0T AQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFMSnsaR7LHH62+FLkHX/xBVghYkQ MA0GCSqGSIb3DQEBBQUAA4IBAQCjGiybFwBcqR7uKGY3Or+Dxz9LwwmglSBd49lZRNI+DT69ikug dB/OEIKcdBodfpga3csTS7MgROSR6cz8faXbauX+5v3gTt23ADq1cEmv8uXrAvHRAosZy5Q6XkjE GB5YGV8eAlrwDPGxrancWYaLbumR9YbK+rlmM6pZW87ipxZzR8srzJmwN0jP41ZL9c8PDHIyh8bw RLtTcm1D9SZImlJnt1ir/md2cXjbDaJWFBM5JDGFoqgCWjBH4d1QB7wCCZAA62RjYJsWvIjJEubS fZGL+T0yjWW06XyxV3bqxbYoOb8VZRzI9neWagqNdwvYkQsEjgfbKbYK7p2CNTUQ -----END CERTIFICATE-----4) это вырезанный абзац вставил в файл /etc/pki/ca-trust/source/blacklist/dst_root_ca_x3.crt
т.е. в черный список.
5) выполнил команду
update-ca-trustГотово.
Для проверки можно выполнить такие команды:
1) присутствие в системе сертификата ISRG Root X1
awk -v cmd='openssl x509 -noout -subject' ' /BEGIN/{close(cmd)};{print | cmd}' < /etc/ssl/certs/ca-bundle.crt | grep "ISRG Root X1"
Должно выдать subject= /C=US/O=Internet Security Research Group/CN=ISRG Root X1
2) отсутствие в системе сертификата DST Root CA X3
awk -v cmd='openssl x509 -noout -subject' ' /BEGIN/{close(cmd)};{print | cmd}' < /etc/ssl/certs/ca-bundle.crt | grep "DST Root CA X3"
Должно ничего не выдать.
Надеюсь кому-то поможет.
Инфу черпал из этой статьи и отсюда
https://serverfault.com/questions/394815/how-to-update-curl-ca-bundle-on-redhat
Snooper
01.10.2021 13:21После добавления DST Root CA X3 в блеклист на centos 6.10
openssl s_client -connect valid-isrgrootx1.letsencrypt.org:443 -quiet depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1 verify error:num=20:unable to get local issuer certificate verify return:0 openssl s_client -connect vault.centos.org:443 -quiet depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1 verify error:num=20:unable to get local issuer certificate verify return:0
Видимо нужно добавить ещё что-то, но не могу понять что
Предположил, что нужен этот сертификат https://letsencrypt.org/certs/isrgrootx1.pemНо не помогло.
Взят отсюда: https://letsencrypt.org/certificates/
Может кто-то что-то подскажет?rantal Автор
01.10.2021 13:26+1Какая версия openssl? Столкнулся с тем, что, например, openssl 1.0.1k в debian jessie при наличии в доверенных ISRG Root X1 и удаленном из доверия DST Root CA X3 как раз выдает ошибку "unable to get local issuer certificate". А вот openssl 1.0.1t при тех же условиях работает корректно.
Snooper
01.10.2021 13:31На centos 6.10:
OpenSSL 1.0.1e-fips 11 Feb 2013Значит ещё и openssl обновлять нужно.
rantal Автор
01.10.2021 13:58+2Вам придется обновиться минимум до openssl 1.0.1p. Дело в том, что в trusted store хранится самоподписанный корневой сертификат ISRG Root X1. А сервер в цепочке предоставляет другую его версию - ISRG Root X1, подписанный DST Root CA X3. Не смотря на одинаковые CN, это РАЗНЫЕ сертификаты. Openssl до 1.0.1p видит в цепочке ISRG Root X1, подписанный DST Root CA X3, и не может соотнести его с самоподписанным ISRG Root X1 в trusted store - отсюда сообщение об ошибке. А начиная с версии 1.0.1p openssl соотносит сертифкат с CN=ISRG Root X1 в trusted store и в цепочке, предоставляемой сервером, поэтому верификация проходит.
PS. Есть еще одна идея, как обойтись без обновления - проверю, напишу
edo1h
01.10.2021 14:03А начиная с версии 1.0.1p openssl соотносит сертифкат с CN=ISRG Root X1 в trusted store и в цепочке, предоставляемой сервером, поэтому верификация проходит.
сопоставление идёт по CN?
rantal Автор
01.10.2021 15:05+1Насколько я понимаю, сопоставление идёт по издателю (issuer) сертификата на шаг дальше по цепочке. Т.е. сервер отдает цепочку ISRG Root X1 (issuer: IdenTrust’s DST Root CA X3) -> Let's Encrypt R3 (issuer: ISRG Root X1) -> Конечный сертификат (issuer: Let's Encrypt R3), в trusted store у нас на клиенте ISRG Root X1 (issuer: ISRG Root X1). При проверке на клиенте openssl видит в цепочке Let's Encrypt R3 (issuer: ISRG Root X1), ищет в своем trusted store сертификат с Subject, совпадающим с полем issuer сертификата Let's Encrypt R3 (issuer: ISRG Root X1). И находит ISRG Root X1(issuer: ISRG Root X1) - альтернативная цепочка найдена, доверие подтверждено. Коммит, где добавлена эта логика. До 1.0.1p этого не было.
Comraddm
01.10.2021 18:08На Fedora 22:
OpenSSL 1.0.1k-fipsНо таки все работает:
openssl s_client -connect valid-isrgrootx1.letsencrypt.org:443 -quietdepth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1verify return:1depth=1 C = US, O = Let's Encrypt, CN = R3verify return:1depth=0 CN = origin.letsencrypt.orgverify return:1rantal Автор
01.10.2021 18:22Может сам бинарник 1.0.1k, а либы более свежие стоят? Например, все корректно работает при таком вот выводе openssl version:
OpenSSL 1.0.1k 8 Jan 2015 (Library: OpenSSL 1.0.1t 3 May 2016)
Comraddm
01.10.2021 18:42+1Все одной и той же версии:
#rpm -qa|grep openssl openssl-1.0.1k-15.fc22.i686 openssl-libs-1.0.1k-15.fc22.i686 openssl-devel-1.0.1k-15.fc22.i686Работает корректно:
#openssl version OpenSSL 1.0.1k-fips 8 Jan 2015rantal Автор
01.10.2021 19:11Похоже тогда есть еще какой-то влияющий фактор, который мы не учитываем... Федоры нет под рукой для экспериментов. А на debian jessie openssl 1.0.1k (не fips правда) при наличии доверенного самоподписного ISRG Root X1 и исключенном DST Root CA X3 получается "unable to get local issuer certificate".
Snooper
03.10.2021 12:42+2Собирал версии openssl 1.0.1u / 1.0.2u / 1.1.1l
Ошибка сохранялась.
В итоге пересобрал пакет из репозитория centos
Инструкция для решения проблемы в centos 6.10:
Ставим зависимости для сборки:
yum install rpm-build rpmdevtools krb5-devel zlib-develСоздаём структуру директорий:
rpmdev-setuptreeСкачиваем и устанавливаем srpm:
wget --no-check-certificate https://vault.centos.org/6.10/updates/Source/SPackages/openssl-1.0.1e-58.el6_10.src.rpm rpm --install openssl-1.0.1e-58.el6_10.src.rpmРедактируем
nano /root/rpmbuild/SPECS/openssl.spec Release: 58%{?dist} меняем на Release: 59%{?dist}nano /root/rpmbuild/SOURCES/openssl-1.0.1e-trusted-first.patchдописываем в конце файла
diff -up openssl-1.0.1e/crypto/x509/x509_vpm.c.trusted-first-default openssl-1.0.1e/crypto/x509/x509_vpm.c --- openssl-1.0.1e/crypto/x509/x509_vpm.c.trusted-first-default 2013-02-11 19:26:04.000000000 +0400 +++ openssl-1.0.1e/crypto/x509/x509_vpm.c 2021-10-03 08:55:08.802387319 +0300 @@ -322,7 +322,7 @@ "default", /* X509 default parameters */ 0, /* Check time */ 0, /* internal flags */ - 0, /* flags */ + X509_V_FLAG_TRUSTED_FIRST, /* flags */ 0, /* purpose */ 0, /* trust */ 100, /* depth */Собираем
rpmbuild -bb /root/rpmbuild/SPECS/openssl.specУстанавливаем
yum install /root/rpmbuild/RPMS/x86_64/openssl-1.0.1e-59.el6.x86_64.rpmДобавлять в блеклист ничего не требуется.
Проверяем:
openssl s_client -connect valid-isrgrootx1.letsencrypt.org:443 -quiet depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1 verify return:1 depth=1 C = US, O = Let's Encrypt, CN = R3 verify return:1 depth=0 CN = origin.letsencrypt.org verify return:1 openssl s_client -connect valid-isrgrootx2.letsencrypt.org:443 -quiet depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1 verify return:1 depth=1 C = US, O = Let's Encrypt, CN = R3 verify return:1 depth=0 CN = origin.letsencrypt.org verify return:1Не забываем перезагрузить апач / php-fpm
service httpd reload service php-fpm reloadComraddm
05.10.2021 14:09Делаю все по вашей инструкции, но пакет не собирается утилитой rpmbuild с ошибками:
patching file doc/apps/openssl.pod patching file doc/apps/s_client.pod patching file doc/apps/smime.pod patching file doc/apps/s_server.pod patching file doc/apps/verify.pod patching file doc/ssl/SSL_accept.pod patching file doc/ssl/SSL_clear.pod patching file doc/ssl/SSL_COMP_add_compression_method.pod patching file doc/ssl/SSL_connect.pod patching file doc/ssl/SSL_CTX_add_session.pod patching file doc/ssl/SSL_CTX_load_verify_locations.pod patching file doc/ssl/SSL_CTX_set_client_CA_list.pod patching file doc/ssl/SSL_CTX_set_session_id_context.pod patching file doc/ssl/SSL_CTX_set_ssl_version.pod patching file doc/ssl/SSL_CTX_use_psk_identity_hint.pod patching file doc/ssl/SSL_do_handshake.pod patching file doc/ssl/SSL_read.pod patching file doc/ssl/SSL_session_reused.pod patching file doc/ssl/SSL_set_fd.pod patching file doc/ssl/SSL_set_session.pod patching file doc/ssl/SSL_shutdown.pod patching file doc/ssl/SSL_write.pod + echo 'Patch #83 (openssl-1.0.1e-bad-mac.patch):' Patch #83 (openssl-1.0.1e-bad-mac.patch): + /bin/cat /root/rpmbuild/SOURCES/openssl-1.0.1e-bad-mac.patch + /usr/bin/patch -p1 -b --suffix .bad-mac --fuzz=0 patching file crypto/evp/e_aes_cbc_hmac_sha1.c + echo 'Patch #84 (openssl-1.0.1e-trusted-first.patch):' Patch #84 (openssl-1.0.1e-trusted-first.patch): + /bin/cat /root/rpmbuild/SOURCES/openssl-1.0.1e-trusted-first.patch + /usr/bin/patch -p1 -b --suffix .trusted-first --fuzz=0 patching file apps/apps.c patching file apps/cms.c patching file apps/ocsp.c patching file apps/s_client.c patching file apps/smime.c patching file apps/s_server.c patching file apps/s_time.c patching file apps/ts.c patching file apps/verify.c patching file crypto/x509/x509_vfy.c Hunk #1 succeeded at 205 (offset -2 lines). patching file crypto/x509/x509_vfy.h patching file doc/apps/cms.pod patching file doc/apps/ocsp.pod patching file doc/apps/s_client.pod Hunk #2 succeeded at 109 (offset 1 line). patching file doc/apps/smime.pod patching file doc/apps/s_server.pod Hunk #2 succeeded at 175 (offset 6 lines). patching file doc/apps/s_time.pod patching file doc/apps/ts.pod patching file doc/apps/verify.pod Hunk #2 succeeded at 58 (offset 1 line). patching file crypto/x509/x509_vpm.c Hunk #1 FAILED at 322. 1 out of 1 hunk FAILED -- saving rejects to file crypto/x509/x509_vpm.c.rej error: Bad exit status from /var/tmp/rpm-tmp.D4AekN (%prep) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.D4AekN (%prep)Snooper
05.10.2021 14:43+1Проблема в табах, в моём сообщении они заменились на пробелы.
https://mega.nz/file/aNh01bAJ#i0vaTcpGqD_xasQa3-Ketm4x9mv8sSbC0s1pdoW-cVw
Здесь файл с текстом с табами.
Содержимое нужно скопировать и вставить в указанный в инструкции файл.
Отредактировать предыдущее сообщение уже не могу.
Обновил ссылку
Comraddm
05.10.2021 17:40Что-то ничего не выходит, опять куча ошибок, перепробовал уже много способов.
Оказалось, что корректно вставить в файл этот кусок не так просто, если там важны все символы вплоть до таба и перевода строки. Nano и Mcedit не могут вставить корректно, форматирование едет.
Вы могли бы выложить готовый файл openssl-1.0.1e-trusted-first.patch с уже вписанным в конец куском?
Snooper
05.10.2021 17:44+1Comraddm
05.10.2021 18:06На этот раз собралось. Но при установке ругается:
--> Running transaction check ---> Package glibc.i686 0:2.12-1.212.el6_10.3 will be installed --> Processing Dependency: libfreebl3.so(NSSRAWHASH_3.12.3) for package: glibc-2.12-1.212.el6_10.3.i686 --> Processing Dependency: libfreebl3.so for package: glibc-2.12-1.212.el6_10.3.i686 ---> Package krb5-libs.i686 0:1.10.3-65.el6 will be installed --> Processing Dependency: libselinux.so.1 for package: krb5-libs-1.10.3-65.el6.i686 --> Processing Dependency: libkeyutils.so.1(KEYUTILS_0.3) for package: krb5-libs-1.10.3-65.el6.i686 --> Processing Dependency: libkeyutils.so.1 for package: krb5-libs-1.10.3-65.el6.i686 ---> Package libcom_err.i686 0:1.41.12-24.el6 will be installed ---> Package zlib.i686 0:1.2.3-29.el6 will be installed --> Running transaction check ---> Package keyutils-libs.i686 0:1.4-5.el6 will be installed ---> Package libselinux.i686 0:2.0.94-7.el6 will be installed ---> Package nss-softokn-freebl.i686 0:3.44.0-6.el6_10 will be installed --> Finished Dependency Resolution Error: Multilib version problems found. This often means that the root cause is something else and multilib version checking is just pointing out that there is a problem. Eg.: 1. You have an upgrade for openssl which is missing some dependency that another package requires. Yum is trying to solve this by installing an older version of openssl of the different architecture. If you exclude the bad architecture yum will tell you what the root cause is (which package requires what). You can try redoing the upgrade with --exclude openssl.otherarch ... this should give you an error message showing the root cause of the problem. 2. You have multiple architectures of openssl installed, but yum can only see an upgrade for one of those arcitectures. If you don't want/need both architectures anymore then you can remove the one with the missing update and everything will work. 3. You have duplicate versions of openssl installed already. You can use "yum check" to get yum show these errors. ...you can also use --setopt=protected_multilib=false to remove this checking, however this is almost never the correct thing to do as something else is very likely to go wrong (often causing much more problems). Protected multilib versions: openssl-1.0.1e-59.el6.x86_64 != openssl-1.0.1e-58.el6_10.i686
Snooper
05.10.2021 18:15+1Проверьте не установлен ли у вас openssl-devel
Или удалите его или установите пересобранный
yum remove openssl-devel
Все пересобранные пакеты лежат в
/root/rpmbuild/RPMS/x86_64/
Comraddm
05.10.2021 19:03Огромное Вам спасибо, на тестовом сервере все собралось и работает. Пока проблем не обнаружено.
Даже на родном пакете сертификатов от Centos 6.10 все работает без необходимости добавления новых и удаления старых CA.
Оба сертификата ISRG Root X1 и DST Root CA X3 присутствуют, но работе не мешают.
steppen
29.09.2021 19:45+1Прошу прощения за, возможно, глупый вопрос, но есть ли возможность в старом рутованном Android/джейлбрейкнутом iOS так же конфигурировать сертификаты, как в случае с Linux? Может быть, как-нибудь задействовать Termux/iSH? Кто-нибудь пробовал?
DaemonGloom
29.09.2021 21:05В Android сертификаты можно поставить и без рута.
steppen
29.09.2021 21:27Это хорошо, а как же iOS?
nikit0s
30.09.2021 02:40А iOS автоматом обломается, во всяком случае с выпуском сертификата Root CA X3, новый вышел 4 сентября, а в iOS 15, пакет сертификатов датирован 2021072200 (во всяком случае на SE, Trust Store Version именно такая). Так что ожидаются очередные проблемы. По первой придётся добавлять обновленный руками. (p.s. на iOS их тоже можно добавить без рута)
vikarti
30.09.2021 22:43Поставить — можно.
А приложения могут (и по умолчанию начиная с Android 7 — будут, разработчик может решить иначе) игнорировать то что в user store стоит
navion
30.09.2021 18:47iOS похоже не умеет достаривать цепочку доверия и если сервер отдаст новый сертификат со старым R3, то клиенты увидят ошибку о недоверенном сертификате.
Если возникла такая ошибка, то проверьте какие сертификаты отдаёт сервер
openssl s_client -showcerts -connect <fqdn>:443И добавьте новый сертификат Let’s Encrypt R3 в fullchain.pem, *.jks или Intermediate Certification Authorities вместо старого на сервере.
maxwolf
01.10.2021 13:04+6Тут дело не столько в iOS, сколь в том, что Letsencrypt в своё время решила проблемы «объехать на кривой козе». Про это везде упоминается как-то вскользь, но вообще-то сертификатов «ISRG Root X1» в мире циркулирует два. Они оба имеют одинаковые значения полей Subject и Subject Key Identifier (а именно по этим полям строится цепочка доверия), но разные значения других полей, например, Serial (кому интересно: 91:2b:08:4a:cf:0c:18:a7:53:f6:d6:2e:25:a7:5f:5a и 82:10:cf:b0:d2:40:e3:59:44:63:e0:bb:63:82:8b:00). При этом один — ссылается на ныне почивший корневой сертификат «DST Root CA X3», а второй — сам на себя (т.е. является самоподписанным корневым сертификатом). И именно этот «трюк» позволил в своё время быстро добиться широкого распространения сертификатов от letsencrypt, а теперь является причиной головной/попной боли. Насколько я понял, цепочка доверия сертификатов, если сервер отдаёт её всю, в разных местах проверяется по-разному: где-то более «старший» сертификат сначала ищется в локальном хранилище, а потом в присланной цепочке, где-то наоборот, где-то — промежуточные сертификаты ищутся в присланной цепочке, а самый корневой — в хранилище. От этого возникают (отнюдь не облечающие понимание проблемы) ситуации, когда стоящие рядом устройства, даже с одинаковым содержимым локального хранилища доверенных сертификатов, по-разному реагируют на один и тот же сервер.
navion
01.10.2021 15:30У Sectigo тоже две цепочки, но они хотя бы равноценные.
Ещё IIS сам выбирает какие промежуточные сертификаты отдавать клиентам на основе хранилища Intermediate Certification Authorities у аккаунта компьютера и пользователя SYSTEM (S-1-5-18). Возможно придётся чистить старые R3 в двух местах, чтобы ушла ошибка на клиентах.
maxwolf
06.10.2021 19:46У Sectigo что, тоже есть два разных сертификата с одинаковыми Subject и Subject Key Identifier?!
navion
07.10.2021 16:21Разные, но похожие friendly names в системном хранилище сбивают с толку:
Правильный тут Sectigo (AAA).
maxwolf
08.11.2021 23:45Себе на память: такая же беда и сертификатом C=US, O=GeoTrust Inc., CN=GeoTrust Global CA
WickedPacman
30.09.2021 18:57+2Сегодня всей командой боролись с проблемой этого сертификата. Использовали Node.js старой версии. Вопрос к сообществу, кто как предвосхищает данные проблемы, кроме как читает новостные IT ленты?
SkryabinD
30.09.2021 20:16А можете уточнить, причем тут Node.js? у меня просто тоже нода не везде новая, но я что-то не вижу, где там могут всплыть проблемы.
WickedPacman
30.09.2021 22:01+1в ноде встроенные сертификаты захардкоженные. И в 8й версии был данный сертификат - у нас все сервера начали валиться, где была 8я нода, 12ю не затронуло
CherryPah
30.09.2021 20:28Мониторинг. По поводу как проверять сроки действия сертификатов тем же заббиксом статей написано вагон и тележка.
DevAdv
30.09.2021 22:06+2Кого ещё задело: в Android, включая последний на данный момент Android 11, отвалился DNS-over-TLS (DoT).
Обсуждение в community.letsencrypt.org
vikarti
30.09.2021 22:46+1У Домру(Эртелеком) при входе в чат поддержки сообщение
Сервисное сообщение:
СЕГОДНЯ РЕЗКО ПЕРЕСТАЛИ ОТКРЫВАТЬСЯ САЙТЫ? Дело в устаревшем сертификате безопасности на вашем устройстве. РЕШЕНИЕ ЗДЕСЬ! (в РЕШЕНИЕ ЗДЕСЬ! — ссылка на эту статью -:)).
Пока не посмотришь куда ссылка — первые ощущения что решили перенимать передовой зарубежный опыт (см https://habr.com/ru/news/t/531642/)
vasyambass
30.09.2021 23:08у меня видновс 7 с отключенными обновлениями
перестало открываться 50% сайтов. что делать ?)
rantal Автор
30.09.2021 23:49+1Включить и установить обновления. Возможно, что хватит одного этого: https://www.microsoft.com/ru-RU/download/details.aspx?id=45633
vasyambass
01.10.2021 00:04не помогла та штука.. а если включить обновления на пиратской версии лицензия слетит?
NVnz
01.10.2021 12:23Если включить автоматические обновления, то слетит из-за какого-нибудь kb971033. В такой ситуации лучше изучать обновления и ставить необходимые
(Откройте «Центр обновлений Windows» ;
В списке слева найдите и откройте пункт «Настройка параметров»;
Под графой «Важные обновления» в ниспадающем списке выберите пункт «Загружать, но решения об установке принимаются мной» либо «Решения об установке и загрузке принимаются мной»;
Нажмите «Ок».)
SagePtr
01.10.2021 16:32Как вариант, можно поставить неофициальный пакет обновлений от Simplix, он поисключал оттуда некоторые обновления, связанные с проверкой активации и отправкой телеметрии. На свой страх и риск, разумеется.
Survtur
01.10.2021 08:46+1Если нужно просто открывать сайты, то установить Firefox, внутри которого есть нужные сертификаты.
vikarti
01.10.2021 00:57+1Joplin (opensource-аналог Evernote, в отличии от Evernote — работающий нормально, хоть и написан на Web-технологиях)+Win10+Joplin Server в docker'е = "certificate has expired".
перед контейнером стоит nginx, c сертификатом от let's encrypt.
на mac/android проблемы нет (у меня по крайней мере)Причем багу уже признали — https://discourse.joplinapp.org/t/certificate-has-expired-error-with-joplin-cloud-and-workaround/20638
Для Joplin Server — достаточно руками сертификат обновить — https://github.com/electron/electron/issues/31212#issuecomment-931486784. (для Joplin Cloud это уже сделано)
Хотя проблема — в Electron'е и вроде как фикс делают но это все приложения кто использует Electron должны обновится.
gekl
01.10.2021 08:24+3https://certbot.eff.org/lets-encrypt/ubuntuxenial-nginx ставим последний certbot
certbot renew --preferred-chain "ISRG Root X1" --force-renewal
systemctl restart nginx
abramovanton
01.10.2021 08:25+1Сломалось :)
OpenSSL 1.0.2k-fips 26 Jan 2017
CentOS Linux release 7.9.2009 (Core)
BitrixVM 7.5.0
Помогает обновление системы (или пакета), там прилетел ca-certificates 2021.2.50-72.el7_9ALexhha
04.10.2021 12:35Помогает обновление системы (или пакета), там прилетел ca-certificates 2021.2.50-72.el7_9
Я может что упускаю, но в чистом doсker - не работает
# lsb_release -a LSB Version: :core-4.1-amd64:core-4.1-noarch Distributor ID: CentOS Description: CentOS Linux release 7.9.2009 (Core) Release: 7.9.2009 Codename: Core # openssl version OpenSSL 1.0.2k-fips 26 Jan 2017 # rpm -qa | grep ca-certificate ca-certificates-2021.2.50-72.el7_9.noarch # curl -i -I https://valid-isrgrootx1.letsencrypt.org/ curl: (60) Peer's Certificate issuer is not recognized. More details here: http://curl.haxx.se/docs/sslcerts.html curl performs SSL certificate verification by default, using a "bundle" of Certificate Authority (CA) public keys (CA certs). If the default bundle file isn't adequate, you can specify an alternate file using the --cacert option. If this HTTPS server uses a certificate signed by a CA represented in the bundle, the certificate verification probably failed due to a problem with the certificate (it might be expired, or the name might not match the domain name in the URL). If you'd like to turn off curl's verification of the certificate, use the -k (or --insecure) option.abramovanton
04.10.2021 13:44А что за "чистый docker"?
ALexhha
04.10.2021 14:36А что за "чистый docker"?
$ docker pull centos:7 $ docker run -it --rm centos:7abramovanton
04.10.2021 23:26похоже, что разные репозитории для образов, так как у меня так и работает, но тут совсем нет что-то openssl, а как раз до версии 1.1.1 проблемы
спойлер
$ docker pull centos:7
# docker.io/library/centos:7$ rpm -qa | grep ca-certificate
# ca-certificates-2020.2.41-70.0.el7_8.noarch$ cat /etc/centos-release
# CentOS Linux release 7.9.2009 (Core)$ openssl version
# bash: openssl: command not found
$ curl -i -I https://valid-isrgrootx1.letsencrypt.org/
DaemonGloom
04.10.2021 14:17Обычный Centos (не контейнер) — та же версия openssl и сертификатов, проблем нет. Видимо, нужно что-то ещё из пакетов. Или перезапустить контейнер?
ALexhha
04.10.2021 14:55Я проверял с помощью простого Dockerfile'а
FROM centos:7 RUN yum -y update && yum -y install curl wget ENTRYPOINT ["curl", "-i", "-I"]И делаем простую проверку
$ docker run -it --rm curl-test https://www.centos.org/ curl: (60) Peer's Certificate issuer is not recognized. More details here: http://curl.haxx.se/docs/sslcerts.html ... ...
tomfrasher
01.10.2021 08:26Да, из-за этого теперь сервер не может сам к себе обратиться по SSL выходит ошибка handshake. Решается проблема в добавление в исключение сертификата и обновлением правил. Спасибо за статью, очень помогло решить с некоторыми сайтами.
creker
01.10.2021 11:46+1Обновить ОСь, добавить или удалить серты - это все ерунда и итак понятно. У меня это все поломало freeipa, где для вэбки и ldap сервера был настроен let's encrypt серт. Вот где приключения. Гениальные программисты решили, что это хорошая идея, обращаться к этому же серверу по http, чтобы установить в него серт. Естественно обратиться к нему невозможно из-за этого самого серта.
SilverFire
01.10.2021 12:45На старых ОС где нет возможности обновить OpenSSL, можно удалить сертификат `DST Root CA X3` чтобы он не мешал.
Для Debian/Ubuntu:
sudo rm /usr/share/ca-certificates/mozilla/DST_Root_CA_X3.crt sudo update-ca-certificatesmaxwolf
01.10.2021 15:02Этого не достаточно. См. мой камент выше. Нужно ещё убедиться, что имеющийся корневой сертификат «ISRG Root X1» — «правильный». Например, запустив
openssl x509 -inform PEM -in /usr/share/ca-certificates/mozilla/ISRG_Root_X1.crt -text -noout
и проверив, что Serial у него «82:10:cf:b0:d2:40:e3:59:44:63:e0:bb:63:82:8b:00» (или что Issuer — такой же, как и Subject). Если «ISRG Root X1» — неправильный, то нужно обновить и его (как уже описывали выше выше).
netruxa
01.10.2021 17:44Большое спасибо за статью)
На моем стареньком debian 9 вчера отвалилась команда wget. Все запросы заканчивались ошибкой
ERROR: The certificate of ‘parserrf.ru’ is not trusted.
ERROR: The certificate of ‘parserrf.ru’ has expired.netruxa
04.10.2021 10:29помогло в файле /etc/ca-certificates.conf восклицательный знак !mozilla/DST_Root_CA_X3.crt и update-ca-certificates
Gartos_DK
02.10.2021 15:29На Центосях можно дернуть curl -k https://letsencrypt.org/certs/isrgrootx1.pem.txt, подкинув его в /etc/pki/ca-trust/source/anchors
После update-ca-trust extract и дальше радуемся жизни))
Comraddm
08.10.2021 13:30+1Подводя итоги для решения этой проблемы в Centos 6.10
Есть два способа решения проблемы.
1) Перекомпиляция и сборка RPM пакета родного openssl 1.0.1e
Описано тут: https://habr.com/ru/post/580092/comments/#comment_23548598
Если будет ругаться при сборке, возможно, потерялось форматирование.
Меняем файл /root/rpmbuild/SOURCES/openssl-1.0.1e-trusted-first.patch на этот: https://habr.com/ru/post/580092/comments/#comment_23557622
И пересобираем опять
rpmbuild -bb /root/rpmbuild/SPECS/openssl.specЕсли будет ругаться при установке RPM, удалить или обновить пакет openssl-devel:
https://habr.com/ru/post/580092/comments/#comment_23557758
Редактировать списки сертификатов не обязательно, будет работать и с теми, что есть.
2) Способ - Перекомпиляция и сборка openssl 1.0.2k из Centos 7.9
Я собирал только первую часть, ca-certificates RPM не собирал, там есть ошибки.
Вместо этого можно создать файл
/etc/pki/ca-trust/source/blacklist/DST_Root_CA_X3.crtтакого содержания:
DST Root CA X3 ============== -----BEGIN CERTIFICATE----- MIIDSjCCAjKgAwIBAgIQRK+wgNajJ7qJMDmGLvhAazANBgkqhkiG9w0BAQUFADA/MSQwIgYDVQQK ExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMTDkRTVCBSb290IENBIFgzMB4X DTAwMDkzMDIxMTIxOVoXDTIxMDkzMDE0MDExNVowPzEkMCIGA1UEChMbRGlnaXRhbCBTaWduYXR1 cmUgVHJ1c3QgQ28uMRcwFQYDVQQDEw5EU1QgUm9vdCBDQSBYMzCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAN+v6ZdQCINXtMxiZfaQguzH0yxrMMpb7NnDfcdAwRgUi+DoM3ZJKuM/IUmT rE4Orz5Iy2Xu/NMhD2XSKtkyj4zl93ewEnu1lcCJo6m67XMuegwGMoOifooUMM0RoOEqOLl5CjH9 UL2AZd+3UWODyOKIYepLYYHsUmu5ouJLGiifSKOeDNoJjj4XLh7dIN9bxiqKqy69cK3FCxolkHRy xXtqqzTWMIn/5WgTe1QLyNau7Fqckh49ZLOMxt+/yUFw7BZy1SbsOFU5Q9D8/RhcQPGX69Wam40d utolucbY38EVAjqr2m7xPi71XAicPNaDaeQQmxkqtilX4+U9m5/wAl0CAwEAAaNCMEAwDwYDVR0T AQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFMSnsaR7LHH62+FLkHX/xBVghYkQ MA0GCSqGSIb3DQEBBQUAA4IBAQCjGiybFwBcqR7uKGY3Or+Dxz9LwwmglSBd49lZRNI+DT69ikug dB/OEIKcdBodfpga3csTS7MgROSR6cz8faXbauX+5v3gTt23ADq1cEmv8uXrAvHRAosZy5Q6XkjE GB5YGV8eAlrwDPGxrancWYaLbumR9YbK+rlmM6pZW87ipxZzR8srzJmwN0jP41ZL9c8PDHIyh8bw RLtTcm1D9SZImlJnt1ir/md2cXjbDaJWFBM5JDGFoqgCWjBH4d1QB7wCCZAA62RjYJsWvIjJEubS fZGL+T0yjWW06XyxV3bqxbYoOb8VZRzI9neWagqNdwvYkQsEjgfbKbYK7p2CNTUQ -----END CERTIFICATE-----и выполнить эти команды:
update-ca-trust enableupdate-ca-trustТем самым мы внесли в черный список истекший корневой сертификат DST Root CA X3
Проверяем:
openssl s_client -connect valid-isrgrootx1.letsencrypt.org:443 -quiet depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1 verify return:1 depth=1 C = US, O = Let's Encrypt, CN = R3 verify return:1 depth=0 CN = origin.letsencrypt.org verify return:1Все работает. Так же надо перезапустить apache/nginx/php-fpm.
3aBulon
12.10.2021 13:20На Win XP проявляется странным образом, установленный антиврус AVG Free блочит сайты ругаясь на сертификат, не давая возможности разрешить, прям вообще никак.
rantal Автор
15.10.2021 22:17В статье Scott'а Helme предложен интересный метод обойти проблему для совсем старых версий OpenSSL (начиная с версии 0.9.8m). Метод основан на том, что OpenSSL не проверяет сигнатуру сертификатов, хранящихся в локальном защищенном хранилище. Таким образом, можно изменить время действия сертификата в защищенном хранилище, при этом модифицированный сертификат будет по-прежнему восприниматься OpenSSL как валидный, несмотря на то, что целостность сертификата нарушена. Добавил этот метод в статью.
BunkerBy
26.10.2021 11:07На Lenovo B8080-F (Android 4.4.2) и Lenovo TB3-X70L (Android 6) внезапно перестало заходить c Chrome на один сайт. При этом на Sony Tablet Z2 (Android 6.0.1) на этот же сайт заходило нормально. Вспомнил про эту статью, установил на оба Lenovo сертификат ISRG Root X1, скачав по ссылке из статьи, и сайт снова стал доступен.
sergey-kuznetsov
Часть пользователей может столкнуться, либо часть пользователей столкнутся.