Промежуточный сертификат ssl: Что такое промежуточный сертификат?

Содержание

Что такое промежуточный сертификат?

Промежуточный сертификат SSL (intermediate certificate) – это одно из звеньев в цепочке доверия, которое позволяет связать Ваш личный SSL сертификат с корневым центром сертификации.

Промежуточный центр сертификации SSL

Существует два типа сертификационных центров: корневые и промежуточные. Часто SSL сертификаты выдаются промежуточными центрами сертификации. Таким, например, является бренд AlphaSSL для GlobalSign или RapidSSL для компании Geotrust. Для того, чтобы SSL сертификат был доверенным, а часто и для того, чтобы вообще установить защищенное соединение, он должен быть выдан центром сертификации, включенным в список доверенных в браузере или устройстве. Поэтому, прежде, чем установить соединение с сервером, браузер клиента проверяет содережащийся список с установленными корневыми сертификатами. Для примера возьмем PositiveSSL, установленный для личного кабинета на нашем сайте emaro-ssl.ru.

В данном случае нашим личным SSL сертификатом будет “emaro-ssl.ru” (владелец: emaro-ssl.ru; издатель: PositiveSSL CA 2), промежуточным – PositiveSSL CA 2 (владелец: PositiveSSL CA 2; издатель: USERTrust), а корневым – USERTrust, который принадлежит компании Comodo.

Зачем применять промежуточный сертификат?

Изначально браузер доверяет корневому сертификату USERTrust, так как он находится в списке доверительных. Поэтому для установления зависимости между emaro-ssl.ru и USERTrust (корневым центром сертификации), необходим посредник, так называемый Intermediate certificate.

Обнаружив, что emaro-ssl.ru подкреплен промежуточным сертификатом PositiveSSL CA 2, который в свою очередь привязан к корневому, браузер может установить защищенное https соединение. В некоторых случаях, особенно для если речь идет об EV SSL (с расширенной проверкой), цепочка доверия может содержать два или три промежуточных сертификата Intermediate. Это делается для обеспечения более надежного уровня защиты.

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

Intermediate certificate содержит подробную информацию о цепочке обладания правом на издательство SSL и включает в себя:

  • имя доверенного сертификационного центра, обладателя корневого сертификата;
  • домен и/или название организации, для которой был создан SSL-сертификат, применяемый для обеспечения безопасности соединения.

Установка

Метод установки зависит от программного обеспечения, поэтому в каждом отдельном случае рекомендуем воспользоваться нашими инструкциями по установке. Следует заметить, что в некоторых случаях (например, для Apache), необходимо пройти дополнительный шаг – создать ca bundle.

Промежуточный сертификат SSL и его настройка

Центры выдачи сертификатов SSL часто подписывают сертификаты, выдаваемые клиентам, не напрямую своими корневыми сертификатами (Root certificate CA), а промежуточными (Intermediate certificate CA).

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

Промежуточный сертификат можно скачать по следующим ссылкам:

COMODO: https://support.comodo.com/index.php?/Default/Knowledgebase/Article/View/620/0/which-is-root-which-is-intermediate

StartSSL, StartCom: https://www.startcomca.com/root

RapidSSL: https://knowledge.rapidssl.com/support/ssl-certificate-support/index?page=content&id=INFO1548&actp=LIST&viewlocale=en_US

Промежуточный сертификат в панели управления ISPmanager

В панели управления ISPmanager существует отдельное поле для добавления промежуточного сертификата. Воспользоваться им можно при добавлении сертификата, SSL-сертификаты —> «Создать»:

Промежуточный сертификат в сервере HTTP Apache

В сервере HTTP Apache путь к файлу с промежуточным сертификатом указывается с помощью директивы SSLCertificateChainFile

.

DocumentRoot /var/www
ServerName www.yourdomain.com
SSLEngine on
SSLCertificateFile /path/to/your_domain_name.crt
SSLCertificateKeyFile /path/to/your_private.key
SSLCertificateChainFile /path/to/DigiCertCA.crt

Промежуточный сертификат в сервере HTTP nginx

У сервера HTTP nginx нет отдельной опции для промежуточного сертификата. Необходимо создать специальный файл, в котором сначала идет сертификат сервера, а затем – промежуточный сертификат центра авторизации:
$ cat www.example.com.crt bundle.crt > www.example.com.chained.crt

Полученный таким образом файл необходимо указать в директиве ssl_certificate:
server {
listen 443 ssl;
server_name www.example.com;

ssl_certificate www.example.com.chained.crt;
ssl_certificate_key www.example.com.key;
...
}

Что такое корневой сертификат (СА) – Помощь

Корневой сертификат (СА) — часть ключа, которым центры сертификации подписывают выпущенные SSL-сертификаты. Выдавая корневой сертификат, каждый такой центр гарантирует, что пользователи или организации, запросившие SSL, верифицированы и действия с доменом легальны.

Центры сертификации с двадцатилетней историей: GlobalSign, Comodo, Symantec, TrustWave, GeoTrust. Они используют «именные» корневые сертификаты, которые распознаются большинством современных браузеров.

Это значит: если на сайт установлен корневой сертификат

GlobalSign, браузер идентифицирует его как выпущенный доверенным «поручителем» и приступает к частной проверке сайта.

Если информация о корневом сертификате центра отсутствует в браузере, у сайта нет «поручителя», и браузер считает его недостоверным. Так иногда происходит с самоподписанными сертификатами безопасности (например, Let’s Encrypt):

Читайте об этом в статье Браузер пишет, что подключение не защищено или соединение является недоверенным.

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

индивидуальный сертификат домена, которые так же выдаются центром сертификации при выпуске SSL. Достоверность промежуточных и «индивидуальных» сертификатов подтверждается корневым сертификатом. Цепочка сертификатов, установленных на сайт, дает основание считать его «защищенным SSL-сертификатом» в сети Интернет.


Данные вашего сайта под защитой

Установите SSL-сертификат, и ваш сайт будет работать по безопасному соединению HTTPS

Где взять корневой сертификат?

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

Также вы можете воспользоваться специальным предложением REG.RU и получить

бесплатный SSL-сертификат на 1 год при заказе домена или хостинга. Читайте об этом в статье: Как заказать бесплатный SSL-сертификат?

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

Могу ли я создать корневой сертификат самостоятельно?

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

