Как стать автором
Обновить

Комментарии 245

Часть пользователей может столкнуться, либо часть пользователей столкнутся.

Этот DST Root CA X3 это какая-то катастрофа. Я так и не смог заставить .net core на ubuntu 21.04 доверять сертификатам let's encrypt после того как его из ca-certificates убрали. Орет что недоверяет одному из сертификатов в цепочке и все. Пришлось накатывать предыдущую версию ca-certificates пока DST Root CA X3 не истечет.

Только мне кажется, что пользователям от всей этой дебильной криптографии больше проблем, чем пользы? HTTPS по сравнению с простым HTTP защищает разве только от подмены пакетов провайдером, и то лишь до поры до времени. А вот проблем с этими уродскими сертификатами выше крыши.

Спрашиваю как человек с предметными знаниями чуть выше абсолютного нуля: разве HTTPS не предполагает шифрование пакетов, и почему подмена в конечном счёте возможна и реализуема?

HTTP, как я понимаю, абсолютно беззащитен перед любым агентом, который может вклиниться между клиентом и сервером.

и почему подмена в конечном счёте возможна и реализуема?

Возможна, но только в некоторых, очень отдельных случаях.

Такая вот штука есть, например -- https://www.telerik.com/fiddler (но не только она, есть и аналогичные решения)

Это, среди прочего, дебаггер HTTPS-сессий в виде сквозного прокси. Он подставляет самоподписанные сертификаты на целевой домен. Конечно же, такой сертификат не имеет цепочки доверия до корневого и браузер сразу покажет, что там что-то не то. Но для отладки сгодится (если воткнуть в доверенное хранилище сертификат самого fiddler или отключить проверку).

Также это прокатывает, если влазят в трафик не браузера, а какой-нибудь игры или клиентского приложения, которое общается с сервером по HTTPS. Разработчикам обычно влом реализовывать как certificate pinning, так и жалобы на отсутствие цепочки доверия.

Разработчикам обычно влом реализовывать как certificate pinning, так и жалобы на отсутствие цепочки доверия
Будет возможность перечислить несколько относительно популярных приложений или игр, которые пропускают MITM без уведомления или «падения»? Если о certificate pinning еще можно допустить, то о работе кода с отключенной проверкой цепочки доверия слова звучат не совсем убедительными.

Во времена бурной молодости.... Ну то есть, до середины 2016 года примерно, разрабатывал я эмулятор Ingress путём реверса его протокола. Почти ничего сложного не было, там внутри такой себе json-rpc на стероидах. Но приходилось очень плотно сидеть в дебаггере https, на что клиент игры и ухом не моргнул, не смотря на то, что я никаких посторонних сертификатов ему не пихал.

Возможно, вы добавляли сертификаты в ПК или смартфон когда-либо ранее, перед работой с Ingress?

Вот вы спросили, и я уже засомневался :(

За давностью лет технических подробностей не помню, к сожалению. Может и добавлял. А может и нет, судя по тому, что я сейчас не знаю, как это делается.

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

Скорее всего там использовалась переменная окружения в windows SSLKEYLOGFILE которая сохраняет ключи во время рукопожатия, что позволяет дебагерам читать весь стрим. Это не MITM, так как дебагер на стороне, которой пакет и предназначался.

Нет, фиддлер в данном случае работал как HTTPS прокси, а запросы шли на сервер игры (не локальный)

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

Про clientBlob я в курсе. Разломать его не удалось ни мне, ни минскому аэроклубу, евпочя. Это смогли только покемонщики.

Тем не менее, мой эмулятор более-менее успешно работал, подставляя рандомно один из ранее заснифаных клиент-блобов. Видимо, проверка валидности клиент-блоба была включена не на всех функциях, а только на самых критичных, типа чтения карты с произвольным cellID или транзакции с глифами. На остальных он до 2016 года не проверялся. А потом как начал :( И проект пришлось прикрыть.

У покемонов был другой блоб, ощутимо проще. А ингрессовский таки был разломан, и успешно эксплуатировался в определённых кругах до смерти апи старого сканера.

Мой эмуль был уникальным в том что он не через интел работал, а через betaspike API, то есть эмулил сам клиент :) Умел сам качаться, сносить, деплоить, поля крыть... Эх, времена.

На реддите вон что пролетало
image

image

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

Последний раз проверял году в 2019, тогда еще не было исправлено. Подозреваю и до сих пор не исправлено, но следует снова перепроверить.

Last Epoch из актуального. Умельцами под черным флагом альтернативная авторизация на серверах игры реализована как раз через Fiddler

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

Я отвечал на вопрос, при каких условиях MITM с https может работать. То, что для этого требуется предварительный админский доступ к машине жертвы -- ну да, а вы чего ожидали? Готового эксплойта а-ля «Взломщик Интернета», что ли?

Нетхак он такой. На 99% состоит из эксплуатации человеческой тупости, и только на 1% -- из эксплуатации технических недостатков IT систем.

Или получить доступ к сертификату СА, который в доверенных по умолчанию. Менее реалистично, но возможно

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

Существуют правила. Root ключи держат отключенными от интернета в криптомодуле. Можно гарантировать, так как тибериумный реверсинг уничтожит чип.

Для начала, есть правило запрещающее переходить дорогу на красный свет, и?

Ну держат CA свои приватные ключи отдельно от интернета в криптомодуле, дальше что? Механизм взаимодействия есть, просто потому что их используют для подписи других сертификатов. Ты можешь гарантировать что завтра в офис не придут люди с автоматами и не потребуют доступа к модулю? Или просто, сотрудник получавший соответствующий доступ не подпишет какой то левый сертификат с своими, сомнительными целями?

Как минимум такие случаи были и в наше время выявляются достаточно быстро через тот же Transparency Log. Собственно, кейс с сертом гугла фактически показал, как быстро теряется доверие к CA. В будущем действующая иерархическая модель PKI может вообще исчезнуть, уступив место тому же DANE (там тоже есть иерархия, но на уровне DNS).

Мне тоже эти https не очень. Да есть шифрование, но смысл от него, если провайдер захочет вставить прокси со своим сертификатом, то как я смогу отказаться от этого? Придется пользоваться и разрешать подмену.

В http сами авторы сайта делали шифрование своих данных, кто хотел. Я вот на своем простеньком сайте сделал логин и регистрацию через rsa и aes, кто-то сделает еще как-то, третий сделает своим способом. Чтобы сломать, нужно ломать каждого по отдельности, а https один раз сломать и всё открыто, авторы не заморачиваются с защитой и шифрованием, оно же есть

если провайдер захочет вставить прокси со своим сертификатом, то как я смогу отказаться от этого?

Перейти к другому провайдеру.

Перейти к другому провайдеру.

Иногда для этого надо менять район проживания.

Лучше сразу страну

Подскажете на какую, и желательно чтоб с гарантией что ее тоже вскоре не придется менять)

