Ошибка в TheBat при соединении с почтой, созданной ISP manager? — Хабр Q&A

Ошибка в thebat при соединении с почтой, созданной isp manager?

Что в tls 1.3?

Все упомянутые трудности решаются использованием TLS 1.3. Половины проблем вообще нет, всё проще, красивее, всё прям отличненько. Но TLS 1.3 еще распространен маловато. Самые важные отличия TLS 1.3 (их очень много, они везде, поэтому только самые важные):

• Плохие шифры удалены, остались только хорошие. Инициализировать сессию TLS 1.3 на плохих шифрах не получится. Всё дело в новых cipher suites: тут и другие алгоритмы обмена сеансовых ключей, и так называемый HMAC – не будем углубляться в подробности, потому что Патрик устал. Вкратце: раньше подпись каждого TLS-пакета шла отдельно. На это были атаки, потому что было известно, какой там контент находится. Сейчас ее запихали вовнутрь (режим AEAD), и в TLS 1.3 по-другому быть не может, соответственно, мы избавились от таких атак.
• Handshake стал короче – нет старых сообщений, нет старых расширений, нет возможности по каким-то странным штукам обменяться ключиками. То есть, он тупо короче количественно – даже самый полный TLS 1.3 handshake короче, чем в TLS 1.2.
• Переход на шифрованный канал происходит почти что сразу. Для этого используются разные ключики: да, пока не договорились о хороших ключиках, оптимальных, мы используем какие попало, но канал уже шифрованный. То есть hello – hello и пошло всё зашифрованное. Из-за этого сложнее всё это ломать.
• Всё регламентировано, больше не надо пытаться менять размеры пакетов, забивая их ноликами, чтобы сложнее было расшифровывать.
• Своя пара ключей на каждую сеансовую фазу. Сеансовые ключи меняются: пока мы ни о чем не договорились – они такие, договорились о более крутых – они более крутые, сертификаты проверили и всё хорошо – еще другие ключи. В итоге их много, они усложняются и очень трудно это всё поломать. Еще одна важная вещь, почему это быстрее: Early Data (она же 0-RTT, Zero Round Trip Time) – это когда у тебя в TLS-handshake посылается полезная инфа – ну например GET-запрос. То есть нет такого, что поговорили-поговорили и только потом посылаем что-то отдельным потоком. Сразу же в handshake идет запрос. Как только сервер его получил, он начинает его обрабатывать, отдает клиенту свои данные, сертификат и пока клиент проверяет, сервер уже готов отдать. И может даже в TLS-handshake и отдать иногда.
• Есть pre-shared key, то есть клиент с сервером могут договориться и сохранить сеансовые ключи для последующих соединений. И, соответственно, когда происходит handshake таких вот договорившихся клиентов, на этап выбора ключей время не тратится. Долго объяснять, как это сделано криптографически, но тех атак, которые были на Session ID, вот в этом месте сейчас нет (что хорошо). Всё стало безопаснее и быстрее.

Основная проблема, что поддержка TLS 1.3 – она во всех браузерах, которые актуальны, есть, но не во всех по дефолту включена. Например, в Safari нет (но там очень легко включить), Google Chrome и Mozilla Firefox уже по дефолту поддерживают TLS 1.3. Ngnix с TLS 1.3 – без проблем, в Apache есть нюансы, а вот с почтовыми клиентами хуже — там только Exim молодец, а остальные не очень.

В общем, это наше будущее, там всё получше и попроще, самое главное. Но пока оно еще не везде наступило.

Basic constraints

Еще одна штука, которая улучшает секьюрити (и с этим были серьезные баги до 2003 года в Internet Explorer): в промежуточных сертификатах в поле Basic Constraints должно быть написано

CA: true

, что означает, что этим сертификатам разрешено подписывать конечные сертификаты. Если этой штуки нет, то клиент при проверке цепочки должен сказать: «я не могу принять этот промежуточный сертификат» – несмотря на то, что все подписи совпадают, в субъекте всё совпадает и т.д.

Еще раз, если кто не понял: если эту штуку не проверять, я могу получить сертификат от Let’s Encrypt и потом этим сертификатом подписывать что угодно. И цепочка будет валидная.

Capi и scvp

