Leaderssl Хостинг

CA/B Forum, регулирующий орган в индустрии SSL-сертификатов, принял изменения, связанные с введением CAA-записей для выпуска S/MIME-сертификатов. Теперь CAA-записи поддерживаются и для доменов электронной почты, что определено в стандарте RFC 9495.

CAA-записи позволяют владельцам доменов использовать DNS для указания того, какие центры сертификации (ЦС) могут выдавать TLS-сертификаты для данного домена. Запись CAA дает владельцу дополнительный контроль над использованием его домена и уменьшает риск случайной неправильной выдачи сертификата.

Удостоверяющие центры должны учитывать проверку CAA для TLS-сертификатов в соответствии с правилами CA/B, и множество доменов уже используют записи CAA для указания одного или нескольких доверенных удостоверяющих центров для TLS-сертификатов.

Случай с S/MIME достаточно отличается от TLS, а потому для него были введены отдельные определения CAA. К примеру, организация может разрешить определенным УЦ выдавать TLS-сертификаты для своих доменов, но при этом список УЦ для выдачи S/MIME-сертификатов будет другим.

Обработка CAA применительно к доменам электронной почты осуществляется следующим образом: задается новая CAA-метка «issuemail» для использования в контексте S/MIME. С помощью этих меток владельцы доменов могут указывать одобренные УЦ для выдачи S/MIME-сертификатов для доменов электронной почты.

Проверка CAA для S/MIME теперь является обязательной для УЦ перед выдачей соответствующих сертификатов.

На днях удостоверяющий центр GlobalSign объявил о переходе на новую иерархию корневых сертификатов Alpha SSL – с R1 на R6. Сделано это с целью соответствия обновленной политике корневого хранилища Mozilla и базовым требованиям CA/B Forum.

С 29 января 2024 года все процедуры перевыпуска или продления сертификатов будут автоматически осуществляться уже через новый выпускающий R6 CA, именуемый GlobalSign GCC R6 AlphaSSL CA 2023.

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

Нужно ли мне прямо сейчас совершать какие-либо действия, если у меня есть активный сертификат GlobalSign?

Нет. Сертификаты, выпущенные R1 CA, будут функционировать в течение всего срока действия (их перевыпуск не требуется). Если же Ваш сертификат был перевыпущен по какой-либо другой причине, установить его необходимо будет уже вместе с новым промежуточным сертификатом.

Что от меня требуется, если я в настоящее время занимаюсь покупкой сертификата GlobalSign (или продлеваю сертификат, у которого заканчивается срок действия)?

Если новый сертификат будет выпущен после 29 января 2024 года, то установить Ваш сертификат необходимо будет уже вместе с новым промежуточным сертификатом.

Выпущено обновление свободной, открытой библиотеки OpenSSL 3.2, используемой для обеспечения безопасного соединения в сетях. Работа над OpenSSL 3.2 длилась более 2 лет. Было собрано более 4000 коммитов и предложений от 300 разных авторов.


Выпущено обновление свободной, открытой библиотеки OpenSSL 3.2, используемой для обеспечения безопасного соединения в сетях.

Работа над OpenSSL 3.2 длилась более 2 лет. Было собрано более 4000 коммитов и предложений от 300 разных авторов.

В числе основных нововведений OpenSSL 3.2 можно отметить:

• Сжатие сертификатов TLS.
• Поддержка TCP Fast Open в системах Linux, FreeBSD и macOS.
• Поддержка zlib, Brotli, Zstandard, SM4-XTS.
• Поддержка алгоритма Argon2 KDF и функционала пула потоков (Thread Pool).
• Библиотека OpenSSL 3.2 теперь поддерживает гибридное кодирование с открытым ключом (HPKE), необработанные открытые ключи TLS (TLS Raw Public Keys), QUIC с клиентской стороны (серверная поддержка QUIC должна появиться в OpenSSL 3.3-3.4), многопоточность, алгоритмы цифровой подписи Ed25519ctx, Ed25519ph и Ed448ph, детерминированные подписи ECDSA, подписи AES-GCM-SIV.

В дополнение к этому, OpenSSL 3.2 включает поддержку подключаемых алгоритмов подписи в TLS 1.3 с поддержкой CMS и X.509, что позволяет использовать постквантовую криптографию.

Базовый уровень безопасности SSL/TLS изменен по умолчанию с 1 на 2. Также в OpenSSL 3.2 добавлена поддержка использования стандартных имен IANA при настройке кодов TLS, реализована поддержка использования хранилища сертификатов Windows в качестве источника доверенных корневых сертификатов.

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

Релиз OpenSSL 3.2 доступен для загрузки на официальном сайте. Всем пользователям рекомендовано как можно скорее обновиться до свежей версии.

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

Изначально иконка замка для передачи сайтов по HTTPS появилась еще в первых версиях Netscapе в далекие девяностые. Сегодня уже более 95% всех сайтов передаются по HTTPS. По причине такого широкого распространения компания Google задумалась над тем, чтобы как-то видоизменить сигналы о безопасных соединениях в браузере.

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

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