Простите, что я отвечаю, а не @farafonoff. Например, можно переехать в Исландию, Норвегию, Швецию, Швейцарию, Нидерланды, Польшу, Канаду, США и т.д.

Да неважно кто отвечает, важно какие гарантии что вскоре ее не придется менять, и на сколько эти гарантии. Вот кстати на счет сша я бы не был так уверен... Шестое чувство)

Тогда куда-нибудь в страны Евросоюза. Или в Канаду. Не знаю, стоит ли оно того, но есть ещё возможность в страны Восточной Азии, например, Японию, Тайвань, Гонконг, Южную Корею. Хотя все же Европа лучше.

Если провайдер (хотя скорее всего государство через провайдера) захочет вставить прокси со своим сертификатом, то это уже политическая проблема, а не техническая, решать которую надо тоже политическими методами, а не техническими.

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

Не браузером единым.
Facebook как приложение тоже поменяете? Или только через православный браузер смотреть всем придется?

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

Условно говоря, на сайт банка вы через браузер худо-бедно сможете зайти. Но вот с мобильным приложением (клиент-банк) облом выйдет.

Это не так. Смотря что вы подразумеваете под один раз сломать.
Во первых есть наборы шифров которые не подвержены MITM атакам.
EDHE например.

Если вы раскроете приватный ключ как владелец сайта это уже другой вопрос.
Напомню что у провайдеров стоят железки из ФСБ которые анализируют весь трафик. в случае https они видят куда вы ходите не видя содержимого. В случае http они видят всё.

И я честный мне нечего скрывать тут не канает. У нас в стране за мемчики сажают, репосты, и смайлики

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

Я в этой теме не сильно хорош, может и чушь написал и такое невозможно сделать чисто технически

Никто не банит VPN. Это невозможно, это как сказать забанить командную строку. Как они собируются банить VPN в локальной сети без Интернета вообще, например?

Китай справился с VPN. С огромным пингом и ограничением до 64кб/с даже ssh не сильно приятно использовать)

1) Компании, которым нужен VPN это не ограничивают

2) Есть VPN и в китае, где скорость норм. Да и закона о VPN нет на самом деле. Это миф.

Вы говорите о "зарегистрированном" VPN. Я не уверен что подконтрольный VPNы, это то что вы хотели бы использовать для задач, где вам он собственно и нужен.

Я переодически живу в Китае - с vpnом там все норм, работает как часы.

Не сможете вы разрешить подмену во многих случаях:


  • кнопку "разрешить" потихоньку прячут.
  • есть HSTS (и в том числе HSTS preload) — с ним кнопки просто не будет. вообще.
  • разрешить методом установки указанного провайдером сертификата — а ничего что например на андроид начиная с 7 — куча ПО просто проигнорирует такую установку и будет вопить про неработу сети. Удачи провайдеру объяснять клиентам что это гугл виноват а не провайдер.
  • если разработчики браузеров посчитают что в данном случае не провайдера идея а государственная и кто-то оборзел — в браузеры прилетит бан конкретного вот этого сертификата провайдера — см например https://www.opennet.ru/opennews/art.shtml?num=54284

в браузеры прилетит бан конкретного вот этого сертификата

И будет провайдер раздавать своим клиентам не Хром, а Яндекс или Спутник, как когда-то делал AOL

Яндекс это же Chrome.

Изменённый. Как и Спутник/Амиго.

В нём Яндекс много своего добавил - от своих около-поисковых штучек и пользовательского интерфейса типа "Я Табло", до более низкоуровневых штучек типа выделения-копирования текста ссылок, Opera Turbo и шифрование ГОСТ в TLS.

Добавит он в свою ветку (git branch) ещё одно изменение - удаление из исходников конкретного "бана конкретного сертификата" - и всё, можно раздавать.

P.S. а AOL Browser тоже не в America onLine разрабатывался, а был перекрашенным MSIE, а потом перекрашенным NN, так что я его не просто так напомнил.

И на HSTS можно обойти, вбив секретную последовательность на клаве.

если провайдер захочет вставить прокси со своим сертификатом, то как я смогу отказаться от этого? 

А вы только браузером пользуетесь? Никаких клиентов типа Яндекс.Диск, OneDrive и прочего?