Еще про верификацию и про цепочку. Есть маленькая особенность – похвалим здесь Windows. Если сервер не отдал сертификат, в обычном (традиционном) подходе сертификат нам взять неоткуда, цепочки нет, всё сломалось. Так вот, в Windows есть такая штука как Certificate API, и она может достроить цепочку, взяв промежуточные сертификаты из своего хранилища.

Как эти сертификаты туда попадают? Либо залиты в хранилище, либо из сертификата, установленного на сервере. Например, в Plesk, если получить сертификат от Comodo и поставить его на домен – в хранилище попадет промежуточный сертификат от Comodo.

Ну и еще люди, которым Windows нравится, придумали SCVP (Server-based Certificate Validation Protocol). В действительности не работает почти ни у кого и нигде – в смысле глобально и массово, — но как концепция есть. Более того, есть продукты, которые это делают, и даже в каких-то сетях это может быть настроено.

Это сервис, который за тебя эту цепочку строит и частично даже проверяет, что удобно. Если там заявлена поддержка DPV (Delegated Path Validation), то он цепочку еще и провалидирует. То есть, клиенту надо этому сервису отправить сертификат и получить ответ – продолжать сессию или рвать.

Предположительно это могло бы всё ускорить, но из-за того, что сервису тоже надо как-то доверять, идея глохнет. И всё-таки она была.

Итак, вот у нас получается такая вот цепочка.

Прежде всего мы проверяем, что с подписями у нас всё нормально: выстраиваем цепочку, проверяем подписи – и считаем, что содержимое сертификатов верно. Дальше нам надо проверить конечный сертификат. Промежуточный нам проверять не надо, потому что мы идем к Патрику и проверить нам надо только самый последний сертификат.

Давайте проверять.

Root certificate

В принципе, это даже не обязательно должен был быть сертификат – вполне хватило бы просто пары ключей. Потому что единственное, что нам от него надо – это знать, что такому-то центру сертификации (Certificate Authority, CA) соответствует такой-то публичный ключ.

Откуда появляется вера в центры сертификации как в «хороших парней»? Все просто договорились, что вот таким-то организациям можно доверять. У каждого клиента есть список соответствия CA и публичного ключа. Таким образом, каждый клиент знает, что есть вот такой чувак и ключ для него такой. И так это всё и проверяется. То есть – просто записано, просто договорились, что верим.

Session id

До TLS 1.3 для решения этой проблемы использовались укороченные сессии. Когда сервер отвечает клиенту, он отдает ему Session ID. Если у клиента этот Session ID тоже есть, он отсылает его серверу и вот эта часть, которая в рамочке, пропускается. Потому что сервер запоминает контекст всей этой штуки и продолжает так, как будто это уже произошло.

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

Так это всё работает. Это побыстрее, но тоже есть проблемы, — возрастает нагрузка на сервер, ну и есть атаки с перехватом Session ID. Потому что этот Session ID идет по открытому каналу.

Блокировка доверия для сертификата wosign ca free ssl certificate g2

Центр сертификации (ЦС) WoSign несколько раз допускал ошибки, связанные с управлением, при выдаче сертификатов через промежуточный ЦС WoSign CA Free SSL Certificate G2. Хотя корневой сертификат WoSign находится в списке доверенных сертификатов Apple, этот промежуточный центр сертификации использовался для связей сертификатов с перекрестной подписью с StartCom и Comodo, чтобы установить отношение доверия с продуктами Apple.

В свете этих обстоятельств мы принимаем меры по защите пользователей в рамках обновления безопасности. Продукты Apple больше не доверяют промежуточному центру сертификации WoSign CA Free SSL Certificate G2.

Чтобы предотвратить прекращение обслуживания держателей сертификатов WoSign и обеспечить для них переход на доверенные корневые сертификаты, продукты Apple доверяют индивидуальным существующим сертификатам, выданным этим промежуточным центром сертификации и опубликованным на общедоступных серверах журналов Certificate Transparency до 19 сентября 2021 года.

По мере изучения проблемы и обнаружении дополнительных уязвимостей, появляющихся из-за использования точек доверия WoSign/StartCom в продуктах Apple, мы будем принимать необходимые меры для защиты пользователей.

Дальнейшие действия для WoSign

В ходе дальнейшего исследования мы пришли к выводу, что помимо многочисленных ошибок управления в работе центра сертификации WoSign (CA), организация WoSign не сообщила о приобретении StartCom.

