Изменились правила выпуска публичных 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

Браузер Google Chrome 90 будет использовать протокол HTTPS по умолчанию



В последнем обновлении браузер Google Chrome стал еще быстрее и безопаснее. Теперь по умолчанию для открытия страниц будет использоваться протокол HTTPS вместо HTTP. Разработчики Chrome уже давно призывают всех владельцев сайтов переходить на HTTPS.

Как следует из поста, опубликованного в блоге Chromium, любые записи в адресной строке браузера, не включающие в себя какой-либо протокол, будут получать префикс https://

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

Если сайт до сих пор не поддерживает протокол HTTPS, браузер попытается обратиться к его HTTP-версии. Также протокол HTTP будет использоваться по умолчанию для IP-адресов, однокомпонентных доменов (single label domain) и зарезервированных имен хостов (reserved hostnames).

Изменения появятся в версии Chrome 90 для десктопов и для Android-устройств. Чуть позже должен выйти релиз Chrome для iOS.

С 1 марта 2021 года Sectigo удалит информацию о полном адресе и почтовом индексе из всех публичных сертификатов



С 1 марта 2021 года Sectigo удалит информацию о полном адресе (Street address) и почтовом индексе (Postal/Zip code) из всех публичных сертификатов. Как отметили представители удостоверяющего центра, эта информация не является необходимой для включения в сертификаты. Технические спецификации ее не требуют. Изменение затрагивает все публичные OV/EV SSL и OV/EV Code Signing сертификаты.
www.leaderssl.ru

В Firefox 83 появился режим HTTPS-Only



В браузере Mozilla Firefox 83 появился новый режим HTTPS-Only. Когда он активирован, происходит следующее:
  • Firefox пытается установить защищенные соединения со всеми сайтами, которые вы посещаете;
  • Firefox запрашивает у вас разрешение на то, чтобы посетить сайт, который доступен только по HTTP.
Сегодня сайты, работающие только по небезопасному и устаревшему протоколу HTTP, становятся редкостью. Также в сети имеется множество старых ссылок, открывающихся по HTTP. Если вы перейдете по такой ссылке, браузер перенесет вас на HTTP-версию сайта.

Режим HTTPS-Only гарантирует, что Firefox не будет переносить вас на HTTP-сайты без вашего прямого разрешения. Все соединения будут полностью защищенными.

Как включить режим HTTPS-Only
Включить режим HTTPS-Only в Firefox легко:
  • Переходим в меню браузера и выбираем Preferences.
  • Далее выбираем раздел Privacy & Security и переходим в секцию HTTPS-Only Mode.
  • Включаем режим HTTPS-Only.
Если сайт недоступен по HTTPS, вы увидите следующее предупреждение


Бывает и так, что сам сайт доступен по HTTPS, но его внутренние ресурсы отдаются по HTTP (ошибка смешанного содержимого). По этой причине некоторые страницы сайта будут выглядеть некорректно. Тогда вы можете временно отключить режим HTTPS-Only, щелкнув по иконке замочка в адресной строке браузера.

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

www.leaderssl.ru