Такого рода клиента обычно точно знают сертификат сервера, к которому подключаются, и не смотрят на вами формируемое хранилище доверенных УЦ. Даже не столько для борьбы с MITM, сколько им просто не нужна вся эта история с тем, что кто-то кому-то должен подтвердить доверие. Они верят зашитому в них корпоративному сертификату (фингерпринт и т.п.)

Так что отвалится слишком много чего. Особенно на мобильных устройствах.

Нет. HTTPS предлагает систему шифрования, а систему доверия предлагает PKI.
Вот с PKI и HTTPS взаимодействии как раз таки проблемка. PKI нужно обновлять постоянно, а HTTPS - это просто протокол

А как это защитит от подмены сертификата людьми у которых есть доступ хотя бы к одному из удостоверяющих центров ?

Если у правительства или сотрудника удостоверяющего центра будет надобность не что не мешает выпустить и подписать такой же сертификат на любой домен (при том что прецедент уже был https://habr.com/ru/company/infopulse/blog/255251/), с любыми данными в полях но с другим приватным клюем и сделать MitM, единственно что будет не совпадать с оригиналом сертификата это хеш и цепочка доверия все остальное будет 1 в 1 и все будут ему доверять.

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

И если бы не Let's Encrypt мне вообще не понятно почему я должен платить кому-то, выглядит это как нарко кортель или крыша, мы вот свой корневой просунули в разные системы, а теперь если ты хочешь шифрование давай плати нам или иди лесом, а не шифрование тебе, при этом компания держатель корневого сертификата не несет по сути не каких издержек каждый платеж чистая прибыль. И тут можно сказать что у них сайт у них там сервис проверки на отозванные сертификаты но это все не работает по большому счету https://habr.com/ru/post/332730/. Так что если ваш приватный ключик скомпрометировали (ну случилось так сам лопух) то вам не кто не поможет и вашим старым сертификатом будут пользоваться до окончания его срока действия. Ну и что то я не разу не слышал что бы центр выплатил страховку, которую они так любят везде рекламировать, из за неработающего механизма отзыва сертификата.

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

Кстати — не только "публичных" в смысле доступных всем. tailscale вот умеет выпускать сертификаты на machine-name.generated-subdomain.ts.net, подразумевается что их увидят только те кто могут попасть к конкретной внутренней сетке tailscale. но при этом прямо выдается предупреждение что если machine-name это сама по себе какая то секретная инфа — то не надо этой функцией пользоваться потому что все уйдет в transparency log

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

Никто не пользуется сертификатом для шифрования. Только для подписи, ключи эфемерны ECDHE

Я скажу больше - конечный пользователь видит пресловутый значок замочка и думает, что его данные в безопасности. И он не понимает, что у него в системе может быть установлен корневой сертификат от товарища майора, или что сайт sberPank dot ru не является безопасным, несмотря на замочек.

или что сайт sberPank dot ru не является безопасным, несмотря на замочек.

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

Вопрос популярности. Я как то в качестве первоапрельской шутки создал фейковый сайт. Несмотря на то, что далеко не все оценили шутку и было много бугурта в сообществе. Домен всё ещё живёт и сертификат регулярно обновляется.

Я думаю чтобы центр сертификации почесался бы блокировкой должна накопиться какая то критическая масса жалоб. Для сайтов однодневок она может просто не успеть набраться. А за это время будет обмануто много людей.

Ну если это широко известно — прикрывают
Причем даже если сертификат формально выдан по правилам
см например https://www.bleepingcomputer.com/news/security/extended-validation-ev-certificates-abused-to-create-insanely-believable-phishing-sites/ — история с EV-сертификатом для Stripe, Inc (Имена компаний — НЕ глобально уникальны).

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

Показ «замочка» это наследие времён, когда большая часть соединений шла в незашифрованном виде, а безопасные соединения были чем-то таким, что выделялось на общем фоне.
У меня такая.

Проблема решится сама собой, когда будет 100% хттпс, и замочек можно будет убрать

Нет никакого замка в chrome canary.

Не только от подмены. Ещё он удостоверяет сервер. Конечно, если пользователь не полный дурак и умеет читать хотя бы.

А ещё можете пояснить, как можно по сертификату убедиться, что зашел на официальный сайт госуслуг?

Немного пояснения. Если зайти на сайт того же Сбера и посмотреть сертификат, там ясно написано: Страна:Ru, Организация:Sberbank of Russia PJSC и т.д.

А вот в сертификате gosuslugi.ru ничего такого нет; есть только общее имя, и с моей точки зрения он ничем не примечательнее сертификата того же dosuslugi.ru или gоsuslugi.ru (кстати, последний продается :=()

у Сбера сертификат выдан на организацию (как и должно собственно быть в большом бизнесе), а на госуслугах сертификат выдан просто на домен, как у любого простого частного сайта...Причем у Сбера сертификаты отдельные на все их поддомены (сервисы), а на госуслугах - один общий на всё

CN = *.gosuslugi.ru

----

CN = sberbank.ru

O = Sberbank of Russia PJSC

L = Moscow

S = Moscow

C = RU

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

Вот и я о том же...

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

А так какая в итоге разница, если это для конечного пользователя оба сертификата выглядят абсолютно одинаково? Раньше была плашка об организации, да, но сейчас её уже убрали.

Да, теперь пользователю нужно делать дополнительные усилия (клац-клац мышкой) и смотреть свойства сертификата :(

В фф это даже 4 клика, чтобы открыть сертификат.

Если бы там стоял бесплатный сертификат от Let's Encrypt, тогда это были бы не госуслуги, а мошеннический сайт. Так как на госуслугах стоит платный сертификат от Sectigo сроком на 1 год, пусть и всего лишь DV, а не OV или EV. Плюс ещё в домене нужно проверять каждый символ, чтобы было именно gosuslugi.ru или esia.gosuslugi.ru, но не никак не gOsusSlugi.ru Конечно, на государственном портале должен быть как минимум Organization Validation- сертификат, но лучше Extended Validation, то есть на организацию, а не просто на домен. Но что имеем то и имеем, к сожалению :(

Ну если заполнен признак O, то это уже не DV, а OV. Другое дело, что и DV и OV для внешнего наблюдателя выглядят практически одинаково.

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

Let's encrypt даёт сертификат на 3 месяца, так что критерий мошенничества как-то не очень.

Для меня признак мошеннического сайта — это краткосрочность действия его сертификата (3 месяца)
Сайт с меньшим временем действия сертификата при прочих равных наоборот может быть более безопасным — меньший шанс использования того же сертификата после утечки.

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

Это вопрос к владельцу сайта. Какой уровень подтверждения он хочет.Задача самого простого сертификата подтверждать только то, что заходя на gosuslugi.ru ты получаешь данные именно от gosuslugi.ru, а не от какого то другого.

Вот кстати, все ли браузеры покажут url как https://www.xn--gsuslugi-nbh.ru/ ? Или кто-то напишет "gоsuslugi.ru"?

gоsuslugi.ru

Многие DNS-регистраторы просто не разрешат регистрировать idn-имя, если в какой-либо его части встречаются одновременно символы нескольких алфавитов.
НЛО прилетело и опубликовало эту надпись здесь
і — \u0456
Кириллическая строчная буква «и десятеричное»
Все. Samsung браузер просто имеет баг, что не декодирует Punycode.

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

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

Подтверждаю. Большинство пользователей не просто не умеют читать, но даже не считают нужным это делать. Любое сообщение об ошибке вызывает два типа реакции: либо ступор, либо, в большинстве случаев, желание поскорее сообщение закрыть.

Айтишные после какого-то числа сотрудников ничем не отличаются от неайтишных и в них также нужно обучать основам ИБ.

И это число — 1

Подмена пакетов провайдером - это далеко не иллюзорная опасность. В РФ очень многие провайдеры подменяют код HTTP-сайтов и вклинивают в них свою рекламу. В результате у владельца сайта во-первых сразу падает выручка от рекламы, потому что кликают не по его баннеру а по провайдерскому, во-вторых браузерное ПО Яндекса и гугла детектирует аггресивную рекламу на сайте, стучит об этом хозяину и сайт получает пессимизацию в поиске вплоть до бана.

РКН, перелогиньтесь

Безопасность это не хуй собачий. И нужно шифровать. А с ESNI и DoH пакеты провайдер не поменяет. А без сертификатов никуда, или надо будет изобретать блокчейн интернет

Алексей, вам ничего не кажется. Вы всё правильно понимаете, но посмотрите сколько недоразвитых вас минусует... Вот в этом вся проблема. Поэтому вечно будут что-то вводить или отменять и, разумеется, всё это будет для "нашей с вами безопасности" :))

Проблемы в основном у любителей халявы. Там где покупные сертификаты пока всё работает отлично.

Проблемы в основном у любителей халявы. Там где покупные сертификаты пока всё работает отлично.


ага, конечно - https://www.opennet.ru/opennews/art.shtml?num=31678

Epic fails того же Verisign загуглите сами

Таракан без лап не слышит © ?

Этот зоопарк с кучей корневых сертификатов в текущем виде будет всегда проблемой.

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

И хорошего выхода не видно... Есть DANE, но там те же проблемы почти - ключ корня DNS нужно тоже иногда обновлять, хоть это и попроще чем сотни корневых.

Замену DANE можно скриптом автоматизировать, если используете Cloudflare. Блин, Cloudflare хоть и гигантская монополистическая машина, но такая, зараза, удобная. А, к сожалению, DANE сам не живой :( Ну только если в почте живёт, но и даже там некоторые почтовые серверы его не проверяют.

Замену DANE можно вообще не делать если менять только сертификат, не меняя пару ключей из которого он получается (опция --reuse-key в certbot)

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

Сейчас TLS есть даже в чайниках и лампочках, а кто будет обновлять в них список доверенных сертификатов?

А вот это даже хорошо, ибо если лампочка не можем законектица на удалённый сервер, то она не является уязвимостью :)

faketime на MacOS доступна в пакете libfaketime

brew install libfaketime

Let's Encrypt является профанацией безопасности, когда любой желающий без всяких даже намёков на подтверждение получает сертификат подлинности, как у настоящих подлинных сайтов. Либо скоро брузеры начнут банить такие сайты, либо сервис круто поменяется и начнет закручивать гайки. Я думаю эта вакханалия возможна только из-за переходного периода и всеобщего желания отказаться от незашифрованного http

Let's Encrypt выдаёт DV-сертификаты. Для них достаточно подтверждения владения доменом через размещение на своём сайте служебного файла или создания в своём DNS служебной записи.
Но получить совершенно произвольный сертификат не получится, попробуйте, например, получить там сертификат для habr.com.

В плане информационной безопасности вы очень узко мыслите. Домены-близнецы регистрировать ничего не мешает.

Так и OV- или EV-сертификат для домена-близнеца получить можно, было бы желание и деньги.

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

С чего бы это? DV-сертификат от Let's Encrypt технически ничем не отличается от DV-сертификата любого другого удостоверяющего центра.

Аргументация уровня "я так сказал".

Дак удали у себя. Тебе же половина интернета не нужна

Но получить совершенно произвольный сертификат не получится

Это у Васи Пупкина в интернете не получится. У товарища майора в чебурнете очень даже получится - с помощью НСДИ. Если авторитативный NS атакуемого домена находится в чебурнете то запросы от LE к нему проходят через НСДИ, которая может сформировать такие ответы, которые LE будет считать подтверждением того, что запрос на серт пришёл от админа домена.

тут в дело вроде бы должен вступить certificate transparency

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

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

(В браузере в просмотре сертификата смотреть в сторону SCT Version 1, Log Operator: Lets Encrypt; детальная инфа тут https://crt.sh/?q=habr.com)

Описанное вами "хождение сервера в CT" называется OCSP stampling и никак не предотвращает выдачу более одного сертификата на один домен.

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

OCSP stampling позволяет посылать такие запросы только со стороны вебсервера и только по расписанию. Ответы (так называемые штампы, они подписаны центром сертификации), действительно передаются браузеру. Если браузер получает от сервера сертификат со штампом, то он просто проверяет дату/время штампа и никаких запросов в сертификационный центр не делает.

Certificate Transparency другая технология, хотя и работает похожим образом. OCSP проверяет отзыв, а CT Log проверяет уникальность.

Почитайте, что такое poison CT. Но вообще Apple запретил серты без CT.
Не, ну для этого тов. майору надо знать волшебный ключик

Какие подтверждения нужны для получения сертификата удостоверяющего исключительно домен, кроме как подтверждение владения доменом?

вот так любой ботнет этим и пользуется: зарегят свой левый домен, разошлют спам со ссылкой, юзер открывает, а брузер говорит ему что всё ок, сертификат годный. Это только спецы понимают что надо читать сертификат и смотреть на строку адреса, а типовой рядовой пользователь, коих 99% когда видит зеленый щит в строке браузера - для него это значит что сайт подлинный.

вот так любой ботнет этим и пользуется: зарегят свой левый домен, разошлют спам со ссылкой, юзер открывает, а в заголовке страницы написано "Сбербанк". Это только спецы понимают что надо смотреть на строку адреса, а типовой рядовой пользователь, коих 99%, когда видит название фирмы на сайте - для него это значит что сайт подлинный.

А когда вы последний раз обновили свой браузер? Уже давно https помечается просто серым значком, а скоро и его планируют убрать.
Нет замочка — нет проблем, так ведь?

Надо просто понять одну простую вещь, что когда вы заходите на какой-то сайт, то замочек в адресной строке вовсе не означает, что сайт не мошеннический. Замочек означает только одно, что вы зашли ровно на тот сайт, адрес которого написан в адресной строке. Другими словами, что вам не подменили трафик. И всё! Это ровно то, чем занимается Let's Encrypt и это никакая не профанация. А то, что написано в адресной строке вы должны читать сами.

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

Почему вы решили, что проблемой скама нужно заниматься на уровне SSL? У него одна задача, не дать подменить трафик. А то, по вашему выходит, что Let's Encrypt должен решать, что тому можно сделать свой бложик, а вот тот выглядит подозрительно, ему нельзя? Вам не кажется, что это должно быть сделано как-то иначе, а не уровне шифрования трафика? У меня есть бложик, и я хочу, чтобы трафик там был зашифрован, иначе провайдер просто подсовывает в трафик свою рекламу. Почему я должен собирать какие-то документы, платить деньги, ждать чьего-то решения? Я просто хочу, чтобы трафик шифровался, и его не подменяли, и всё.

Специально для таких существуют самоподписанные сертификаты, чтобы никому ничего не платить. Ой что я слышу? Браузеры не пускают юзеров на твой бложик из-за соображений безопасности? Ай-яй-яй, вот идиоты и параноики эти хромы, эджи и фаерфоксы (как и я). А давай подпишем сервисом, который безотказен и его сертификат внедрен в любой браузер и проблема безопасности обойдена. Уловил теперь суть проблемы? Этот сервис тупо протащил в браузеры сертификаты по уровню доверия аналогичные самоподписанным.

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

Ещё раз, я считаю, что технология, обеспечивающая шифрование не должна заниматься аудитом. Этим могут заниматься:

а) правоохранительные органы;

б) регистраторы домена;