Мы продолжаем принимать меры для защиты пользователей в предстоящем обновлении безопасности. Продукты Apple будут блокировать сертификаты, выданные корневыми центрами сертификации WoSign и StartCom, если их дата Not Before (Не раньше) выпадает на 1 декабря 2021 г. 00:00:00 GMT/UTC или позже.

Дополнительная информация

Профиль, использовавшийся для создания сертификата из протокола ADCert или SCEP, можно удалить. Если используется Mavericks или более поздняя версия macOS, наиболее недавний сертификат и закрытый ключ удаляются из связки ключей, а исходный сертификат необходимо удалять вручную.

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

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

Информация о продуктах, произведенных не компанией Apple, или о независимых веб-сайтах, неподконтрольных и не тестируемых компанией Apple, не носит рекомендательного или одобрительного характера. Компания Apple не несет никакой ответственности за выбор, функциональность и использование веб-сайтов или продукции сторонних производителей.

источник

Импорт сертификата в macos x

Для того чтобы записать персональный сертификат WM Keeper WebPro (Light) с закрытым ключом на MacOS X необходимо выполнить следующие действия:

1. Запустите приложение «Связка ключей». Перетащите файл сертификата со съемного носителя информации в приложение «Связка ключей».

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

2. Введите пароль для персонального сертификата (тот, который вы задали при экспорте сертификата)

3. При успешном выполнении импорта персонального сертификата, он отобразится у Вас в «Связке ключей»

источник

Исправление ошибки

Как писалось выше, вся проблема в отсутствующих корневых сертификатах. Для того, чтобы данная ошибка ушла, нужно поставить эти самые корневые сертификаты – взять их можно у издателя сертификата (почти наверняка, они должны быть на их сайте). Издателя сертификата можно увидеть в поле “Кем выдан” свойств сертификата (выделено оранжевым на картинке ниже).

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

Переходим на сайт федерального казначейства, в раздел “Корневые сертификаты”. Скачиваем “Сертификат Минкомсвязи России (Головного удостоверяющего центра) ГОСТ Р 34.10-2021” и “Сертификат Удостоверяющего центра Федерального казначейства ГОСТ Р 34.10-2021 CER”. Открываем оба скачанных файла и устанавливаем оба сертификата.

Установка сертификата состоит из следующих действий:

1. Открываем сертификат. В левом нижнем углу нажимаем на кнопку “Установить сертификат“.
   
2. Откроется “Мастер импорта сертификатов“. Нажимаем “Далее“. В следующем окошке выбираем пункт “Поместить все сертификаты в следующее хранилище”, и нажимаем кнопку “Обзор”.
   
3. В списке выбора хранилища сертификатов выбираем “Доверенные корневые центры сертификации“. Нажимаем кнопку “ОК“, затем кнопку “Далее“.
   
4. В следующем окошке нажимаем на кнопку “Готово“. Затем, в окне предупреждения системы безопасности, на вопрос о том, что вы действительно хотите установить этот сертификат, нажимаем “Да”. После этого последует подтверждение установки сертификатов.
   

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

Как установить отозванные

В отдельных случаях понадобится установка списка отозванных сертификатов (СОС) в дополнительном порядке. Для этого выполните следующие действия:

1. откройте Internet Explorer;
2. перейдите в разделе «Сервис» по пути «Свойства» — «Содержание» — «Сертификаты»;
3. в подразделе «Имя точки» скопируйте в файл имеющуюся ссылку на список;
4. сохраните файл на жестком диске компьютера;
5. кликните по этому файлу правой кнопкой мыши для вызова контекстного меню;
6. следуйте инструкциям «мастера».

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

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

Если вам понадобилась дополнительная техническая консультация или появилась необходимость оформить ЭЦП любого типа, сделать это можно в УЦ «Астрал-М». Компания имеет аккредитацию Минкомсвязи и предлагает клиентам возможность открытия цифровых подписей любого типа. Обращаясь к нам, вы получаете:

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

Маленький бонус

То, что не влезло.

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

Эта картинка — про ключевые слова. Из литературы можно рекомендовать очень крутую статью на русском языке «Ключи, шифры, сообщения: как работает TLS» – прочитать целиком вряд ли удастся, но в качестве справочника пригодится. Открыл, нашел что надо, почитал, ключевые слова узнал, пошел в википедию и на английском прочитал (на русском почему-то плохо написано).

