CA/B Forum одобрил использование CAA-записи для S/MIME-сертификатов



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

На днях удостоверяющий центр 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, используемой для обеспечения безопасного соединения в сетях. Работа над 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 доступен для загрузки на официальном сайте. Всем пользователям рекомендовано как можно скорее обновиться до свежей версии.

Изменились правила выпуска публичных OV Code Signing сертификатов



Согласно 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!

Принят Ballot SC53, связанный с отказом от SHA-1 OCSP-подписей



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 перестанет поддерживать TLS 1.0 и 1.1, начиная с iOS 15 и macOS 12



Компания 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 могут использоваться злоумышленниками для получения доступа к приватным данным.

Разработчики Google Chrome планируют удалить иконку замочка для HTTPS-сайтов



В случае принятия изменений сайты, доступные по 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 года.

С 1 июля 2021 года DNS-операторы будут обязаны проверять CAA-записи при выпуске сертификатов



В результате дополнительных проверок 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/

Изменения, связанные с проверкой доменов для выпуска SSL-сертификатов в 2021 году



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 и мультидоменных сертификатов. Файловая аутентификация подойдет только для отдельных доменов (она перестанет охватывать все пространство доменов внутри проверенного домена).

Новые требования к размеру RSA-ключей для Code Signing сертификатов DigiCert



Начиная с 27 мая 2021 года, для выпуска Code Signing сертификатов DigiCert потребуются RSA-ключи размером 3072-бит или выше.

Это изменение связано с ужесточившимися стандартами индустрии. Новые требования к размеру RSA-ключа касаются всей цепочки сертификатов (корневого, конечного сертификата и всех промежуточных). При этом требования к ECC-ключам остались неизменными.
  • Все сертификаты, выпущенные до 27 мая, не нуждаются в изменениях. Они продолжат работать до конца своего срока действия.
  • После 27 мая все новые, продленные и повторно выпущенные сертификаты Code Signing от DigiCert будут автоматически выпускаться с обновленными цепочками (с новыми промежуточными и корневыми сертификатами).
  • После 27 мая все Code Signing сертификаты будут требовать RSA-ключи размером 3072-бит или выше. Для EV Code Signing сертификатов нужен будет новый токен (или HSM), поддерживающий минимум 3072-битные ключи. В настоящий момент токены и HSM поддерживают в основном только 2048-битные ключи.

Что нужно сделать вам
Если в вашей среде отсутствуют прикрепленные (pinned) или напрямую прописанные (hard coded) ссылки на промежуточные и корневые сертификаты, вам не потребуется ничего делать. В противном случае вам придется обновлять свою среду.

Для EV Code Signing сертификатов вам нужно будет получить HSM/токен, поддерживающий размер RSA-ключа минимум 3072-бит.

leaderssl.ru