в) специализированное ПО на компьютере пользователя;

г) придумайте что-то своё

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

Как это с шифрованием трафика связано? И с проверкой того, что трафик пришел от того же домена, который указан в адресной строке?

Проблемы скама это совершенно никак не транспортный уровень. Многие браузеры реализуют предупреждения о том, что данный сайт "плохой", а яндекс браузер (насколько читал) прям какой-то серьезный инструмент для этого реализовал. Ставьте своим пользователям пожилого возраста яндеск браузер или поставьте фаервол с фильтрацией по белым спискам, но при чем тут сертификаты их валидация?

Это как пытаться решить проблему вопровства тем, что не выдавать ворам паспорт, чтобы они не могли на него симку зарегистрировать. Вот только нужно как-то понять, что человек вор, на момент выдачи паспорта - но это же не наша проблема, правда?

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

Комменты отлично демонстрируют розовые сопли и деградацию "спецов". Со временем только хуже будет.

Ну безопасники это какая-то мифическая ниша. Я из сетевика как-то хотел переквалифицироваться в безопасника, но.. я тупо не нашёл ни самих безопасников, ни каких-либо внятных мануалов. Вся ниша очень сильно закуклена саму на себя: всё как-бы есть, но только для участников. 120% шапошно-знакомых людей пролезших в кибербез подтвердили, что их туда звали, а не они сами это нашли: кого отличником из вуза дёрнули, кого знакомые подтянули.