Вместо замка в браузере Chrome будет выводиться иконка «tune», отсылающая к меню настроек. Этот нейтральный индикатор призван устранить всю двусмысленность, которая имелась ранее. Новая иконка:

• призывает совершить клик по ней;
• не говорит о том, что сайт автоматически доверенный;
• ассоциируется с настройками, опциями, а также другими аналогичными элементами управления.

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

Когда ждать нововведений
Новая иконка появится в Chrome 117 в начале сентября 2023. Также ее можно будет видеть в Chrome для Android. В приложении iOS иконка замка будет полностью удалена, поскольку по ней нельзя кликать.

Посмотреть, как выглядит иконка еще на стадии разработки, можно, скачав Chrome Canary и активировав Chrome Refresh 2023 по ссылке chrome://flags#chrome-refresh-2023. Обратите внимание, что разработка все еще ведется, потому финальный результат может существенно отличаться от текущей фазы.

Согласно CA/B Forum, регулятору SSL-индустрии, с 15 ноября 2022 года приватные ключи для OV Code Signing сертификатов должны храниться на устройствах, отвечающих стандартам безопасности FIPS 140 Level 2, Common Criteria EAL 4+ или аналогичным. В итоге защита приватного ключа будет усилена и доведена до уровня EV (Extended Validation).

Изменения выпуска OV Code Signing затронут все сертификаты, выпущенные, перевыпущенные или продленные с 15 ноября 2022 года.

Пользователям больше не придется самостоятельно совершать CSR-запросы, поскольку теперь вся техническая часть по выпуску Code Signing сертификата будет осуществляться на стороне удостоверяющего центра.

Приватные ключи и сертификаты должны по новым правилам храниться на токенах или на HSM-модулях (аппаратные модули безопасности), которые имеют сертификацию по стандартам не ниже FIPS 140-2 Level 2 или Common Criteria EAL 4+.

Как будет проходить процесс подписи кода с 15 ноября 2022 года
Чтобы использовать Code Signing сертификат, хранящийся на токене/HSM, пользователю потребуется физический доступ к этому устройству, а также учетные данные для использования сертификата.

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

Как будет проходить заказ и продление Code Signing сертификатов с 15 ноября 2022 года
В случае с заказом или продлением Code Signing-сертификата пользователю нужно будет выбрать подходящий метод доставки. Иными словами, нужно будет выбрать вид устройства, на котором придет приватный ключ. Удостоверяющие центры предлагают три варианта доставки:

• На физическом токене (предустановленный сертификат).
• На HSM-модуле.
• С использованием вашего собственного поддерживаемого токена.

Как мы отмечали выше, токены и HSM-модули должны отвечать стандартам безопасности FIPS 140 Level 2, Common Criteria EAL 4+ или аналогичным. Для использования HSM-модуля потребуется направить удостоверяющему центру аттестационное письмо с информацией о пройденном аудите.

Как будет проходить перевыпуск Code Signing сертификатов с 15 ноября 2022 года
В случае с перевыпуском Code Signing сертификата пользователям нужно будет установить сертификат на поддерживаемый токен/HSM. Если токена нет, то в таком случае его нужно будет дополнительно заказать.

В данный момент удостоверяющие центры налаживают процедуру покупки токенов при перевыпуске Code Signing-сертификатов. Как только цены и условия приобретения будут известны, мы добавим соответствующую информацию на сайт.

Ознакомиться с полными правилами выпуска OV Code Signing-сертификатов можно в документе «Baseline Requirements (BR) for the Issuance and Management of Code Signing (v. 2.8)», который доступен на сайте CA/B Forum.

Подписывайтесь на нашу рассылку, чтобы быть в курсе свежих событий из мира SSL!

CA/B Forum, регулятор в индустрии SSL-сертификатов, принял большинством голосов новый Ballot SC53. Теперь SHA-1 OCSP-подписи больше не поддерживаются.

OCSP (Online Certificate Status Protocol) или протокол состояния сетевого сертификата — это интернет-протокол, используемый для получения статуса отзыва цифрового сертификата X.509.

Алгоритм хеширования SHA-1, применяемый для подписей, недостаточно устойчив.

Уже давно был введен запрет на использование приватных ключей для прямой подписи OCSP-ответов с помощью SHA-1.

Однако приватные ключи, соответствующие делегированным ответчикам OCSP, по-прежнему могли использоваться для подписи OCSP-ответов с помощью алгоритма SHA-1.

Что делает новый Ballot SC53

• Новый Ballot SC53 вносит следующие изменения в документ «Baseline Requirements»:
• Появился пункт 7.1.3.2.1, гласящий, что удостоверяющий центр больше не может подписывать OCSP-ответы с помощью алгоритма SHA-1.
• Поле producedAt для ResponseData в OCSP-ответе должно содержать дату до 2022-06-01 00:00:00 UTC.

Компания Apple продолжает отказываться от поддержки Transport Layer Security 1.0 и 1.1 в своих операционных системах.

Протоколы TLS 1.0 и 1.1 признаны устаревшими в iOS 15, iPadOS 15, watchOS 8, macOS 12 и tvOS 15. В последующих релизах поддержка этих протоколов будет удалена.