Установка цепочки сертификатов

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

Была ли эта статья полезной?

Да Нет

Пользователи, считающие этот материал полезным: 3 из 5

Что такое центры сертификации и иерархии доверия?

Что такое центры сертификации и иерархии доверия? 


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

Сертификат SSL — это популярный тип цифрового сертификата, который привязывает информацию о владельце веб-сервера (и веб-сайта) к ключу шифрования. Эти ключи используются в ючу шифрования. Эти ключи используются в протоколе SSL/TLS для создания безопасной сессии между браузером и веб-сервером, на котором расположен SSL-сертификат. Чтобы браузер мог доверять SSL-сертификату и выполнял сессию SSL/TLS без предупреждений безопасности, SSL-сертификат должен содержать доменное имя веб-сайта, использующего этот сертификат, должен быть выдан надежным центром сертификации и быть действующим.

По данным аналитического сайта Netcraft (www.netcraft.com), в августе 2012 года на общедоступных веб-сайтах использовались почти 2,5 млн SSL-сертификатов. Есть вероятность, что на самом деле их на 50% больше, но реальное число на общедоступных веб-сайтах Netcraft определить не в состоянии. Это делает SSL одной из самых распространенных технологий безопасности, применяемых в настоящее время.

Как при таком обилии SSL-сертификатов определить, какому центру сертификации можно доверять?

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

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

Более подробная информация о разных классах SSL-сертификатов содержится в статье: Классы сертификатов и примеры их использования.

PKI и иерархии доверия

Браузеры и устройства доверяют центру сертификации, принимая  корневой сертификат  в свое хранилище — специальную базу данных об утвержденных центрах сертификации, которая предустановлена в браузерах и на устройствах. Windows поддерживает свое хранилище корневых сертификатов, так же поступают Apple и Mozilla (для своего браузера Firefox). Многие операторы мобильной связи также имеют собственное хранилище.

Хранилище Apple OSX доверенных корневых сертификатов

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

Обычно центры сертификации создают множество корневых сертификатов промежуточных центров сертификации (ICA), которые выдают сертификаты конечным пользователям, в том числе SSL-сертификаты. Это называется иерархией доверия и выглядит следующим образом: 

Центры сертификации не должны выдавать цифровые сертификаты напрямую из корневого сертификата, передаваемого операторам, а только через один или несколько промежуточных центров сертификации (ICA). Центры сертификации обязаны выполнять рекомендации по безопасности чтобы свести к минимуму уязвимость корневого центра сертификации для хакерских атак. GlobalSign — один из немногих центров сертификации, которые всегда (с 1996 года) использовали ICA.

Что входит в работу центра сертификации?

Центры сертификации служат оплотом доверия в интернете и поэтому несут особую ответственность. Работа центра сертификации с соблюдением всех требований к аудиту является сложной задачей. Инфраструктура центров сертификации включает в себя значительное количество операционных элементов, аппаратного и программного обеспечения, политик отправителей и положений о правилах, проверок, элементов инфраструктуры безопасности и персонала. В совокупности эти элементы называются доверенной инфраструктурой открытого ключа (PKI).

Сертификаты бывают разных форматов и поддерживают не только SSL, а еще и аутентификацию людей и устройств, а также заверяют подлинность кода и документов. Посетите раздел Продукты GlobalSign для получения более подробной информации.

Разбираемся в наборах файлов SSL сертификатов

Разбираемся в наборах файлов SSL сертификатов

Покупая SSL сертификат, чтобы перевести свой сайт на HTTPS, вы получаете определенный набор файлов сертификата, и не всегда с первого взгляда на этот список файлов, можно разобраться, а какой файл (содержимое) и куда вставить, чтобы все корректно прикрепить.

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

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

Установка сертификата от Comodo

По умолчанию, Центр сертификации отправляет корневой (Root) и промежуточный (Intermediate) сертификаты вместе с основным в архиве. Стоит отметить, что в архиве может быть не один, а несколько промежуточных сертификатов. Данный факт зависит от типа заказанного SSL сертификата. На текущий момент, Центр Сертификации предоставляет следующую цепочку сертификатов.

EV

  • private.key — приватный ключ (вставлять в первое поле). Ключ вы генерируете сами вначале регистрации сертификата.
  • name_domain.crt — сертификат для вашего домена (вставлять в второе поле).
  • COMODOAddTrustServerCA.crt — промежуточный сертификат (вставлять в третье поле).
  • COMODOExtendedValidationSecureServerCA.crt — промежуточный сертификат (вставлять четвертое поле).
  • AddTrustExternalCARoot.crt — корневой сертификат (вставлять в пятое поле).

GoGetSSL Domain SSL

  • private.key — приватный ключ (вставлять в первое поле). Ключ вы генерируете сами вначале регистрации сертификата.
  • вашдомен.crt —  сертификат для вашего домена (вставлять в второе поле).
  • USERTrust_RSA_Certification_Authority.crt — промежуточный сертификат (вставлять в третье поле).
  • AddTrust_External_CA_Root.crt — корневой сертификат (вставлять в четвертое поле).

Sectigo SSL

  • private.key — приватный ключ (вставлять в первое поле). Ключ вы генерируете сами вначале регистрации сертификата.
  • name_domain.crt — сертификат для вашего домена (вставлять в второе поле).
  • AAA_Certificate-Services.crt — промежуточный сертификат (вставлять в третье поле).
  • USERTrust_RSA_Certification_Authority.crt  — промежуточный сертификат (вставлять в четвертое поле).

Sectigo

  • private.key — приватный ключ (вставлять в первое поле). Ключ вы генерируете сами вначале регистрации сертификата.
  • name_domain.crt — сертификат для вашего домена (вставлять в второе поле).
  • AAACertificateServices.crt — промежуточный сертификат (вставлять в третье поле).
  • USERTrustRSAAAACA.crt  — промежуточный сертификат (вставлять в четвертое поле).
  • SectigoRSADomainValidationSecureServerCA.crt — промежуточный сертификат (вставлять в пятое поле).

GoGetSSL от Comodo

  • private.key — приватный ключ (вставлять в первое поле). Ключ вы генерируете сами вначале регистрации сертификата.
  • name_domain.crt — сертификат для вашего домена (вставлять в второе поле).
  • AAACertificateServices.crt — промежуточный сертификат (вставлять в третье поле).
  • USERTrustRSAAAACA.crt  — промежуточный сертификат (вставлять в четвертое поле).
  • GoGetSSLRSADVCA.crt — промежуточный сертификат (вставлять в пятое поле).