Может поэтому и деградация спецов налицо: если свежей кровью хрен разбавишь - будет застой.

Не могли бы Вы так же привести соответствующие команды для Windows?

Сертификаты посмотреть, добавить, удалить можно запустив certmgr.msc. DST Root CA X3 лежит в доверенных корневых центрах сертификации.

Не факт только что современные браузеры (firefox, chrome) берут сертификаты из хранилища винды.

Google Chrome, а также Опера, Яндекс Браузер, Microsoft Edge, и т.д., используют сертификаты из системного хранилища Windows. Можете сами в этом убедиться, нажав на замок в адресной строке, а потом посмотрев информацию о сертификате. А Firefox использует свое хранилище сертификатов.

День Икс настал и на работе обнаружились несколько WinXP SP3 с изначально отключенным механизмом автообновлений. Также есть несколько WinXP SP3, которые без проблем подключаются к веб-серверу с сертификатом LE. Кто-нибудь уже нашёл, какое конкретно обновление надо установить и где его можно скачать?

Отдельное спасибо автору статьи за инструкцию для debian jessie, такая тоже ещё работает.

У Вас немного устаревшая информация. В Firefox есть параметр security.enterprise_roots.enabled (тип булево)

Начиная с Firefox версии 68, когда возникает ошибка TLS-соединения, Firefox автоматически активирует параметр Enterprise Roots и пытается подключиться снова. Если проблема устранена, то параметр Enterprise Roots остаётся включённым.