Первый шаг, который сделали специалисты Apple на пути к большей безопасности — перевод Safari на TLS 1.2 и 1.3 в 2020 году. Эти изменения появились в бета-версиях релизов iOS 13.4 и macOS 10.15.4.

Компания порекомендовала разработчикам, чьи приложения пока еще работают со старыми версиями протокола TLS, начать постепенный переход к TLS 1.2 или выше. Версия TLS 1.3 была официально одобрена Internet Engineering Task Force (IETF) еще в марте 2018 года.

Microsoft, Google, Apple и Mozilla поддерживают совместные усилия по переходу к безопасным версиям TLS. В августе 2020 года Microsoft включила TLS 1.3 по умолчанию в свежие сборки Windows 10 Insider.

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

В случае принятия изменений сайты, доступные по HTTPS, больше не будут иметь иконку замочка в Chrome 93. При этом ресурсы, которые работают по HTTP, по-прежнему будут маркироваться как «Not secure».

Протестировать изменение можно уже сейчас в сборках Chrome 93 Beta и Chrome 94 Canary. Чтобы сделать это, необходимо установить флаг Omnibox Updated connection security indicators.

Вводим chrome://flags в адресную строку Chrome 93 Beta или Chrome 94 Canary.
Ищем раздел security indicators.
Задаем Enabled для флага Omnibox Updated connection security indicators.
Перезапускаем браузер.
Также в Chrome 93 будет введена корпоративная политика LockIconInAddressBarEnabled для компаний, которые не готовы отказаться от вывода замочка в адресной строке для HTTPS-сайтов.

Изменение находится на этапе тестирования. Даже если текущий дизайн будет изменен, пользователи по-прежнему смогу выявлять незащищенные сайты с помощью указателя «Not secure».

Релиз Chrome 93 ожидается 31 августа 2021 года.

В результате дополнительных проверок CA/B Forum выяснил, что секция 3.2.2.8 текущих правил по выпуску SSL-сертификатов (Baseline Requirements) содержит дыры в безопасности, связанные с проверкой CAA.

В настоящий момент секция 3.2.2.8 позволяет обойти проверку CAA, если удостоверяющий центр (или его аффилированное лицо) является DNS-оператором.

Определение DNS-оператора, данное в RFC 7719, содержит четкое техническое описание того, как конфигурируются и передаются зоны авторитетных серверов (включая NS-записи). Соответственно, удостоверяющий центр может обойти проверку CAA-записи, но это не освобождает его от необходимости поиска всех остальных записей при выдаче каждого сертификата.

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

Чтобы избежать подобных проблем, с 1 июля 2021 года оператор DNS должен будет выполнять проверку CAA. Это позволит снизить двусмысленность правил выпуска сертификатов для удостоверяющих центров.

leaderssl.ru/

CA/B Forum, регулятор индустрии SSL-сертификатов, одобрил несколько изменений, связанных с политикой валидации доменов. Изменения касаются всех новых сертификатов, а также перевыпусков и продлений старых сертификатов. Уже выпущенные SSL/TLS-сертификаты продолжат функционировать (менять их не потребуется).

ПОВТОРНАЯ ВАЛИДАЦИЯ ДОМЕНОВ ПОТРЕБУЕТСЯ КАЖДЫЕ 398 ДНЕЙ

Начиная с 1 октября 2021 года, повторная валидация доменов (FQDN) должна будет проводиться каждые 398 дней. То же самое относится и к повторной валидации IP-адресов. Это изменение отмечено в Ballot SC42. Для проверки по организации (OV) остается все тот же 825-дневный период повторного использования данных.

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

ИЗМЕНЕНА ПРОВЕРКА УПРАВЛЕНИЯ ДОМЕНОМ (DCV) С ИСПОЛЬЗОВАНИЕМ ФАЙЛОВОЙ АУТЕНТИФИКАЦИИ

CA/B Forum внес некоторые изменения в файловую аутентификацию доменов. Метод проверки управления доменом на базе файлов будет запрещен для wildcard-сертификатов. При этом для отдельных поддоменов такая проверка будет осуществима.
Методы проверки управления доменом на базе Email и DNS не будут затронуты.

Изменение политики CA/B Forum требует проведения отдельной проверки на базе файлов для каждого FQDN. При этом валидация на базе Email и DNS будет все так же работать для wildcard-сертификатов. Ее можно будет применить для валидации всех поддоменов одного проверенного домена. Данное изменение вступит в силу 1 декабря 2021 года.

НУЖНО ЛИ МНЕ ЧТО-ТО ДЕЛАТЬ В СВЯЗИ С ЭТИМИ ИЗМЕНЕНИЯМИ

Каких-либо срочных действий совершать не требуется.
Чтобы лучше подготовиться к данным изменениям, мы рекомендуем изменить метод валидации доменов на email или DNS для wildcard и мультидоменных сертификатов. Файловая аутентификация подойдет только для отдельных доменов (она перестанет охватывать все пространство доменов внутри проверенного домена).