GlobalSign DV SSL / Сертификат от Reg.ru

  • Приватный RSA PRIVATE KEY — вставить в первое поле.
  • Ваш SSL сертификат — вставить в второе поле.
  • Промежуточный сертификат — вставить в третье поле.
  • Корневой сертификат — добавьте четвертое поле и в него вставьте.

InstantSSL

  • private.key — приватный ключ (вставлять в первое поле). Ключ вы генерируете сами вначале регистрации сертификата.
  • name_domain.crt — сертификат для вашего домена (вставлять в второе поле).
  • ComodoHigh-AssuranceSecureServerCA.crt — промежуточный сертификат (вставлять в третье поле).
  • AddTrustExternalCARoot.crt — корневой сертификат (вставлять в четвертое поле).

ComodoSSL / ComodoSSL Wildcard

  • private.key — приватный ключ (вставлять в первое поле). Ключ вы генерируете сами вначале регистрации сертификата.
  • name_domain.crt — сертификат для вашего домена (вставлять в второе поле).
  • ComodoSSLCA.crt — промежуточный сертификат (вставлять в третье поле).
  • AddTrustExternalCARoot.crt — корневой сертификат (вставлять в четвертое поле).

EssentialSSL

  • private.key — приватный ключ (вставлять в первое поле). Ключ вы генерируете сами вначале регистрации сертификата.
  • name_domain.crt — сертификат для вашего домена (вставлять в второе поле).
  • UTNAddTrustSGCCA.crt — промежуточный сертификат (вставлять в третье поле).
  • ComodoUTNSGCCA.crt — промежуточный сертификат (вставлять в четвертое поле).
  • EssentialSSLCA_2.crt — промежуточный сертификат (вставлять в пятое поле).
  • AddTrustExternalCARoot.crt — корневой сертификат (вставлять в шестое поле).

В uCoz / uWeb ограничение всего на 5 полей, в данной ситуации вам придется написать в техподдержку с панели управления сайтом (предоставить им файлы сертификата) и вам прикрепит сертификат сотрудник техподдержки.

PositiveSSL

  • private.key — приватный ключ (вставлять в первое поле). Ключ вы генерируете сами вначале регистрации сертификата.
  • name_domain.crt — сертификат для вашего домена (вставлять в второе поле).
  • PositiveSSLCA2.crt — промежуточный сертификат (вставлять в третье поле).
  • AddTrustExternalCARoot.crt — корневой сертификат (вставлять в четвертое поле).

Comodo PositiveSSL

  • private.key — приватный ключ (вставлять в первое поле). Ключ вы генерируете сами вначале регистрации сертификата.
  • sitename_com.crt — сертификат для вашего домена (вставлять в второе поле).
  • sitename_com.ca-bundle — промежуточный сертификат (вставлять в третье поле).

Comodo

  • private.key — приватный ключ (вставлять в первое поле). Ключ вы генерируете сами вначале регистрации сертификата.
  • name_domain.crt — сертификат для вашего домена (вставлять в второе поле).
  • COMODORSADomainValidationSecureServerCA — промежуточный сертификат (вставлять в третье поле).
  • COMODORSAAddTrustCA — промежуточный сертификат (вставлять в четвертое поле).
  • AddTrustExternalCARoot — корневой сертификат (вставлять в пятое поле).

Comodo может предоставить файлы сертификата

  • private.key — приватный ключ (вставлять в первое поле). Ключ вы генерируете сами вначале регистрации сертификата.
  • name_domain.crt — сертификат для вашего домена (вставлять в второе поле).
  • SectigoRSADomainValidationSecureServerCA — промежуточный сертификат (вставлять в третье поле).
  • USERTrustRSAAddTrustCA — промежуточный сертификат (вставлять в четвертое поле).
  • AddTrustExternalCARoot — корневой сертификат (вставлять в пятое поле).

Digi Sert может предоставить такие файлы

  • key.txt — приватный ключ (вставлять в первое поле). Ключ вы генерируете сами вначале регистрации сертификата.
  • sitename_ru_2022_10_13.crt — сертификат для вашего домена (вставлять в второе поле).
  • intermediate_pem_thawte_ssl123_1.crt — промежуточный сертификат (вставлять в третье поле).
  • root_pem_thawte_ssl123_1.crt — корневой сертификат (вставлять в четвертое поле).

При установке SSL сертификата, содержимое каждого из файлов нужно копировать вместе с текстом:

---BEGIN CERTIFICATE-----
---END CERTIFICATE-----

то есть не нужно отдельно выбирать что копировать, а что нет. Открыли файл текстовым редактором (блокнотом) Notepad и копируете все содержимое, далее вставляете в нужное поле.

Купить SSL сертификат

Разбираемся в наборах файлов SSL сертификатов

Настройка промежуточных сертификатов в службы IIS (IIS)

  • Статья
  • Чтение занимает 2 мин
  • Участники: 2

Были ли сведения на этой странице полезными?

Да Нет

Хотите оставить дополнительный отзыв?

Отзывы будут отправляться в корпорацию Майкрософт. Нажав кнопку «Отправить», вы разрешаете использовать свой отзыв для улучшения продуктов и служб Майкрософт. Политика конфиденциальности.

Отправить

В этой статье

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

Оригинальная версия продукта:   службы IIS
Исходный номер КБ:   954755

Сводка

Когда клиентский компьютер пытается установить подключений безопасного уровня sockets Layer (SSL) с веб-сервером IIS, он проверяет цепочку сертификатов сервера. Чтобы успешно завершить проверку сертификата, промежуточные сертификаты в цепочке сертификатов сервера должны быть правильно настроены на сервере. В противном случае проверка подлинности сервера может привести к сбойу. Он также применяется к любой программе, использующей SSL или безопасность транспортного слоя (TLS) для проверки подлинности.

Влияние

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

Рекомендуется правильно настроить промежуточные сертификаты на сервере.

Технические подробности

Проверка сертификата X.509 состоит из нескольких этапов, включая обнаружение пути сертификата и проверку пути.

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

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