Понял. А каким образом благодаря этому параметру исправляется данная ошибка? Он заставляет Firefox использовать системное хранилище сертификатов в Windows вместо собственного? P. S Я не программист и не айтишник, и в этом плохо разбираюсь. Уж извините(

А, все, я уже узнал, за что отвечает этот параметр- благодаря нему Firefox импортирует сертификаты из хранилища Windows,в собственное хранилище сертификатов, чтобы устранять те самые ошибки безопасного соединения.

Скажем так, если у вас в Windows установлены обновления (а конкретно, обновления корневых сертификатов), то практически наверняка проблема не должна вас коснуться. Если только вы не пользователь чего-либо более старого, чем Windows XP SP3. Но в последнем случае современный HTTPS в любом случае не для вас, т.к. тогда у вас просто не будет поддержки кучи используемых сейчас в HTTPS шифров и т.п.

Тем не менее, если есть желание проверить и убедиться, то есть программа RunAsDate, аналог faketime для Windows.

Runasdate не сработает. Время проверяется на сервере.

Поясните, пожалуйста, свою мысль про проверку времени на сервере.

Для Windows 7 (на не обновленной отваливаются сайты в хроме, файрфокс работает норм)
Control Panel -> Internet Options -> Content -> Certificates -> Trusted Root Certification Authorities -> Import
сертификат лежит тут letsencrypt.org/certs/isrgrootx1.der
там же удалить DST Root CA X3

Спасибо. Заработало на старой 7-ке. А обязательно удалять DST Root CA X3? Там кнопка для удаления не активна.

Не проверял. Сделал как написано в рекомендациях. На что влияет хз(по идее сертификат и так не используется т.к. уже не валиден, возможно это приходится проверять каждый раз и будет медленнее), если и так работает то не надо :). Странно что кнопка не активна — может зайти под админом?

Про админа забыл. Благодарю.

извините, я плохо разбираюсь в пк, могли бы подсказать, где именно найти это - Control Panel -> Internet Options -> Content -> Certificates -> Trusted Root Certification Authorities -> Import, и какие действия нужно выполнить? Установил обновления UpdatePack7R2-21.9.15, всё работает, но ноутбук у меня старенький и после этого обновления он что-то тормозить начал. Хочу откатить всё назад. Было бы здорово, если можно было бы обновить только сам сертификат, а не всю систему. Благодарю!

У нас установлен 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 и все заработало.

Не совсем понятно из статьи, а что делать, если система старая и не доверяет 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

Спасибо, важное дополнение. Добавил в статью.

У меня на Ubuntu Server 14 sertbot перестал работать. Ругается что эта устаревшая система больше не поддерживается. Перевыпустить сертификат на ней теперь нельзя.

Хм, у меня, вроде, работает на 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

Сейчас попробовал обновить сертификал от Let's Encrypt и они выдают мне сертификат подписывая его старым Root CA X3 который закончится через 2 дня. Так и задумано или где-то проблема?

Так и задумано, основная цепочка останется 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).

Можно вопрос, а разве Let's Encrypt не дает только 2 бесплатных продления (3 месяца *3=9)? не проще просто перейти на другой УЦ?

Нет, Let's Encrypt бесплатен при любом числе продлений.

Утилита 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.crt

3) отредактировал скачанный 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

Ох, я бы вам пиво (или колы прохладной) поставил за это сообщение. Сегодня столкнулись на AWS Beantstalk. Работает с 4го пункта, достаточно забанить протухший сертификат.

Рад, что кому-то пригодилась информация!

:)

После добавления 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/

Может кто-то что-то подскажет?

Какая версия openssl? Столкнулся с тем, что, например, openssl 1.0.1k в debian jessie при наличии в доверенных ISRG Root X1 и удаленном из доверия DST Root CA X3 как раз выдает ошибку "unable to get local issuer certificate". А вот openssl 1.0.1t при тех же условиях работает корректно.