На английском написано отлично: идея, зачем, почему, ссылочки. Не знаешь, что такое HSTS – иди в википедию, там будет ссылочки на статьи для Патриков, то есть чайников. Еще на RFC, но это читать невозможно. Общий смысл станет понятен даже из самой статьи в Википедии.

Вот и всё! Вы молодцы 🙂

Настройка уведомлений о продлении

В Yosemite и более поздних версиях macOS уведомление отображается раз в день, когда до истечения срока действия сертификата остается менее 14 дней.

Время ежедневного уведомления можно изменить с помощью двух параметров конфигурации: CertificateRenewalTimeInterval и CertificateRenewalTimePercent.

Параметр CertificateRenewalTimePercent можно применить с помощью следующего синтаксиса.

Эти два параметра можно использовать вместе.

• Если в профиле задан параметр CertificateRenewalTimeInterval, используйте это значение.
• Если параметр CertificateRenewalTimeInterval задан не в профиле, а в клиенте, используйте значение CertificateRenewalTimePercent.

Если не задано ни одно из значений, временной интервал составляет 14 дней.

Не отозван ли сертификат?

Самая интересная вещь – мы дошли до нее, ура! Самая прикольная, самая неработающая 🙂

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

Чаще всего – когда ваш приватный ключ утек. Ваш приватный ключ утек – вы попали. Надо сертификат отозвать, потому что если не отозвать, тот кто украл ваш ключ, сможет подсовывать клиентам ваш сертификат и представляться вами. Надо сказать: чуваки, я поменял свой ключ – тот сертификат не действителен!

Если сделать время действия сертификата очень маленьким, то в принципе можно не отзывать, а подождать, когда он кончится. Отсюда все эти экстремальные предложения с минутами и часами. Ну, а если у тебя сертификат на 3 года, а ключ украли на второй день – то три года кто-то сможет представляться тобой.

Как же проверить, отозван сертификат или нет?

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

В этом кратком обзоре я хотел бы поделиться своим опытом, как отключить проверку SSL для тестовых сайтов, иначе говоря, как сделать HTTPS сайты доступными для тестирования на локальных машинах.

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

Всем известно, что при посещении сайта у которого “временно” что-то случилось c сертификатом вы обнаружите предупреждение, которое показывается, если сертификат безопасности не является доверенным net::ERR_CERT_AUTHORITY_INVALID?

Про сертификаты:  Чем отличается грамота от благодарности: что лучше и выше по статусу, разница

Привет онлайн-кинотеатрам

Все современные браузеры показывают сообщение об ошибке HSTS

Самый простой способ обхода данного запрета — это, разумеется, нажатие на вкладку “Дополнительные” и согласиться с Небезопасным режимом.

Но не во всех браузерах как оказывается, есть данная возможность. Так я столкнулся с данной проблемой в Chrome на Mac OS

Разработчики данной операционной системы настолько обеспокоены безопасностью пользователей, что даже убрали доступ в «Небезопасном режиме» к сайту, несмотря на то, что это сайт владельца устройства.

Ну что ж, поскольку, вести разработку в других, более сговорчивых браузерах было не комфортно, вот способы как обойти эту проблему:

— Все хромоподобные браузеры (Chrome, Opera, Edge …) могут открыть небезопасную веб страницу, если на английской раскладке клавиатуры набрать фразу:

thisisunsafe

прямо на данной веб странице. Это даст возможность работать с сайтом без оповещение об ошибке на момент текущей сессии браузера, пока вы не закроете вкладку Chrome.

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

Для Windows

C:Program Files (x86)GoogleChromeApplicationchrome.exe" --ignore-certificate-errors

Для Mac OS

/Applications/Google Chrome.app/Contents/MacOS/Google Chrome --ignore-certificate-errors --ignore-urlfetcher-cert-requests &> /dev/null

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

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

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

*Так же есть метод с добавлением сертификатов тестируемого сайта в конфиги браузера Настройки->Безопасность->Настроить сертификаты->Импорт… но мне он показался не продуктивным и очень муторным, поэтому не привожу

Надеюсь моя краткая статья кому-то пригодится при разработке и тестировании сайтов =)

Ответ клиента

Итак, Патрик проверил сертификаты и начинает отвечать Губке Бобу.