Цепочка сертификатов настраиваемого сертификата проверки подлинности сервера построена в локальном контексте компьютера. Таким образом, IIS определяет набор сертификатов, которые он отправляет клиентам для TLS/SSL. Чтобы правильно настроить промежуточные сертификаты, добавьте их в промежуточный хранилище сертификатов ЦС в локальной учетной записи компьютера на сервере.

Предположим, что оператор сервера устанавливает сертификат SSL вместе с соответствующими сертификатами ЦС. После обновления сертификата SSL оператор сервера должен обеспечить одновременное обновление промежуточных сертификатов выдачи.

  1. Откройте оснастку Консоли управления сертификатами Microsoft (MMC). Для этого выполните следующие действия:
    1. В командной подсказке введитеMmc.exe.
    2. Если вы не работаете в качестве встроенного администратора, вам будет предложено разрешение на запуск программы. В диалоговом окне Безопасность Windows нажмите кнопку Разрешить.
    3. В меню File выберите Добавить или Удалить привязку.
    4. В диалоговом окне Добавить или Удалить оснастку выберите привязку Сертификаты в списке доступные оснастки. Затем выберите Добавить > ОК.
    5. В диалоговом окне «Сертификаты» выберите учетную запись Computer и выберите Далее.
    6. В диалоговом окне Выберите компьютер выберите Finish.
    7. В диалоговом окне Добавить или Удалить snap-ins выберите ОК.
  2. Чтобы добавить промежуточный сертификат, выполните следующие действия:
    1. В оснастке Сертификаты MMC разйдите сертификаты, щелкните правой кнопкой мыши промежуточные органы сертификации, указать на все задачи, а затем выберите Импорт.
    2. В мастере импорта сертификатов выберите Далее.
    3. На странице Файл импорт введите имя файла сертификата, который необходимо импортировать в поле Имя файла. Нажмите кнопку Далее.
    4. Выберите Далее, а затем выполните мастер импорта сертификатов.

Ссылки

Дополнительные сведения о том, как эта функция создает цепочки сертификатов и проверяет состояние отзыва, посетите сведения о состоянии сертификата устранения неполадок и CryptoAPI отзыве.

Промежуточные intermediate сертификаты CA и их потенциал для неправомерного использования

Google обнаружил, что общедоступные сертификаты TLS / (SSL) были созданы для доменов Google без запроса самого Google. Существование таких сертификатов обычно может быть принято в качестве признака несоответствия выдающим ЦС (т. е. сбой или ошибка ЦС, которая разрешила выдачу сертификата конечного объекта иначе, чем в соответствии с их политикой) или как указание на компромисс выдающего ЦС.

В этом случае проблема была не совсем одной из этих вещей, а вместо этого возникла из-за выдачи неограниченного доверенного промежуточного сертификата ЦС одной частью французского правительства в другую часть. После этого произошло (возможно, непреднамеренное) неправильное использование этого сертификата ЦС для выпуска дополнительного промежуточного сертификата ЦС, который использовался в каком-либо устройстве безопасности для прекращения соединений TLS внутри предприятия, вероятно, для DLP (Data Loss Prevention).

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

Какое правовое использование может быть применимо к устройству, которое находится между конечными пользователями и веб-сайтами или другими интернет-ресурсами, к которым они обращаются, и целью которых является прекращение соединения TLS для чтения (в противном случае зашифрованного) трафика между пользователем и веб-сайтом? В общем случае, когда конечный пользователь находится в общедоступном Интернете, для такого устройства нет законного использования — и, конечно же, успешное развертывание такого устройства потребует компромисса с другими элементами интернет-инфраструктуры, такими как маршрутизация интернет-трафика , разрешение имен доменов (или обоих) в дополнение к доступности либо неограниченного доверенного промежуточного сертификата ЦС, либо доверенных и невостребованных сертификатов конечных объектов (и их соответствующих закрытых ключей) для каждого сайта или ресурса, с которым в противном случае был защищен трафик.

Тем не менее, существует законный рынок для таких устройств, когда он используется в закрытой (обычно корпоративной) среде. Одним из примеров может быть предоставление интернет-подключения к финансовому отделению, в котором есть нормативное требование о том, чтобы дилеры должны были записывать все свои сообщения и где дилеры, использующие сеть, знают о записи и понимают, что у них нет ожидание конфиденциальности при использовании сети дилинговых сетей. Даже здесь важно, чтобы любые меры, принимаемые прибором, не представляли никакого риска для всех за пределами дилижанса, и в этом случае это должно быть достигнуто, если устройство использует сертификаты, которые выдаются не из централизованного доверия, а вместо этого от частного ЦС, которому доверяют только в пределах среды дилинга. Это достижимо с небольшим усилием для большинства закрытых или корпоративных развертываний, чтобы сделать приватный CA «доверенным» в пределах своей собственной области.

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

Централизованно доверенные корневые ЦС не могут выдавать неограниченный промежуточный сертификат ЦС, который будет использоваться в устройстве безопасности, потому что для этого нарушаются базовые требования Форума CA / B (раздел 11.1.1) о том, чтобы гарантировать, что сертификат TLS / SSL никогда не будет выдается без подтверждения от кого-то, кто владеет или контролирует доменное имя.

Существуют и другие причины, по которым корневой ЦС может рассмотреть вопрос о выдаче неконфиденциального промежуточного сертификата ЦС третьей стороне, но независимо от причины, по которой такой сертификат ЦС не может быть выпущен, если эта третье лицо не подвергается такому же уровню аудита, который квалифицировал бы третью сторону быть корневым ЦС в своем собственном праве (раздел 17), а корневой ЦС остается ответственным (раздел 18.3) для действий промежуточного ЦС, включая их соответствие базовым требованиям.

В дополнение к этим запретам в базовых требованиях CA / B Forum, которые включены в качестве ссылок в политику корневой программы большинства основных браузеров, Mozilla (производитель браузера FireFox) попросила все корневые центры сертификации в своей программе добавить заявление в CA CP / CPS, заявляя, что они не выдадут подчиненный (так называемый промежуточный) сертификат, который может использоваться для MITM или «управление трафиком» доменных имен или IP-адресов, которые владелец сертификата не имеет законного права собственности или контроля.

Все доверенные корневые центры сертификации проверяются, чтобы продемонстрировать их соответствие исходным требованиям Форума CA / B. Ни один из членов Совета безопасности CA не предоставил независимые промежуточные центры сертификации из доверенных корней предприятиям (или кому-либо еще!) Для этой цели, и все члены Совета безопасности CA соблюдали требования к корневой программе с момента их появления. 