Вам придется обновиться минимум до 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. Есть еще одна идея, как обойтись без обновления - проверю, напишу

Ясно, спасибо за информацию.

А начиная с версии 1.0.1p openssl соотносит сертифкат с CN=ISRG Root X1 в trusted store и в цепочке, предоставляемой сервером, поэтому верификация проходит.

сопоставление идёт по CN?

Насколько я понимаю, сопоставление идёт по издателю (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 этого не было.

На Fedora 22:

OpenSSL 1.0.1k-fips

Но таки все работает:

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

Может сам бинарник 1.0.1k, а либы более свежие стоят? Например, все корректно работает при таком вот выводе openssl version:

OpenSSL 1.0.1k 8 Jan 2015 (Library: OpenSSL 1.0.1t 3 May 2016)

Все одной и той же версии:

#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 2015

Похоже тогда есть еще какой-то влияющий фактор, который мы не учитываем... Федоры нет под рукой для экспериментов. А на debian jessie openssl 1.0.1k (не fips правда) при наличии доверенного самоподписного ISRG Root X1 и исключенном DST Root CA X3 получается "unable to get local issuer certificate".

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

Собирал версии 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 reload

Делаю все по вашей инструкции, но пакет не собирается утилитой 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)

Проблема в табах, в моём сообщении они заменились на пробелы.

https://mega.nz/file/aNh01bAJ#i0vaTcpGqD_xasQa3-Ketm4x9mv8sSbC0s1pdoW-cVw

Здесь файл с текстом с табами.

Содержимое нужно скопировать и вставить в указанный в инструкции файл.

Отредактировать предыдущее сообщение уже не могу.

Обновил ссылку

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

Оказалось, что корректно вставить в файл этот кусок не так просто, если там важны все символы вплоть до таба и перевода строки. Nano и Mcedit не могут вставить корректно, форматирование едет.

Вы могли бы выложить готовый файл openssl-1.0.1e-trusted-first.patch с уже вписанным в конец куском?

На этот раз собралось. Но при установке ругается:

--> 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

Проверьте не установлен ли у вас openssl-devel

Или удалите его или установите пересобранный

yum remove openssl-devel

Все пересобранные пакеты лежат в /root/rpmbuild/RPMS/x86_64/

Огромное Вам спасибо, на тестовом сервере все собралось и работает. Пока проблем не обнаружено.

Даже на родном пакете сертификатов от Centos 6.10 все работает без необходимости добавления новых и удаления старых CA.

Оба сертификата ISRG Root X1 и DST Root CA X3 присутствуют, но работе не мешают.

Прошу прощения за, возможно, глупый вопрос, но есть ли возможность в старом рутованном Android/джейлбрейкнутом iOS так же конфигурировать сертификаты, как в случае с Linux? Может быть, как-нибудь задействовать Termux/iSH? Кто-нибудь пробовал?

В Android сертификаты можно поставить и без рута.

Это хорошо, а как же iOS?

А iOS автоматом обломается, во всяком случае с выпуском сертификата Root CA X3, новый вышел 4 сентября, а в iOS 15, пакет сертификатов датирован 2021072200 (во всяком случае на SE, Trust Store Version именно такая). Так что ожидаются очередные проблемы. По первой придётся добавлять обновленный руками. (p.s. на iOS их тоже можно добавить без рута)

Осталось заставить морочиться с этим тысяч пользователей нашего магазина

Поставить — можно.
А приложения могут (и по умолчанию начиная с Android 7 — будут, разработчик может решить иначе) игнорировать то что в user store стоит

НЛО прилетело и опубликовало эту надпись здесь
В частности, в certbot за возможность выбора альтернативной цепочки отвечает параметр --preferred-chain.

Нет такого параметра у сертбота.
Версия 0.27.0
На другой машине Ubuntu 20 с последними апдейтами
certbot 0.40.0
На сайте вижу что есть 1.19.0, но в пакетах только 0.40.0. Облом.

Удаляйте пакет, ставьте python3-pip и затем pip3 install certbot - будет вам версия посвежее.

iOS похоже не умеет достаривать цепочку доверия и если сервер отдаст новый сертификат со старым R3, то клиенты увидят ошибку о недоверенном сертификате.

Если возникла такая ошибка, то проверьте какие сертификаты отдаёт сервер
openssl s_client -showcerts -connect <fqdn>:443

И добавьте новый сертификат Let’s Encrypt R3 в fullchain.pem, *.jks или Intermediate Certification Authorities вместо старого на сервере.

Тут дело не столько в 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, а теперь является причиной головной/попной боли. Насколько я понял, цепочка доверия сертификатов, если сервер отдаёт её всю, в разных местах проверяется по-разному: где-то более «старший» сертификат сначала ищется в локальном хранилище, а потом в присланной цепочке, где-то наоборот, где-то — промежуточные сертификаты ищутся в присланной цепочке, а самый корневой — в хранилище. От этого возникают (отнюдь не облечающие понимание проблемы) ситуации, когда стоящие рядом устройства, даже с одинаковым содержимым локального хранилища доверенных сертификатов, по-разному реагируют на один и тот же сервер.

У Sectigo тоже две цепочки, но они хотя бы равноценные.

Ещё IIS сам выбирает какие промежуточные сертификаты отдавать клиентам на основе хранилища Intermediate Certification Authorities у аккаунта компьютера и пользователя SYSTEM (S-1-5-18). Возможно придётся чистить старые R3 в двух местах, чтобы ушла ошибка на клиентах.