Если у клиента просили сертификаты, он их отдает. Дальше он отдает информацию для того, чтобы сделать ключики – так же, как сервер, clientKeyExchange. Поле CertificateVerify – неинтересная инфа на тему «как валидировать сертификат», в TLS 1.3 она и выглядит-то уже по-другому, потому что не сильно нужна.

После этого клиент переходит на шифрованный канал и посылает сообщение Finished – «я готов к шифрованному каналу». Сервер проверяет это сообщение – что там всё нормально, как договорились, что оно расшифровывается, что не успели на данном этапе ничего подменить и это всё еще Патрик, — тоже переходит на шифрованный канал и отдает свое Finished-сообщение, которое в свою очередь проверяет клиент. И после этого идет общение уже данными приложений по шифрованному каналу.

При чем здесь корневой сертификат

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

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

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

Новые версии устройств уже добавили в хранилище корневой сертификат ISRG Root X1, поэтому не идут дальше по цепочке доверия, чтобы проверить сайт. 

Цепочка доверия сертификатов Let’s Encrypt на новых устройствах: 

ISRG Root X1 → Let's Encrypt R3 → Конечный сертификат пользователя

А старые версии устройств все еще не распознают новый промежуточный сертификат ISRG Root X1, поэтому цепочка проверки для них выглядит так: 

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

Проблема устаревших корневых сертификатов. на очереди let’s encrypt и умные телевизоры

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

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

Специалист по безопасности Скотт Хельме (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).

Он использовался для перекрёстной подписи, чтобы обеспечить совместимость с устаревшими устройствами, в хранилище которых нет нового корневого сертификата USERTrust.

К сожалению, проблемы возникли не только в устаревших браузерах, но и в небраузерных клиентах на базе OpenSSL 1.0.x, LibreSSL и GnuTLS. Например, в телевизионных приставках Roku, сервисе Heroku, в приложениях Fortinet, Chargify, на платформе .NET Core 2.0 под Linux и многих других.

Предполагалось, что проблема затронет только устаревшие системы (Android 2.3, Windows XP, Mac OS X 10.11, iOS 9 и т.п.), поскольку современные браузеры могут задействовать второй корневой сертификат USERTRust. Но по факту начались сбои в сотнях веб-сервисов, которые использовали свободные библиотеки OpenSSL 1.0.x и GnuTLS. Безопасное соединение перестало устанавливаться с выводом ошибки об устаревании сертификата.

Ещё один хороший пример предстоящей смены корневого CA — центр сертификации Let’s Encrypt. Ещё

в апреле 2021 года

они планировали перейти с цепочки Identrust на собственную цепочку ISRG Root, но этого

не произошло

.

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

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

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

Про сертификаты:  Инструкции по настройке почты на Yandex (smtp)

Экосистема Android

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

Для проверки, что на вашем устройстве (телевизор, приставка или другой клиент) установлен корень ISRG X1, откройте тестовый сайт https://valid-isrgrootx1.letsencrypt.org/. Если не появляется предупреждение безопасности, то обычно всё в порядке.

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

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

www.bbc.co.uk (Leaf)
GlobalSign ECC OV SSL CA 2021 (Intermediate)
GlobalSign Root CA - R5 (Intermediate)
GlobalSign Root CA - R3 (Intermediate)

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

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

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

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

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

---

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

Шаг № 1. Переводим программу в экспертный режим, который предоставляет доступ к полному перечню функций.

Шаг № 2. Выбираем подозрительный для операционной системы сертификат ЭЦП. Для этого:

1. подключаем носитель с цифровой подписью к вашему компьютеру;
2. выбираем действующий криптопровайдер и тип носителя;
3. выбираем контейнер с цифровой подписью (если на токене их несколько, выбираем проблемный);
4. вводим PIN-код для доступа (стандартный пароль для eToken — 1234567890, для Рутокен — 12345678).

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

1. перейдите в меню программы «КриптоАРМ»;
2. войдите во вкладку «Свойства» конкретного проблемного сертификата (ее можно найти в подразделе «Личное хранилище» раздела «Сертификаты»);
3. зайдите во вкладку «Статус»;
4. кликните по кнопке «Посмотреть»;
5. нажмите «Установить»;
6. выберите раздел «Поместить сертификаты в хранилище»;
7. нажмите «Обзор» и выберите пункт «Доверенные корневые сертификаты»;
8. подтвердите действие.

Сам процесс занимает несколько секунд и требует последующей перезагрузки системы.

Шаг № 4. Финальным этапом остается проверка сертификата по перечню отозванных. Для этого:

1. выберите нужный сертификат во вкладке «Свойства сертификата»;
2. выберите пункт «По CRL, полученному в УЦ»;
3. кликните по кнопке «Проверить».

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

Сertificate transparency

Итак, всё хорошо, но Google не был бы Google, если бы не придумал еще одну технологию конкретно для себя. Она называется Сertificate Transparency. Откуда что идет: Google очень беспокоится о том, чтобы кто-нибудь не выписал плохой сертификат на него самого – чтобы именно Google не пострадал от того, что кто-то там выписывает какие-то нехорошие сертификаты.

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

Это не только технология, но и набор процессов. То есть Google говорит: ребята, вот у нас есть Сertificate Transparency, мы в него записываем только нормальные сертификаты – такие, где цепочка есть, цепочка правильная и всё нормально. Мы можем время записи Сertificate Transparency Log запихать в сертификат, чтобы клиент мог четче посмотреть, что вот этот сертификат в Transparency Log должен быть тогда-то.

Мы гарантируем, что это вот эта штука не редактируема обратно (из-за того, что блокчейн) – ну то есть нельзя взять и подменить старые записи, можно только добавлять новые. И давайте, ребята, кто-нибудь из вас будет периодически ходить по этому логу, и проверять, что там всё нормально, а если что-то не так, говорить нам и мы будем это править. А другие ребята пусть держат у себя всё это, потому что надо, чтобы было много мощностей на вот эту вот штуку.

Создание новой настройки сертификата

В программе «Связка ключей»

на Mac выберите «Вход» в списке «Связки ключей».

Выберите пункт «Сертификаты» в списке под названием «Категория».

Для этого выполните следующее:

Выберите сертификат, который хотите использовать, а затем перейдите в пункт меню «Файл» > «Новая настройка сертификата».

Перейдите в пункт меню «Файл» > «Новая настройка сертификата», нажмите всплывающее меню «Сертификат», а затем выберите сертификат, который требуется использовать.

В строке «Размещение или адрес e‑mail» введите размещение (URL) или адрес e‑mail, для которого необходим сертификат.

Чтобы просмотреть созданные настройки сертификатов, нажмите на заголовок столбца «Тип» в окне просмотра сертификатов, а затем найдите вхождения «настройка сертификата» в столбце «Тип».

Создание самоподписанных сертификатов в связке ключей на mac

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

В программе «Связка ключей»

на Mac выберите пункт меню «Связка ключей» > «Ассистент сертификации» > «Создать сертификат».

Выберите тип идентификации, а затем выберите тип сертификата.

Для информации о типах сертификатов нажмите «Подробнее».

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

Примечание. Можно создавать ключи RSA длиной до 4096 бит. Ключи RSA длиной меньше 2048 бит больше не поддерживаются.

Просмотрите сертификат и затем нажмите «Готово».

источник

Тот ли тип использования?

Кроме проверки, тот ли это домен, не истёк ли срок годности и валидна ли подпись, из таких вещей, которые достаточно просто делаются, у нас еще есть пункт «тот ли тип использования».

Сертификаты бывают разные. То есть, если в Key Usage не указаны вот эти вот два параметра, то это – по идее! – должно влиять на то, как клиент с этим работает.

Key agreement – это как раз когда мы выписываем сеансовые ключи и договариваемся о них. Обычно вся эта коммуникация подписывается или шифруется вот этим вот публичным ключом, который чуть выше. Но если в key usage не прописан key agreement, то это означает, что ишьюер этого сертификата запрещает использовать этот сертификат для вот этого назначения.

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

Удаление настройки сертификата

В программе «Связка ключей»

на Mac выберите «Вход» в списке «Связки ключей».

Выберите «Все объекты» в списке под названием «Категория».

Нажмите на заголовок столбца «Тип», чтобы отсортировать все объекты столбца по типу, а затем прокручивайте вниз, пока не увидите заданные Вами настройки сертификатов.

Выберите настройку сертификата и нажмите клавишу Delete, затем нажмите кнопку «Удалить».

источник