Разница между корневыми сертификатами и промежуточными сертификатами

Этот SSL-сертификат конечного пользователя является лишь частью цепочки сертификатов.

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

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

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

Итак, без лишних слов, давайте разберемся.

Что такое корневая программа?

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

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

  • Microsoft
  • Apple
  • Google
  • Mozilla

Пользователи Apple, как macOS, так и iOS, полагаются на корневой магазин Apple, а также пользователи Microsoft и его корневой магазин. Android использует Google. А набор продуктов Mozilla использует собственное корневое хранилище.

Корневые программы работают в соответствии с очень строгими правилами. В дополнение к правилам и ограничениям, установленным базовыми требованиями CA/B Forum, некоторые корневые программы, например Mozilla, добавляют еще более строгие требования.

Причина этого проста: доверие.

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

В этом смысле было бы полезно рассматривать доверие в двух конкретных контекстах:

  • Social Trust
  • Technical Trust

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

Как правило, эти вещи довольно просты, обычно ЦС уже выпускает промежуточное звено с перекрестной подписью (мы вернемся к этому через секунду) и ведет свой собственный ЦС в течение определенного периода времени, прежде чем подавать заявку на доверенность своего корня.Или, другими словами, вы не можете просто сформировать ЦС и сразу же подать заявку на доверенность корневого каталога. И обсуждения иногда могут иметь политический уклон, как мы видели в дебатах CA DarkMatter несколько месяцев назад.

Несмотря на это, после того, как CA приняла свое приложение и доказала свою надежность, его корни добавляются в корневое хранилище.

Что такое доверенный корневой сертификат?

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

Во-первых, в то время как сертификаты конечного пользователя или конечные SSL-сертификаты (и, как правило, любой вид общедоступного доверенного сертификата PKI) имеют срок службы два года — максимум — корневые сертификаты живут намного, намного дольше. Вот один из корней EV DigiCert, взгляните на его срок действия:

.

Теперь, как вы, вероятно, уже догадались, каждый ЦС имеет более одного корня. На самом деле, у большинства ЦС их несколько. Вот краткий обзор корневого хранилища на моем компьютере:

.

Обычно разные корни будут иметь разные атрибуты.Это, вероятно, лучше всего иллюстрируется двумя корнями COMODO (теперь Sectigo) в верхней части этого списка. Один для создания подписей RSA, а другой для подписей ECDSA.

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

Что такое цепочка сертификатов?

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

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

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

Теперь, когда браузер видит SSL-сертификат, он видит, что сертификат был выпущен одним из доверенных корней в его корневом хранилище (точнее, подписан закрытым ключом корня).Поскольку он доверяет корню, он доверяет любому сертификату, подписанному корнем.

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

Как указано выше, центры сертификации не выдают серверные/конечные сертификаты (сертификаты SSL конечного пользователя) непосредственно из своих корней. Эти корни слишком ценны и слишком велик риск.

Итак, чтобы изолировать себя, центры сертификации обычно выдают так называемый промежуточный корень.ЦС подписывает промежуточный корень своим закрытым ключом, что делает его доверенным. Затем ЦС использует закрытый ключ промежуточного сертификата для подписи и выпуска SSL-сертификатов конечных пользователей. Этот процесс может повторяться несколько раз, когда промежуточный корень подписывает другой промежуточный продукт, а затем ЦС использует его для подписи сертификата. Эти ссылки, от корневого до промежуточного и листового, представляют собой цепочку сертификатов.

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

Возможно, вы заметили, что иногда, когда ваш ЦС выдает SSL-сертификат, он также отправляет промежуточный сертификат, который вам также необходимо установить. Это делается для того, чтобы браузеры могли завершить цепочку сертификатов и связать сертификат SSL на вашем сервере с одним из его корней.

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

Какую роль играет цифровая подпись?

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

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

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

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

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

Вот практический пример: Google и другие браузеры недавно не доверяли сертификатам SSL торговой марки Symantec CA. На первый взгляд может показаться, что это монументальная задача — не доверять миллионам SSL-сертификатов конечных пользователей. На самом деле все было очень просто. Они только что удалили все корни Symantec CA из своих доверенных хранилищ. Теперь любой сертификат, который должен связываться с этими корнями, терпит неудачу и ему не доверяют. (Стоит отметить, что DigiCert хорошо очистил Symantec, но это служит хорошим примером из реальной жизни для нашего обсуждения.)

В чем разница между связанным корнем и одиночным корнем?

На самом деле это ответ на наш последний вопрос. Один корень принадлежит ЦС. Он может выдавать сертификат напрямую, что значительно упрощает развертывание сертификатов и упрощает установку. Связанный корень — это то, что Sub CA использует для выпуска сертификатов. Это промежуточный сертификат, но, поскольку дополнительный ЦС не имеет собственного доверенного корня, он должен связываться со сторонним ЦС, у которого он есть.

Это тоже имеет значение. Вот почему:

  • Сцепленные корни усложняют установку, поскольку промежуточный корень необходимо будет загружать на каждый сервер и приложение, на котором размещается сертификат.
  • Связанные корни находятся во власти ЦС, к которому они привязаны. У них нет контроля над корнем, поэтому, если корневой ЦС обанкротится, им конец.
  • Срок действия корневых и промежуточных сертификатов также истекает. Хоть и на более длительных сроках.Тем не менее срок действия промежуточного продукта должен истечь раньше, чем его корень, что усложняет процесс.

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

Но когда кто-то говорит об PKI, он имеет в виду именно это. Имея это в виду, вы, вероятно, сможете понять, как частный ЦС и самозаверяющие сертификаты развертываются в контексте предприятия.Работая вместе с доверенным центром сертификации, организация создает корневой сертификат (сертификаты) и закрытый ключ (это называется церемонией выдачи ключей). Затем организация добавляет корень в свои собственные корневые хранилища во всех своих системах и устройствах. И с этого момента организация может самостоятельно подписывать свои собственные сертификаты X.509, используя закрытый ключ из своих собственных корней, и они будут доверенными в своей сети.

Как всегда, оставляйте любые комментарии или вопросы ниже…

Разница между корневыми и промежуточными сертификатами