У Sectigo что, тоже есть два разных сертификата с одинаковыми Subject и Subject Key Identifier?!

Сегодня всей командой боролись с проблемой этого сертификата. Использовали Node.js старой версии. Вопрос к сообществу, кто как предвосхищает данные проблемы, кроме как читает новостные IT ленты?

А можете уточнить, причем тут Node.js? у меня просто тоже нода не везде новая, но я что-то не вижу, где там могут всплыть проблемы.

в ноде встроенные сертификаты захардкоженные. И в 8й версии был данный сертификат - у нас все сервера начали валиться, где была 8я нода, 12ю не затронуло

Мониторинг. По поводу как проверять сроки действия сертификатов тем же заббиксом статей написано вагон и тележка.

Кого ещё задело: в Android, включая последний на данный момент Android 11, отвалился DNS-over-TLS (DoT).
Обсуждение в community.letsencrypt.org

У Домру(Эртелеком) при входе в чат поддержки сообщение


Сервисное сообщение:
СЕГОДНЯ РЕЗКО ПЕРЕСТАЛИ ОТКРЫВАТЬСЯ САЙТЫ? Дело в устаревшем сертификате безопасности на вашем устройстве. РЕШЕНИЕ ЗДЕСЬ! (в РЕШЕНИЕ ЗДЕСЬ! — ссылка на эту статью -:)).
Пока не посмотришь куда ссылка — первые ощущения что решили перенимать передовой зарубежный опыт (см https://habr.com/ru/news/t/531642/)

у меня видновс 7 с отключенными обновлениями

перестало открываться 50% сайтов. что делать ?)

не помогла та штука.. а если включить обновления на пиратской версии лицензия слетит?

Нет, активация не слетит.

Если включить автоматические обновления, то слетит из-за какого-нибудь kb971033. В такой ситуации лучше изучать обновления и ставить необходимые

(Откройте «Центр обновлений Windows» ;

  • В списке слева найдите и откройте пункт «Настройка параметров»;

  • Под графой «Важные обновления» в ниспадающем списке выберите пункт «Загружать, но решения об установке принимаются мной» либо «Решения об установке и загрузке принимаются мной»;

  • Нажмите «Ок».)

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

Решили вопрос?

Если нужно просто открывать сайты, то установить Firefox, внутри которого есть нужные сертификаты.

Joplin (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 должны обновится.

Сломалось :)

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_9

Помогает обновление системы (или пакета), там прилетел 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.

А что за "чистый docker"?

А что за "чистый docker"?

$ docker pull centos:7
$ docker run -it --rm centos:7

похоже, что разные репозитории для образов, так как у меня так и работает, но тут совсем нет что-то 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/

Обычный Centos (не контейнер) — та же версия openssl и сертификатов, проблем нет. Видимо, нужно что-то ещё из пакетов. Или перезапустить контейнер?

Я проверял с помощью простого 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
...
...

Да, из-за этого теперь сервер не может сам к себе обратиться по SSL выходит ошибка handshake. Решается проблема в добавление в исключение сертификата и обновлением правил. Спасибо за статью, очень помогло решить с некоторыми сайтами.

Обновить ОСь, добавить или удалить серты - это все ерунда и итак понятно. У меня это все поломало freeipa, где для вэбки и ldap сервера был настроен let's encrypt серт. Вот где приключения. Гениальные программисты решили, что это хорошая идея, обращаться к этому же серверу по http, чтобы установить в него серт. Естественно обратиться к нему невозможно из-за этого самого серта.

На старых ОС где нет возможности обновить OpenSSL, можно удалить сертификат `DST Root CA X3` чтобы он не мешал.

Для Debian/Ubuntu:

sudo rm /usr/share/ca-certificates/mozilla/DST_Root_CA_X3.crt
sudo update-ca-certificates
Этого не достаточно. См. мой камент выше. Нужно ещё убедиться, что имеющийся корневой сертификат «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» — неправильный, то нужно обновить и его (как уже описывали выше выше).

Большое спасибо за статью)

На моем стареньком debian 9 вчера отвалилась команда wget. Все запросы заканчивались ошибкой

ERROR: The certificate of ‘parserrf.ru’ is not trusted.
ERROR: The certificate of ‘parserrf.ru’ has expired.

помогло в файле /etc/ca-certificates.conf восклицательный знак !mozilla/DST_Root_CA_X3.crt и update-ca-certificates

Спасибо, добрый человек. Очень помогло

На Win 7 без обновлений проблема также возникает.

Подводя итоги для решения этой проблемы в 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

https://community.letsencrypt.org/t/rhel-centos-6-openssl-client-compatibility-after-dst-root-ca-x3-expiration/161032/73

Я собирал только первую часть, 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 enable

update-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.

На Win XP проявляется странным образом, установленный антиврус AVG Free блочит сайты ругаясь на сертификат, не давая возможности разрешить, прям вообще никак.

можно добавить домен в исключения.

так получилось обойти

только если домен не зоне рф - эти не вводятся

В статье Scott'а Helme предложен интересный метод обойти проблему для совсем старых версий OpenSSL (начиная с версии 0.9.8m). Метод основан на том, что OpenSSL не проверяет сигнатуру сертификатов, хранящихся в локальном защищенном хранилище. Таким образом, можно изменить время действия сертификата в защищенном хранилище, при этом модифицированный сертификат будет по-прежнему восприниматься OpenSSL как валидный, несмотря на то, что целостность сертификата нарушена. Добавил этот метод в статью.

На 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, скачав по ссылке из статьи, и сайт снова стал доступен.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории