GlobalSign is the leading provider of trusted identity and security solutions enabling businesses, large enterprises, cloud service providers and IoT innovators around the world to secure online communications, manage millions of verified digital identities and automate authentication and encryption. Its high-scale Public Key Infrastructure (PKI) and identity solutions support the billions of services, devices, people and things comprising the Internet of Everything (IoE).
В начале октября авторитетный центр выдачи TLS-сертификатов (CA) GlobalSign занялся реструктуризацией своей инфраструктуры. В числе прочих мер, GlobalSign удалил ряд кросс-подписей своих корневых TLS-сертификатов.
К сожалению, в процессе браузеры Safari, Chrome и IE11 начали воспринимать сертификаты GlobalSign как отозванные по причинам безопасности. Инженеры GlobalSign оперативно устранили критическую ошибку, однако некорректный OCSP-ответ оказался закэширован на CDN и широко распространился по свету. В данный момент — и следующие четыре дня, до истечения срока действия записи в OCSP-кэше браузеров — сайты, защищённые сертификатом от GlobalSign, могут быть недоступны для значительной части пользователей.
Среди затронутых сайтов такие компании, как Wikipedia, Dropbox, Financial Times и другие.
Overview
Intermediate Certificates help complete a «Chain of Trust» from your SSL or Client Certificate to GlobalSign’s Root Certificate.
As an OrganizationSSL customer you must install your end entity SSL Certificate (received via e-mail) along with an OrganizationSSL Intermediate Certificate listed below.
Instructions for installing SSL Certificates on various platforms can be found here:
SSL Installation
Note: In some cases, the web server may need to be configured with the GlobalSign R3-R5 Cross Certificate or possibly with Root R3 or Root R5 as part of the standard configuration process.
Быстрый и надежный SSL
GlobalSign предоставляет наивысший уровень защиты, используя криптографический алгоритм SHA-256 и RSA-ключи размером минимум 2048 бит, дополнительно мы предлагаем ECC.
Универсальная совместимость и поддержка устройств
Сертификаты GlobalSign совместимым со всеми браузерами, операционными системами, приложениями и устройствами. Это значит, что все посетители, вне зависимости от используемого браузера и устройства, автоматически примут ваш SSL-сертификат.
Бесплатные SSL-инструменты
Бесплатные инструменты для установки SSL (SSL Server Test) и управления SSL (платформа MPKI и Certificate Inventory Tool).
Более 20 лет в качестве аккредитованного удостоверяющего центра
Начиная с 1996 года GlobalSign выдал более, чем 2,5 млн. доверенных SSL-сертификатов по всему миру. В 2001 году удостоверяющий центр получил аккредитацию WebTrust.
Один из лидеров индустрии по качеству международной поддержки
Наши офисы находятся по всему миру, а поддержка осуществляется на разных языках — мы по праву гордимся своей великолепной репутацией как фирмы с наилучшей международной поддержкой.
Экономия и удобство
Столкнулся с небольшой проблемой в процессе рядовой и будничной процедуры регистрации на одной из торговых площадок госсзакупок. Все обычно проходит без проблем, все привыкли к ключам, регистрациям и чаще всего пользователи сами способны по инструкции сделать все необходимое. Но тут возник затык и меня попросили помочь разобраться.
Речь пойдет конкретно про сайт zakupki.mos.ru, но ключ используют не только на этом сайте. Он универсальный и подходит для очень многих торговых площадок. А ошибка вообще не имеет прямого отношения к сайту, а относится к вопросу использования электронных цифровых подписей.
Использован не доверенный сертификат. Не удалось подписать: Не удается построить цепочку сертификатов для доверенного корневого центра. (0x800B010A)
Ошибка по большому счету понятная, но не ясно, как ее исправить, с учетом того, что все необходимые сертификаты, в том числе и корневого центра сертификации, были установлены. Идем их проверять. Для этого открываем оснастку CryptoPro:
Идем в раздел: Сертификаты — текущий пользователь — Личное — Реестр — Сертификаты. Открываем наш сертификат и смотрим его свойства. Конкретно нас интересует раздел Путь сертификации. К сожалению, у меня не осталось скриншотов до решения проблемы, поэтому придется описывать словами, в чем там дело. Потом покажу, как должно все выглядеть, чтобы нормально работало.
Цепочка сертификатов выглядела следующим образом: УЦ 1 ИС ГУЦ — АО «ЕЭТП» — Сертификат пользователя. При этом в корневом сертификате УЦ 1 ИС ГУЦ была ошибка в виде сообщения:
Невозможно обнаружить поставщика этого сертификата
А в его свойствах еще одна ошибка:
Недостаточно информации для проверки этого сертификата
При этом сертификат УЦ 1 ИС ГУЦ был на компьютере в списке доверенных корневых центров сертификации. Проверить это можно через ту же оснастку CryptoPro в соседней ветке: Доверенные корневые центры сертификации — Реестр — Сертификаты. Я был уверен, что УЦ 1 ИС ГУЦ это корневой центр сертификации самого первого уровня и не мог понять, кто еще должен подтверждать его доверие. При этом в прошлом сертификате корневым стоял вообще АО «ЕЭТП», и больше никого. И все нормально работало.
И вот так выглядеть полный путь сертификации для пользовательского сертификата.
У меня изначально самого первого Головной удостоверяющий центр не было, и я не знал, что он должен быть. Когда его установил, все стало нормально. Возможно люди что-то с установочного диска не так установили, или по ходу дела напортачили. Я разбирался удаленно и не видел, какой софт шел в комплекте с ключом. По факту проблема популярная, в интернете много отзывов и советов. Надеюсь, кому-то эта информация поможет сэкономить время.
Чтобы браузер мог аутентифицировать веб-сайт, тот представляет себя действительной цепочкой сертификатов. Типичная цепочка показана сверху, в ней может быть больше одного промежуточного сертификата. Минимальное количество сертификатов в действительной цепочке равно трём.
Корневой сертификат — сердце центра сертификации. Он буквально встроен в вашу ОС или браузер, он физически присутствует на вашем устройстве. Его не поменяешь со стороны сервера. Нужно принудительное обновление ОС или встроенного ПО на устройстве.
Специалист по безопасности Скотт Хельме (Scott Helme) пишет, что основные проблемы возникнут у центра сертификации Let’s Encrypt, потому что сегодня это самый популярный ЦС в интернете, а его корневой сертификат скоро «протухнет». Смена корня Let’s Encrypt назначена на 8 июля 2020 года.
Конечные и промежуточные сертификаты удостоверяющего центра (CA) доставляются клиенту с сервера, а корневой сертификат у клиента уже есть, поэтому с помощью этой коллекции сертификатов можно построить цепочку и аутентифицировать веб-сайт.
Проблема заключается в том, что у каждого сертификата есть срок действия, после чего он нуждается в замене. Например, с 1 сентября 2020 года в браузере Safari планируют ввести ограничение на срок действия серверных TLS-сертификатов максимум 398 дней.
Это значит, что всем нам придётся заменять серверные сертификаты по крайней мере каждые 12 месяцев. Это ограничение распространяется только на сертификаты сервера, оно не распространяется на корневые сертификаты CA.
Сертификаты CA регулируются другим набором правил, поэтому имеют разные ограничения на срок действия. Очень часто встречаются промежуточные сертификаты со сроком действия 5 лет и корневые сертификаты со сроком службы даже 25 лет!
С промежуточными сертификатами обычно нет проблем, потому что они поставляются клиенту сервером, который сам гораздо чаще меняет свой собственный сертификат, так что просто в ходе этой процедуры заменяет и промежуточный. Его довольно легко заменить вместе с сертификатом сервера, в отличие от корневого сертификата CA.
Как мы уже говорили, корневой CA встроен непосредственно в само клиентское устройство, в ОС, в браузер или другое программное обеспечение. Изменение корневого CA веб-сайт не может контролировать. Здесь требуется обновление на клиенте, будь то обновление ОС или софта.
Некоторые корневые CA существуют уже очень давно, речь о 20-25 годах. Скоро некоторые из самых старых корневых CA приблизятся к концу своей естественной жизни, их время почти истекло. Для большинства из нас это вообще не будет проблемой, потому что CA создали новые корневые сертификаты, и они уже много лет распространяются по всему миру в обновлениях ОС и браузеров. Но если кто-то очень давно не обновлял ОС или браузер, это своего рода проблема.
Такая ситуация возникла 30 мая 2020 года в 10:48:38 GMT. Это точное время, когда протух корневой сертификат AddTrust от центра сертификации Comodo (Sectigo).
К сожалению, проблемы возникли не только в устаревших браузерах, но и в небраузерных клиентах на базе OpenSSL 1.0.x, LibreSSL и GnuTLS. Например, в телевизионных приставках Roku, сервисе Heroku, в приложениях Fortinet, Chargify, на платформе .NET Core 2.0 под Linux и многих других.
Ежегодно форум CA/Browser обновляет базовые требования к серверным SSL/TLS-сертификатам (Baseline Requirements или BR).
Одно из таких требований указано в пункте 4.9.9 с пометкой MUST:
Ответы по OCSP (протокол статуса онлайн-сертификатов) ДОЛЖНЫ соответствовать RFC 6960 и/или RFC 5019. OCSP ответы ДОЛЖНЫ либо:
- Иметь подпись УЦ, выдавшим сертификаты, чей статус отзыва проверяется, или
- Иметь подпись OCSP Responder, сертификат которого подписан УЦ, выдавшим сертификаты, чей статус отзыва проверяется
Именно это правило нарушают практически все удостоверяющие центры (УЦ), что имеет некоторые последствия.
Вот скриншот из Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates (последняя версия 1.7.0, 4 мая 2020 года, pdf):
Стандарт RFC6960 в разделе 4.2.2.2 даёт определение «OCSP Delegated Responder» по наличию id-kp-OCSPSigning.
Изучив данные crt.sh, Райан Сливи обнаружил 293 промежуточных сертификата без расширения pkix-nocheck, из них на данный момент 180 валидных и 113 отозванных.
Фильтрация на Census.io выдаёт 276 сертификатов, соответствующих этим условиям.
Таким образом, эти сертификаты нарушают базовые требования CA/Browser, причём обязательные к выполнению требования.
Отсутствие соответствующего расширения — не просто формальность. Здесь нет проблемы в том смысле, что промежуточный УЦ не может отозвать сертификат другого промежуточного УЦ от того же корневого удостоверяющего центра.
Реальная проблема в том, что в отсутствие расширения промежуточный УЦ теоретически может отменить отзыв сертификата другого промежуточного УЦ или самого корневого УЦ. Это действительно проблема. Фактически, у удостоверяющего центра в такой ситуации нет надёжного варианта для полного и необратимого отзыва сертификатов. Процедура отзыва не работает как положено, что открывает двери для злоумышленников, которые потенциально могут провести атаку с восстановлением отозванного сертификата.
Чтобы исправить эту проблему, предлагается при отзыве сертификата необратимо удалять все копии ключей, чтобы отзыв тоже стал необратимым.
В оправдание УЦ можно сказать, что и без этого недостатка процедура отзыва сертификатов сейчас не работает как положено. Так, основные браузеры поддерживают собственные копии списков отозванных сертификатов CRL — и не всегда проверяют их актуальность. Эти CRL содержат только базовую, самую важную информацию, но они далеко не полные. Например, Chrome вовсе не трудится проверять, не отозван ли каждый конкретный TLS-сертификат, тогда как Firefox это делает. То есть иногда с Chrome вы можете спокойно зайти на сайт с истёкшим сертификатом, а Firefox выдаст предупреждение и не пустит вас туда.
Интересно, что по правилам неправильные сертификаты должны быть аннулированы в браузерах в течение 7 дней, но для данной ситуации сделали исключение. Бен Уилсон (Ben Wilson) из Mozilla сказал, что они не будут аннулировать сертификаты с отсутствующим расширением id-pkix-ocsp-nocheck. Хотя такие сертификаты не соответствуют правилам, но браузер Firefox не подвержен этой конкретной уязвимости в безопасности, потому что OCSP-ответы за подписью промежуточных УЦ в нём не принимаются.
УЦ должны как-нибудь заменить некорректные сертификаты, но финального срока для них не установлено.
SSL RSA Certificates (Before May 27, 2019)
If you want browsers to chain up to Root R3, a SHA-256 Root, instead of Root R1, a SHA-1 Root, then you must install this Intermediate Certificate on your web server instead of the one provided with the Certificate. Note: This Intermediate Certificate has the same keys and same Certificate SubjectDN and will use this when provided in the TLS session so that their connections chain up to Root R3.
Следующий — Let’s Encrypt
Ещё один хороший пример предстоящей смены корневого CA — центр сертификации Let’s Encrypt. Ещё в апреле 2019 года они планировали перейти с цепочки Identrust на собственную цепочку ISRG Root, но этого не произошло.
«Из-за опасений по поводу недостаточного распространения корня ISRG на устройствах Android мы решили перенести дату перехода к собственному корню с 8 июля 2019 года на 8 июля 2020 года», — сказано в официальном сообщении Let’s Encrypt.
Дату пришлось перенести из-за проблемы, которую называют «распространением корня» (root propagation), а точнее, отсутствием распространения корня, когда корневой CA не слишком широко распространён на всех клиентах.
Сейчас Let’s Encrypt использует перекрёстно подписанный промежуточный сертификат с цепочкой до корня IdenTrust DST Root CA X3. Этот корневой сертификат был выдан ещё в сентябре 2000 года и истекает 30 сентября 2021 года. До этого времени Let’s Encrypt планирует перейти на собственный самоподписанный корень ISRG Root X1.
Корень ISRG выпущен 4 июня 2015 года. После этого начался процесс его утверждения в качестве центра сертификации, который завершился 6 августа 2018 года. С этого момента корневой CA был доступен всем клиентам через обновление операционной системы или программного обеспечения. Всё, что нужно было сделать, — это установить обновление.
Но в этом и проблема.
Если ваш мобильный телефон, телевизор или другое устройство не обновлялось два года — как оно узнает о новом корневом сертификате ISRG Root X1? А если его не установить в системе, то все серверные сертификаты Let’s Encrypt ваше устройство признает недействительными, как только Let’s Encrypt перейдёт на новый корень. А в экосистеме Android много устаревших устройств, которые давно не обновлялись.
Вот почему Let’s Encrypt отложил переход к собственному корню ISRG и всё ещё использует промежуточное звено, которое спускается к корню IdenTrust. Но переход в любом случае придётся сделать. И датой смены корня назначено 8 июля 2020 года.
Let’s Encrypt не единственный, кому предстоит решить проблему с переходом на новый корень. Криптографию в интернете начали использовать чуть более 20 лет назад, так что как раз сейчас наступает момент окончания действия многих корневых сертификатов.
С такой проблемой могут столкнуться владельцы умных телевизоров, которые много лет не обновляли программное обеспечение Smart TV. Например, новый корень GlobalSign R5 Root выпущен в 2012 году, и после некоторые старые Smart TV не могут построить цепочку к нему, потому что этот корневой CA у них просто отсутствует. В частности, эти клиенты не могли установить защищённое соединение с сайтом bbc.co.uk. Чтобы решить проблему, админам BBC пришлось пойти на хитрость: они построили для этих клиентов альтернативную цепочку через дополнительные промежуточные сертификаты, задействуя старые корни R3 Root и R1 Root, которые ещё не протухли.
www.bbc.co.uk (Leaf)
GlobalSign ECC OV SSL CA 2018 (Intermediate)
GlobalSign Root CA — R5 (Intermediate)
GlobalSign Root CA — R3 (Intermediate)
Это временное решение. Проблема никуда не уйдёт, если не обновить клиентское ПО. Умный телевизор — это по сути ограниченный в функциональности компьютер под Linux. И без обновлений его корневые сертификаты неизбежно протухнут.
Это касается всех устройств, не только телевизоров. Если у вас любое устройство, которое подключено к интернету и которое рекламировали как «умный» девайс, то проблема с протухшими сертификатами почти наверняка касается его. Если устройство не обновляется, то корневое хранилище CA со временем устареет, и в конечном итоге проблема всплывёт на поверхность. Как скоро возникнет проблема, зависит от времени последнего обновления корневого хранилища. Это может быть за несколько лет до даты реального выпуска устройства.
Кстати, в этом проблема, почему некоторые крупные медиаплатформы не могут использовать современные автоматизированные центры сертификации типа Let’s Encrypt, пишет Скотт Хельме. Для умных ТВ они не подходят, и количество корней слишком мало, чтобы гарантировать поддержку сертификата на устаревших устройствах. В противном случае ТВ просто не сможет запустить современные стриминговые сервисы.
Последний инцидент с AddTrust показал, что даже крупные IT-компании бывают не готовы к тому, что у корневого сертификата заканчивается срок действия.
Решение проблемы только одно — обновление. Разработчики умных устройств должны заранее обеспечить механизм обновления программного обеспечения и корневых сертификатов. С другой стороны, производителям невыгодно обеспечивать работу своих устройств по окончании срока гарантии.
Самое главное
Этот инцидент — первый в своём роде. Впервые в истории Интернета случилась проблема такого уровня, и нет сомнения, что все игроки индустрии CA сделают всё возможное, чтобы подобное не повторилось.
GlobalSign сильно провинился перед своими клиентами, но эта компания известна тем, что умеет признавать свои ошибки и делать из них выводы. В ближайшее время мы ожидаем от компании подробный анализ всех обстоятельств и открытую работу над ошибками и будем держать вас в курсе.
Кровавые технические подробности
В этой концепции есть один скользкий момент. Дело в том, что в случае обнаружения, например, уязвимости на сервере злоумышленник может получить доступ к существующему сертификату и закрытому ключу шифрования. Украв ключ, злоумышленник сможет использовать его для имитации оригинального сайта и организовать на этот сайт атаку типа Man-in-the-Middle. В результате вор потенциально может получить доступ к паролям, данным пластиковых карт и иной конфиденциальной информации посетителей сайта.
Проблема усугубляется тем, что TLS-сертификаты выдаются хоть и не навсегда, но на достаточно длительный промежуток времени (обычно — от года и более), причём многие центры сертификации (включая, кстати, GlobalSign) дают скидку тем, кто покупает у них сертификат с длительным сроком действия. Это одна из тех проблем, решить которые стремится бесплатный центр сертификации Let’s Encrypt. Сертификаты, выданные Let’s Encrypt, действительны не более 3 месяцев, и центр сертификации планирует сократить этот период до 30 дней.
Исправить существующее положение дел призваны механизмы под названием CRL и OCSP. Они позволяют браузеру проверить, действителен ли тот TLS-сертификат, который предъявляется сайтом. Если в какой-то момент обладатель сертификата заподозрит, что закрытый ключ от сертификата попал не в те руки, он может связаться с центром, выдавшим сертификат, и отозвать его. Отозванный сертификат не будет приниматься большинством современных браузеров, в частности, Safari и Chrome, а в перспективе — всеми браузерами вообще. Таким образом, закрытая информация не попадёт не в те руки.
Что произошло в начале октября
Компания GlobalSign управляет множеством корневых доверенных сертификатов. Ряд этих сертификатов кросс-подписывает друг друга, аналогично тому, как это делает Let’s Encrypt:
Кросс-подпись нужна, например, при выпуске нового корневого сертификата. Так как многие люди редко обновляют свои операционные системы, вновь созданный сертификат может не сразу оказаться в кэше старых браузеров. Чтобы корневой сертификат можно было использовать по назначению, его подписывают одним из старых корневых сертификатов.
Само собой, кросс-подписывание усложняет обслуживание корневых сертификатов. Кроме того, со времени выпуска некоторых из сертификатов GlobalSign прошло уже достаточно времени, чтобы оставшимися необновлёнными системами можно было пренебречь. В конце концов, эти системы всё равно обречены — например, печально известный Internet Explorer 6 «из коробки» поддерживает криптографические протоколы версии не выше уязвимого SSL 3.0.
Ввиду этого в октябре 2016 года GlobalSign решил удалить часть кросс-подписей между своими сертификатами и управлять ими далее раздельно и независимо.
Что пошло не так
Утром 14 октября в процесс отзыва кросс-подписей вкралась ошибка. В результате ряд промежуточных сертификатов GlobalSign (в частности, недорогой и распространённый AlphaSSL) стал восприниматься браузерами Safari и Chrome как отозванный, а все сайты, купившие сертификат у AlphaSSL и других, перестали открываться.
В данный момент проблема с кэшом CDN также решена, однако у множества пользователей неверный OCSP-статус закэширован теперь уже в браузере. Запись в OCSP-кэше браузеров и операционных систем будет действительна в течение следующих 4 дней, потом ситуация исправится.
Есть также косвенные основания полагать, что проблема была вызвана багом в обработке OCSP-записей в браузерах Safari и Chrome. Однако фактических подтверждений этому пока нет
. Обновление: The Register в Твиттере сообщает: сотрудники GlobalSign подтвердили в интервью радио BBC, что проблема была целиком на их стороне.
Спустя 11 часов после начала инцидента GlobalSign выпустил рекомендацию по исправлению возникших проблем, однако ряд клиентов за это время уже мигрировали к другим CA:
Онлайн курcы по Mikrotik
Если у вас есть желание научиться работать с роутерами микротик и стать специалистом в этой области, рекомендую пройти курcы по программе, основанной на информации из официального курcа MikroTik Certified Network Associate. Помимо официальной программы, в курcах будут лабораторные работы, в которых вы на практике сможете проверить и закрепить полученные знания. Все подробности на сайте Курcы по ИТ.
Стоимость обучения весьма демократична, хорошая возможность получить новые знания в актуальной на сегодняшний день предметной области. Особенности курcов:
- Знания, ориентированные на практику;
- Реальные ситуации и задачи;
- Лучшее из международных программ.
Помогла статья? Подписывайся на telegram канал автора
Анонсы всех статей, плюс много другой полезной и интересной информации, которая не попадает на сайт.