Что такое цепочки сертификатов?

Цепочка сертификатов — это список сертификатов (обычно начинающийся с сертификата конечного объекта), за которыми следуют один или несколько сертификатов CA (обычно последний является самозаверяющим сертификатом) со следующими свойствами:

  • Эмитент каждого сертификата (кроме последнего) соответствует субъекту следующего сертификата в списке.
  • Каждый сертификат (кроме последнего) должен быть подписан секретным ключом, соответствующим следующему сертификату в цепочке (т.е. подпись одного сертификата может быть проверена с помощью открытого ключа, содержащегося в следующем сертификате).
  • Последний сертификат в списке — это якорь доверия: сертификат, которому вы доверяете, потому что он был доставлен вам с помощью какой-то заслуживающей доверия процедуры. Якорь доверия — это сертификат ЦС (или, точнее, открытый ключ проверки ЦС), используемый проверяющей стороной в качестве отправной точки для проверки пути.

В RFC 5280 цепочка сертификатов или цепочка доверия определяется как «путь сертификации». Другими словами, цепочка доверия относится к вашему SSL-сертификату и тому, как он связан с доверенным центром сертификации. Чтобы SSL-сертификат был доверенным, его необходимо отследить до корня доверия, с которого он был подписан, а это означает, что все сертификаты в цепочке — серверный, промежуточный и корневой — должны быть должным образом доверенными. Цепочка доверия состоит из трех частей:


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

Цепочки сертификатов используются для проверки того, что открытый ключ и другие данные, содержащиеся в сертификате конечного объекта (первом сертификате в цепочке), действительно принадлежат его субъекту. Чтобы убедиться в этом, подпись конечного целевого сертификата проверяется с использованием открытого ключа, содержащегося в следующем сертификате, чья подпись проверяется с использованием следующего сертификата, и так далее, пока не будет достигнут последний сертификат в цепочке.Поскольку последний сертификат является якорем доверия, его успешное получение докажет, что сертификату конечного объекта можно доверять.

Корневые сертификаты

Корневой сертификат, часто называемый доверенным корневым, находится в центре модели доверия, которая защищает инфраструктуру открытых ключей (PKI).

Каждое устройство имеет так называемое корневое хранилище. Корневое хранилище — это набор предварительно загруженных корневых сертификатов вместе с их открытыми ключами, которые находятся на устройстве.Устройства используют либо корневое хранилище, встроенное в их операционную систему, либо стороннее корневое хранилище через приложение, такое как веб-браузер. Корневые хранилища являются частью корневых программ, таких как Microsoft, Apple, Google и Mozilla. Пользователи Microsoft используют корневое хранилище Microsoft и так далее.

Корневые программы работают в соответствии с очень строгими правилами. В дополнение к правилам и ограничениям, установленным базовыми требованиями CA/B Forum, некоторые корневые программы, например Mozilla, добавляют еще более строгие требования.

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

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

Доверенный корневой сертификат — это особый вид цифрового сертификата X.509, который можно использовать для выдачи других сертификатов.В то время как срок действия любых сертификатов TLS/SSL конечного пользователя составляет максимум два года (скоро будет 1 год), корневые сертификаты действительны гораздо дольше. Например, корневой сертификат DigiCert (доверенного центра сертификации) действителен в течение 25 лет.

Кроме того, каждый доверенный ЦС имеет несколько корневых сертификатов, каждый из которых имеет разные атрибуты. Это видно в корневом хранилище.

 

На приведенном выше изображении есть два корневых сертификата, выпущенных COMODO (теперь Sectigo) CA.Один предназначен для создания подписей RSA, а другой — для подписей ECDSA.
 

В ОС Windows, если вы просматриваете хранилище сертификатов, вы увидите все сертификаты корневого центра сертификации в доверенных корневых центрах сертификации. По умолчанию сюда входит список общедоступных корневых ЦС, которые устанавливаются вместе с Windows и периодически обновляются через Центр обновлений Windows.

Все сертификаты ниже корневого сертификата доверяют корневому сертификату, и открытый ключ корневого сертификата используется для подписи других сертификатов.Многие программные приложения наследуют надежность этого корневого сертификата, например, браузеры проверяют соединения SSL/TLS на основе надежности корневого сертификата. Из-за ценности этих корневых сертификатов и рисков, связанных с их компрометацией, они редко используются для выдачи сертификатов конечных объектов. Вместо этого мы используем промежуточные сертификаты.

Промежуточные сертификаты

В связи с увеличением ответственности за PKI количество корневых центров сертификации было реплицировано.С другой стороны, нецелесообразно иметь много корневых ЦС, поскольку это может привести к мошенничеству и проблемам с управлением. Чтобы решить эту проблему, была введена концепция промежуточного центра сертификации. Корневые центры сертификации делегировали свои задачи промежуточным центрам сертификации. В результате может быть более одного промежуточного ЦС. Промежуточный сертификат работает как замена корневого сертификата, потому что корневой сертификат имеет свои собственные уровни безопасности, гарантирующие, что его ключи останутся недоступными.Промежуточный сертификат воспроизводит «цепочку доверия» между сертификатом конечного объекта и корневым сертификатом.

Вот как это работает. Корневой ЦС подписывает промежуточный корень своим закрытым ключом, что делает его доверенным. Затем ЦС использует закрытый ключ промежуточного сертификата для подписи и выпуска SSL-сертификатов конечных пользователей. Этот процесс может повторяться несколько раз, когда промежуточный корень подписывает другой промежуточный узел и, наконец, подписывает сертификат конечного объекта. Эти ссылки от корневого до промежуточного и конечного объектов представляют собой цепочку сертификатов.

Мы можем отличить корневой сертификат от промежуточного, взглянув на сам сертификат. Если поля «Кому выдан» и «Кем выдан» совпадают, то это корневой сертификат, в противном случае — промежуточный. Другой идентификацией будет просмотр пути сертификации. Сертификация, которая отображается в верхней части списка, является корневым сертификатом. Ниже приведен пример одного из общедоступных корневых ЦС:

.


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

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

Связанные посты

Корневой сертификат

против промежуточных сертификатов

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

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

Итак, не откладывая, давайте приступим к делу.

Если вы устанавливаете сертификат SSL/TLS самостоятельно, и вы впервые, то не новость, что вы можете на мгновение удивиться, помимо процесса установки, в основном потому, что папка ZIP-архива который вы получаете по электронной почте от ЦС, состоит из разных файлов SSL.

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

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

Разница между корневыми сертификатами и промежуточными сертификатами — ключевой фактор

Хотя одного корневого сертификата достаточно для обеспечения безопасности SSL, на практике большинство ЦС используют промежуточные сертификаты. Это связано с практическими соображениями, связанными с получением основных квалификаций, необходимых для выдачи CA.

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

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

После того, как ЦС получит необходимую проверку и будет признан заслуживающим доверия для выпуска собственных корневых сертификатов, он заменит якорь доверия своими собственными корневыми сертификатами.И соответствующие корни будут добавлены в хранилище корней.

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

Еще несколько причин, по которым используются промежуточные сертификаты, перечислены ниже 

.
  • Промежуточные сертификаты помогают контролировать количество используемых корневых сертификатов и снижают риски безопасности и мошенничество.Поскольку все больше и больше пользователей внедряют SSL-сайты, число корневых ЦС также будет увеличиваться. Но наличие слишком большого количества корневых ЦС может привести к серьезным последствиям для безопасности, которые призваны устранить промежуточные сертификаты. Они предоставляют корневым центрам сертификации возможность делегировать некоторые обязанности по выдаче сертификатов промежуточным центрам сертификации, предоставляя промежуточные сертификаты, которые заменят корневой сертификат.
  • Промежуточные сертификаты можно реплицировать в большом количестве, не нарушая структуру безопасности и помогая установить цепочку доверия.
  • Они помогают с масштабируемой реализацией сети SSL.


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

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

Что такое цепочка сертификатов SSL?

Существует два типа центров сертификации (ЦС): корневых ЦС и промежуточных ЦС . Чтобы SSL-сертификат считался доверенным, этот сертификат должен быть выдан ЦС, включенным в доверенное хранилище устройства, которое подключается .

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

Список сертификатов SSL, от корневого сертификата до сертификата конечного пользователя, представляет цепочку сертификатов SSL .

Пример цепочки сертификатов SSL

В качестве примера предположим, что вы приобрели сертификат от Awesome Authority для примера домена .круто .

Awesome Authority не является корневым центром сертификации. Его сертификат не встроен напрямую в ваш веб-браузер, поэтому ему нельзя явно доверять.

  • Awesome Authority использует сертификат, выданный Intermediate Awesome CA Alpha .
  • Intermediate Awesome CA Alpha использует сертификат, выданный Intermediate Awesome CA Beta .
  • Intermediate Awesome CA Beta использует сертификат, выданный Intermediate Awesome CA Gamma .
  • Intermediate Awesome CA Gamma использует сертификат, выданный The King of Awesomeness .
  • The King of Awesomeness — это корневой ЦС. Его сертификат встроен непосредственно в ваш веб-браузер, поэтому ему можно явно доверять.

В нашем примере цепочка сертификатов SSL представлена ​​6 сертификатами:

  1. Сертификат конечного пользователя — выдан на: example.com; Выдано: Awesome Authority
  2. Промежуточный сертификат 1 — выдан: Awesome Authority; Выдано: Intermediate Awesome CA Alpha
  3. Intermediate Certificate 2 — Выдан: Intermediate Awesome CA Alpha; Выпущено: Intermediate Awesome CA Beta
  4. Промежуточный сертификат 3 — выдан для: промежуточного уровня Awesome CA Beta; Выпущено: Intermediate Awesome CA Gamma
  5. Intermediate Certificate 4 — Выдан: Intermediate Awesome CA Gamma; Выдал: Король удивительности
  6. Корневой сертификат — Выдан и для: The King of Awesomeness

Сертификат 1, который вы приобретаете в ЦС, является вашим сертификатом конечного пользователя .Сертификаты со 2 по 5 являются промежуточными сертификатами . Сертификат 6, тот, что находится в верхней части цепочки (или в конце, в зависимости от того, как вы читаете цепочку), является корневым сертификатом .

Когда вы устанавливаете свой сертификат конечного пользователя для example.awesome , вы должны связать все промежуточные сертификаты и установить их вместе с вашим сертификатом конечного пользователя. Если цепочка SSL-сертификатов недействительна или повреждена, некоторые устройства не будут доверять вашему сертификату.

Часто задаваемые вопросы

  1. Должен ли я устанавливать корневой сертификат на свой сервер?

    Нет. Корневой сертификат обычно встроен в подключенное устройство. В случае веб-браузеров корневые сертификаты упаковываются вместе с программным обеспечением браузера.

  2. Как установить промежуточные сертификаты SSL?

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

    Например, Apache требует, чтобы вы связали промежуточные сертификаты SSL и назначили расположение пакета для конфигурации SSLCertificateChainFile . Однако NGINX требует, чтобы вы упаковали промежуточные SSL-сертификаты в один пакет с сертификатом конечного пользователя.

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

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

  3. Что произойдет, если я не установлю промежуточный сертификат SSL?

    Если вы не установите один или несколько промежуточных SSL-сертификатов, вы разорвете цепочку сертификатов. Это означает, что вы создаете разрыв между конкретным (конечным пользователем или промежуточным) сертификатом и его эмитентом.Когда устройство не может найти доверенного издателя для сертификата, сертификат и вся цепочка, от промежуточного сертификата до окончательного сертификата, не могут быть доверенными.

    В результате ваш окончательный сертификат не будет доверенным. Веб-браузеры будут отображать ошибку «Неверный сертификат» или «Сертификат не доверенный».

  4. Как сократить цепочку SSL-сертификатов в браузере?

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

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

корневых и промежуточных сертификатов — в чем разница?

На первый взгляд SSL-сертификат кажется простым. Вы устанавливаете его на свой сервер для защиты конфиденциальных данных ваших посетителей, и он работает безупречно до истечения срока действия.Большинство владельцев веб-сайтов редко углубляются в технические аспекты SSL/TLS. Они позволяют профессионалам заниматься настройкой и обновлением сертификатов. Многих даже не волнует разница между корневыми сертификатами и промежуточными сертификатами, но если вы хотите установить свой сертификат самостоятельно, вы должны знать механизм, стоящий за ним.

Доверительная цепочка SSL

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

Один из них — это сертификат сервера, выданный специально для вашего домена, а другой — промежуточный сертификат, который связывает сертификат вашего сервера с корневым сертификатом ЦС. Все вместе они образуют цепочку доверия SSL — упорядоченный список сертификатов, которые позволяют получателю (веб-браузеру) проверить надежность отправителя (вашего защищенного сервера) и ЦС. Если один компонент в цепочке отсутствует, браузеры не будут доверять SSL-сертификату сервера и выдадут предупреждение HTTPS.

Подождите, что? Сертификаты сервера, промежуточные сертификаты, корневые сертификаты, цепочка доверия — всего этого слишком много для новичков. Если вы один из них, не волнуйтесь, в этой статье мы объясним разницу между корневыми сертификатами и промежуточными сертификатами и почему они имеют решающее значение для работы SSL/TLS. Но сначала вернемся к цепи ржавчины и посмотрим на картину в целом.

На изображении ниже показано, как функционирует цепочка доверия:

Изображение предоставлено: Yanpas — CC BY-SA 4.0

Вы также можете проверить доверие цепочки SSL, щелкнув замок любого веб-сайта и выбрав вкладку Certification Path. Если вы посмотрите на путь сертификации SSL Dragon, вы увидите сверху вниз корневой сертификат, промежуточный сертификат и сертификат сервера (SSL Dragon использует сертификат Cloudflare SSL как часть службы CDN).

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

Что такое корневой сертификат SSL?

Корневой сертификат SSL находится на вершине иерархии доверия и является основой инфраструктуры открытых ключей.Корневые SSL-сертификаты подписываются доверенными центрами сертификации. Кто решает, какой ЦС заслуживает доверия? Короче говоря, браузеры и приложения, потому что все они включают корневое хранилище в свой установочный пакет.

Корневое хранилище — это список предварительно загруженных доверенных корневых сертификатов из различных ЦС. Например, если корневой сертификат ЦС не включен в корневое хранилище Google, Chrome пометит веб-сайт, использующий указанный ЦС, как небезопасный. Вы можете узнать больше о центрах сертификации и о том, кто их регулирует, в этой обширной статье.

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

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

В отличие от коммерческих сертификатов, корневые сертификаты имеют гораздо более длительный срок службы. Вот срок действия Sectigo (ранее Comodo CA) ECC . Как видите, срок его действия истекает в далеком 2038 году.

 

Что такое промежуточный SSL-сертификат?

Выдача SSL-сертификата конечному пользователю непосредственно из корневого сертификата слишком опасна.Корни очень ценны. Чтобы дополнительно обезопасить себя, ЦС придумали еще один уровень безопасности — промежуточный сертификат.

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

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

Заключительные слова

Надеюсь, теперь у вас есть полное представление о том, что на самом деле делает цифровой сертификат таким безопасным. Поняв, в чем разница между корневыми сертификатами и промежуточными сертификатами, вы решили загадку SSL/TLS.Цепочка доверия SSL — одна из причин повсеместного распространения и эффективности SSL-сертификатов. Другой — это высококлассное шифрование, которое не может взломать даже самый умный хакер.

Корневые сертификаты и промежуточные сертификаты и центры сертификации

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

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

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

Однако многие организации часто чувствуют себя перегруженными задачей, связанной с внедрением сертификатов, и в конечном итоге избегают этой задачи. Чтобы упростить сертификаты, в этой статье будут рассмотрены основы корневых и промежуточных сертификатов, центров сертификации (ЦС) и почему сертификаты SSL/TLS широко используются для просмотра веб-страниц.

Сертификаты клиента и сервера

Прежде чем мы перейдем к корневым и промежуточным ЦС и сертификатам, давайте рассмотрим разницу между сертификатом клиента и сертификатом сервера или SSL.Это довольно просто, так как сертификат клиента подтверждает подлинность устройства конечного пользователя, а сертификат сервера подтверждает подлинность сервера.

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

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

Например, если мы ищем в Википедии, доменное имя «www.wikipedia.com» имеет сертификат SSL/TLS, который ваш веб-браузер может использовать для подтверждения того, что вы подключаетесь к странице Википедии, а не где-либо еще. Зная, кому назначены сертификаты, мы можем понять, какие типы сертификатов существуют и как они генерируются.

Что такое цепочки доверия сертификатов?

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

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

Что такое корневой сертификат?

Цепочка доверия начинается с сертификата, выданного центром сертификации или ЦС, этот первый сертификат называется корневым сертификатом.

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

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

Что такое корневое хранилище?

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

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

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

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

Что такое промежуточный сертификат?

ЦС

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

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

Корневой и промежуточный ЦС

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

Интересный вопрос, как устанавливается доверие между разными ЦС? Доверие предоставляется именно потому, что существуют корневые центры сертификации, а личность всех объектов известна по специальному соглашению в интернет-сообществе. В таком случае это первый шаг к доверию.Затем центры сертификации можно разделить на две категории: корневые центры сертификации и промежуточные центры сертификации.

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

Как веб-браузеры аутентифицируют сертификаты SSL/TLS?

Все веб-браузеры имеют собственный список доверенных корней, которые прошли критерии включения. Когда веб-браузер подключается к веб-странице, веб-страница отправляет свой сертификат SSL/TLS, который затем проверяет браузер.

Вот общий обзор того, что проверяет браузер:

  1. Веб-браузер проверяет целостность сертификата с помощью цифровой подписи, подтверждая подлинность сервера.
  2. Затем веб-браузер проверяет срок действия сертификата, чтобы убедиться, что сертификат все еще активен.
  3. Веб-браузер проверяет, был ли сертификат отозван до истечения срока его действия. Центры сертификации поддерживают список отозванных сертификатов, удачно названный списком отзыва сертификатов (CRL).

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

Как центры сертификации подписывают сертификаты?

Прежде чем ЦС сможет подписать сертификат, клиент должен сгенерировать пару открытого и закрытого ключей и запрос на подпись сертификата (CSR). Вот подробное руководство по созданию пар ключей, а вот — по CSR. CSR содержит открытый ключ и информацию о пользователе, которые затем будут отправлены в ЦС.

Центр сертификации проверит информацию о пользователе и подпишет сертификат своим закрытым ключом, установив доверие. Теперь клиент может импортировать свой подписанный сертификат на сервер.

Центры сертификации и сертификаты обеспечивают надежную сетевую безопасность

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

Leave a Reply