Комментарии 245
Часть пользователей может столкнуться, либо часть пользователей столкнутся.
Этот DST Root CA X3 это какая-то катастрофа. Я так и не смог заставить .net core на ubuntu 21.04 доверять сертификатам let's encrypt после того как его из ca-certificates убрали. Орет что недоверяет одному из сертификатов в цепочке и все. Пришлось накатывать предыдущую версию ca-certificates пока DST Root CA X3 не истечет.
Спрашиваю как человек с предметными знаниями чуть выше абсолютного нуля: разве HTTPS не предполагает шифрование пакетов, и почему подмена в конечном счёте возможна и реализуема?
HTTP, как я понимаю, абсолютно беззащитен перед любым агентом, который может вклиниться между клиентом и сервером.
и почему подмена в конечном счёте возможна и реализуема?
Возможна, но только в некоторых, очень отдельных случаях.
Такая вот штука есть, например -- https://www.telerik.com/fiddler (но не только она, есть и аналогичные решения)
Это, среди прочего, дебаггер HTTPS-сессий в виде сквозного прокси. Он подставляет самоподписанные сертификаты на целевой домен. Конечно же, такой сертификат не имеет цепочки доверия до корневого и браузер сразу покажет, что там что-то не то. Но для отладки сгодится (если воткнуть в доверенное хранилище сертификат самого fiddler или отключить проверку).
Также это прокатывает, если влазят в трафик не браузера, а какой-нибудь игры или клиентского приложения, которое общается с сервером по HTTPS. Разработчикам обычно влом реализовывать как certificate pinning, так и жалобы на отсутствие цепочки доверия.
Разработчикам обычно влом реализовывать как certificate pinning, так и жалобы на отсутствие цепочки доверияБудет возможность перечислить несколько относительно популярных приложений или игр, которые пропускают MITM без уведомления или «падения»? Если о certificate pinning еще можно допустить, то о работе кода с отключенной проверкой цепочки доверия слова звучат не совсем убедительными.
Во времена бурной молодости.... Ну то есть, до середины 2016 года примерно, разрабатывал я эмулятор Ingress путём реверса его протокола. Почти ничего сложного не было, там внутри такой себе json-rpc на стероидах. Но приходилось очень плотно сидеть в дебаггере https, на что клиент игры и ухом не моргнул, не смотря на то, что я никаких посторонних сертификатов ему не пихал.
Вот вы спросили, и я уже засомневался :(
За давностью лет технических подробностей не помню, к сожалению. Может и добавлял. А может и нет, судя по тому, что я сейчас не знаю, как это делается.
Скорее всего там использовалась переменная окружения в windows SSLKEYLOGFILE которая сохраняет ключи во время рукопожатия, что позволяет дебагерам читать весь стрим. Это не MITM, так как дебагер на стороне, которой пакет и предназначался.
Про clientBlob я в курсе. Разломать его не удалось ни мне, ни минскому аэроклубу, евпочя. Это смогли только покемонщики.
Тем не менее, мой эмулятор более-менее успешно работал, подставляя рандомно один из ранее заснифаных клиент-блобов. Видимо, проверка валидности клиент-блоба была включена не на всех функциях, а только на самых критичных, типа чтения карты с произвольным cellID или транзакции с глифами. На остальных он до 2016 года не проверялся. А потом как начал :( И проект пришлось прикрыть.
Мобильный банкинг Белинвестбанка. Пример только один, но он непростителен для банковского приложения. Причем пароль передается в открытом виде, а не хотя бы хэш с солью.
Последний раз проверял году в 2019, тогда еще не было исправлено. Подозреваю и до сих пор не исправлено, но следует снова перепроверить.
Last Epoch из актуального. Умельцами под черным флагом альтернативная авторизация на серверах игры реализована как раз через Fiddler
То есть чтобы реализовать такую подмену нужно получить доступ к пользовательской системе и прописать сертификат фейкового центра сертификации в качестве корневого и доверенного. Встаёт вопрос, а почему бы тогда за одно ещё не поставить парукейлогеров и не настроить вебку вещать напрямую в оранжевый ютуб. Раз у нас уже есть доступ, то что мелочиться.
Я отвечал на вопрос, при каких условиях MITM с https может работать. То, что для этого требуется предварительный админский доступ к машине жертвы -- ну да, а вы чего ожидали? Готового эксплойта а-ля «Взломщик Интернета», что ли?
Нетхак он такой. На 99% состоит из эксплуатации человеческой тупости, и только на 1% -- из эксплуатации технических недостатков IT систем.
Или получить доступ к сертификату СА, который в доверенных по умолчанию. Менее реалистично, но возможно
Категорически странное заявление. В каком чипе? Почему они там зашиты? Почему именно 7 нм? Чипе расположенном где? Кто имеет доступ к этому чипу? Вы наверняка можете гарантировать в рамках всех компаний занимающихся выпуском сертификатов выполняться все заявленные вами требования и никто, и ни при каких обстоятельствах не сможет получить доступ к приватному ключу сертификата?
Для начала, есть правило запрещающее переходить дорогу на красный свет, и?
Ну держат CA свои приватные ключи отдельно от интернета в криптомодуле, дальше что? Механизм взаимодействия есть, просто потому что их используют для подписи других сертификатов. Ты можешь гарантировать что завтра в офис не придут люди с автоматами и не потребуют доступа к модулю? Или просто, сотрудник получавший соответствующий доступ не подпишет какой то левый сертификат с своими, сомнительными целями?
Как минимум такие случаи были и в наше время выявляются достаточно быстро через тот же Transparency Log. Собственно, кейс с сертом гугла фактически показал, как быстро теряется доверие к CA. В будущем действующая иерархическая модель PKI может вообще исчезнуть, уступив место тому же DANE (там тоже есть иерархия, но на уровне DNS).
Мне тоже эти https не очень. Да есть шифрование, но смысл от него, если провайдер захочет вставить прокси со своим сертификатом, то как я смогу отказаться от этого? Придется пользоваться и разрешать подмену.
В http сами авторы сайта делали шифрование своих данных, кто хотел. Я вот на своем простеньком сайте сделал логин и регистрацию через rsa и aes, кто-то сделает еще как-то, третий сделает своим способом. Чтобы сломать, нужно ломать каждого по отдельности, а https один раз сломать и всё открыто, авторы не заморачиваются с защитой и шифрованием, оно же есть
если провайдер захочет вставить прокси со своим сертификатом, то как я смогу отказаться от этого?
Перейти к другому провайдеру.
Перейти к другому провайдеру.
Иногда для этого надо менять район проживания.
Лучше сразу страну
Подскажете на какую, и желательно чтоб с гарантией что ее тоже вскоре не придется менять)
Простите, что я отвечаю, а не @farafonoff. Например, можно переехать в Исландию, Норвегию, Швецию, Швейцарию, Нидерланды, Польшу, Канаду, США и т.д.
Если провайдер (хотя скорее всего государство через провайдера) захочет вставить прокси со своим сертификатом, то это уже политическая проблема, а не техническая, решать которую надо тоже политическими методами, а не техническими.
Не браузером единым.
Facebook как приложение тоже поменяете? Или только через православный браузер смотреть всем придется?
И обратите внимание, сколько у вас именно приложений на смартфоне лезут к своим серверам. Подавляющему большинству пофиг на вручную добавленные сертификаты, они знают свой собственный, и по цепочкам доверия лазить им никакой нужды нет.
Условно говоря, на сайт банка вы через браузер худо-бедно сможете зайти. Но вот с мобильным приложением (клиент-банк) облом выйдет.
Это не так. Смотря что вы подразумеваете под один раз сломать.
Во первых есть наборы шифров которые не подвержены MITM атакам.
EDHE например.
Если вы раскроете приватный ключ как владелец сайта это уже другой вопрос.
Напомню что у провайдеров стоят железки из ФСБ которые анализируют весь трафик. в случае https они видят куда вы ходите не видя содержимого. В случае http они видят всё.
И я честный мне нечего скрывать тут не канает. У нас в стране за мемчики сажают, репосты, и смайлики
Я думал про чебуреки и государственный сертификат. А неугодных банить. Слышал что уже и закон хотят или хотели выпустить для бана програм, впн тоже хотят банить, сайты уже банят. Все идет к чебурнету, там и государственный сертификат могут придумать. Хотя при таком раскладе шифрование будет уже меньшим из зол и сайты будут сами выдавать все логи по первому запросу, иначе бан.
Я в этой теме не сильно хорош, может и чушь написал и такое невозможно сделать чисто технически
Китай справился с VPN. С огромным пингом и ограничением до 64кб/с даже ssh не сильно приятно использовать)
Не сможете вы разрешить подмену во многих случаях:
- кнопку "разрешить" потихоньку прячут.
- есть HSTS (и в том числе HSTS preload) — с ним кнопки просто не будет. вообще.
- разрешить методом установки указанного провайдером сертификата — а ничего что например на андроид начиная с 7 — куча ПО просто проигнорирует такую установку и будет вопить про неработу сети. Удачи провайдеру объяснять клиентам что это гугл виноват а не провайдер.
- если разработчики браузеров посчитают что в данном случае не провайдера идея а государственная и кто-то оборзел — в браузеры прилетит бан конкретного вот этого сертификата провайдера — см например https://www.opennet.ru/opennews/art.shtml?num=54284
в браузеры прилетит бан конкретного вот этого сертификата
И будет провайдер раздавать своим клиентам не Хром, а Яндекс или Спутник, как когда-то делал AOL
Изменённый. Как и Спутник/Амиго.
В нём Яндекс много своего добавил - от своих около-поисковых штучек и пользовательского интерфейса типа "Я Табло", до более низкоуровневых штучек типа выделения-копирования текста ссылок, Opera Turbo и шифрование ГОСТ в TLS.
Добавит он в свою ветку (git branch) ещё одно изменение - удаление из исходников конкретного "бана конкретного сертификата" - и всё, можно раздавать.
P.S. а AOL Browser тоже не в America onLine разрабатывался, а был перекрашенным MSIE, а потом перекрашенным NN, так что я его не просто так напомнил.
если провайдер захочет вставить прокси со своим сертификатом, то как я смогу отказаться от этого?
А вы только браузером пользуетесь? Никаких клиентов типа Яндекс.Диск, 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
"выглядит это как нарко кортель или крыша "
полностью согласен, и кроме того всё сделано так, что каждый раз при обновлении (платном) - то нет чтобы в два клика продлить срок действия, а выполняешь целую вереницу действий по новой установке сертификатов - причем в каждый сервис в каком либо особом формате. То каждый год на то, что должно быть в два клика (продолжить действие сертификата) тратишь кучу времени чтобы во всех подсистемах заново прописать.
Я скажу больше - конечный пользователь видит пресловутый значок замочка и думает, что его данные в безопасности. И он не понимает, что у него в системе может быть установлен корневой сертификат от товарища майора, или что сайт 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 (Имена компаний — НЕ глобально уникальны).
Показ «замочка» это наследие времён, когда большая часть соединений шла в незашифрованном виде, а безопасные соединения были чем-то таким, что выделялось на общем фоне.
Проблема решится сама собой, когда будет 100% хттпс, и замочек можно будет убрать
Не только от подмены. Ещё он удостоверяет сервер. Конечно, если пользователь не полный дурак и умеет читать хотя бы.
А ещё можете пояснить, как можно по сертификату убедиться, что зашел на официальный сайт госуслуг?
Немного пояснения. Если зайти на сайт того же Сбера и посмотреть сертификат, там ясно написано: Страна: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
на госуслугах сертификат выдан просто на домен, как у любого простого частного сайта...
Вот и я о том же...
на госуслугах сертификат выдан просто на домен, как у любого простого частного сайта
А так какая в итоге разница, если это для конечного пользователя оба сертификата выглядят абсолютно одинаково? Раньше была плашка об организации, да, но сейчас её уже убрали.
Если бы там стоял бесплатный сертификат от 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, а не от какого то другого.
del
Вот кстати, все ли браузеры покажут url как https://www.xn--gsuslugi-nbh.ru/ ? Или кто-то напишет "gоsuslugi.ru"?
Кириллическая строчная буква «и десятеричное»
А там не латинская i - Кириллическая строчная буква и десятеричное
Конечно, если пользователь не полный дурак
Мой опыт сисадмина-эникейщика в неайтишных предприятиях подсказывает, что ваши ожидания сильно завышены.
Подтверждаю. Большинство пользователей не просто не умеют читать, но даже не считают нужным это делать. Любое сообщение об ошибке вызывает два типа реакции: либо ступор, либо, в большинстве случаев, желание поскорее сообщение закрыть.
Айтишные после какого-то числа сотрудников ничем не отличаются от неайтишных и в них также нужно обучать основам ИБ.
Подмена пакетов провайдером - это далеко не иллюзорная опасность. В РФ очень многие провайдеры подменяют код HTTP-сайтов и вклинивают в них свою рекламу. В результате у владельца сайта во-первых сразу падает выручка от рекламы, потому что кликают не по его баннеру а по провайдерскому, во-вторых браузерное ПО Яндекса и гугла детектирует аггресивную рекламу на сайте, стучит об этом хозяину и сайт получает пессимизацию в поиске вплоть до бана.
РКН, перелогиньтесь
Безопасность это не хуй собачий. И нужно шифровать. А с ESNI и DoH пакеты провайдер не поменяет. А без сертификатов никуда, или надо будет изобретать блокчейн интернет
Алексей, вам ничего не кажется. Вы всё правильно понимаете, но посмотрите сколько недоразвитых вас минусует... Вот в этом вся проблема. Поэтому вечно будут что-то вводить или отменять и, разумеется, всё это будет для "нашей с вами безопасности" :))
Проблемы в основном у любителей халявы. Там где покупные сертификаты пока всё работает отлично.
Проблемы в основном у любителей халявы. Там где покупные сертификаты пока всё работает отлично.
ага, конечно - https://www.opennet.ru/opennews/art.shtml?num=31678
Epic fails того же Verisign загуглите сами
Этот зоопарк с кучей корневых сертификатов в текущем виде будет всегда проблемой.
Сейчас TLS есть даже в чайниках и лампочках, а кто будет обновлять в них список доверенных сертификатов? Производитель про них через пару лет забудет.
И хорошего выхода не видно... Есть DANE, но там те же проблемы почти - ключ корня DNS нужно тоже иногда обновлять, хоть это и попроще чем сотни корневых.
Замену DANE можно скриптом автоматизировать, если используете Cloudflare. Блин, Cloudflare хоть и гигантская монополистическая машина, но такая, зараза, удобная. А, к сожалению, DANE сам не живой :( Ну только если в почте живёт, но и даже там некоторые почтовые серверы его не проверяют.
Как производитель я бы "надеялся" на то, что срок службы таких чайников и лампочек окажется меньше срока действительности сертификата.
Сейчас TLS есть даже в чайниках и лампочках, а кто будет обновлять в них список доверенных сертификатов?
А вот это даже хорошо, ибо если лампочка не можем законектица на удалённый сервер, то она не является уязвимостью :)
faketime на MacOS доступна в пакете libfaketime
brew install libfaketime
Let's Encrypt является профанацией безопасности, когда любой желающий без всяких даже намёков на подтверждение получает сертификат подлинности, как у настоящих подлинных сайтов. Либо скоро брузеры начнут банить такие сайты, либо сервис круто поменяется и начнет закручивать гайки. Я думаю эта вакханалия возможна только из-за переходного периода и всеобщего желания отказаться от незашифрованного http
Но получить совершенно произвольный сертификат не получится, попробуйте, например, получить там сертификат для habr.com.
В плане информационной безопасности вы очень узко мыслите. Домены-близнецы регистрировать ничего не мешает.
Но получить совершенно произвольный сертификат не получится
Это у Васи Пупкина в интернете не получится. У товарища майора в чебурнете очень даже получится - с помощью НСДИ. Если авторитативный 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 позволяет посылать такие запросы только со стороны вебсервера и только по расписанию. Ответы (так называемые штампы, они подписаны центром сертификации), действительно передаются браузеру. Если браузер получает от сервера сертификат со штампом, то он просто проверяет дату/время штампа и никаких запросов в сертификационный центр не делает.
Какие подтверждения нужны для получения сертификата удостоверяющего исключительно домен, кроме как подтверждение владения доменом?
вот так любой ботнет этим и пользуется: зарегят свой левый домен, разошлют спам со ссылкой, юзер открывает, а брузер говорит ему что всё ок, сертификат годный. Это только спецы понимают что надо читать сертификат и смотреть на строку адреса, а типовой рядовой пользователь, коих 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.
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, всё работает, но ноутбук у меня старенький и после этого обновления он что-то тормозить начал. Хочу откатить всё назад. Было бы здорово, если можно было бы обновить только сам сертификат, а не всю систему. Благодарю!
Предположительно вот это обновление должно помочь: 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
У нас установлен 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 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)? не проще просто перейти на другой УЦ?
Утилита 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 при тех же условиях работает корректно.
На centos 6.10:
OpenSSL 1.0.1e-fips 11 Feb 2013
Значит ещё и openssl обновлять нужно.
Вам придется обновиться минимум до 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
Прошу прощения за, возможно, глупый вопрос, но есть ли возможность в старом рутованном 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
iOS похоже не умеет достаривать цепочку доверия и если сервер отдаст новый сертификат со старым R3, то клиенты увидят ошибку о недоверенном сертификате.
Если возникла такая ошибка, то проверьте какие сертификаты отдаёт серверopenssl s_client -showcerts -connect <fqdn>:443
И добавьте новый сертификат Let’s Encrypt R3 в fullchain.pem, *.jks или Intermediate Certification Authorities вместо старого на сервере.
У Sectigo тоже две цепочки, но они хотя бы равноценные.
Ещё IIS сам выбирает какие промежуточные сертификаты отдавать клиентам на основе хранилища Intermediate Certification Authorities у аккаунта компьютера и пользователя SYSTEM (S-1-5-18). Возможно придётся чистить старые R3 в двух местах, чтобы ушла ошибка на клиентах.
Разные, но похожие friendly names в системном хранилище сбивают с толку:
Правильный тут Sectigo (AAA).
Сегодня всей командой боролись с проблемой этого сертификата. Использовали Node.js старой версии. Вопрос к сообществу, кто как предвосхищает данные проблемы, кроме как читает новостные IT ленты?
Кого ещё задело: в Android, включая последний на данный момент Android 11, отвалился DNS-over-TLS (DoT).
Обсуждение в community.letsencrypt.org
У Домру(Эртелеком) при входе в чат поддержки сообщение
Сервисное сообщение:
СЕГОДНЯ РЕЗКО ПЕРЕСТАЛИ ОТКРЫВАТЬСЯ САЙТЫ? Дело в устаревшем сертификате безопасности на вашем устройстве. РЕШЕНИЕ ЗДЕСЬ! (в РЕШЕНИЕ ЗДЕСЬ! — ссылка на эту статью -:)).
Пока не посмотришь куда ссылка — первые ощущения что решили перенимать передовой зарубежный опыт (см https://habr.com/ru/news/t/531642/)
у меня видновс 7 с отключенными обновлениями
перестало открываться 50% сайтов. что делать ?)
Включить и установить обновления. Возможно, что хватит одного этого: https://www.microsoft.com/ru-RU/download/details.aspx?id=45633
не помогла та штука.. а если включить обновления на пиратской версии лицензия слетит?
Нет, активация не слетит.
Если включить автоматические обновления, то слетит из-за какого-нибудь 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 должны обновится.
https://certbot.eff.org/lets-encrypt/ubuntuxenial-nginx ставим последний certbot
certbot renew --preferred-chain "ISRG Root X1" --force-renewal
systemctl restart nginx
Сломалось :)
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-certificatesopenssl 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.
Спасибо, добрый человек. Очень помогло
На Центосях можно дернуть curl -k https://letsencrypt.org/certs/isrgrootx1.pem.txt, подкинув его в /etc/pki/ca-trust/source/anchors
После update-ca-trust extract и дальше радуемся жизни))
На 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
Я собирал только первую часть, 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.
В статье 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, скачав по ссылке из статьи, и сайт снова стал доступен.
Публикации
30 сентября: Let's Encrypt и конец срока действия IdenTrust DST Root CA X3