Построение небольшого центра сертификации на основе OpenSSL
Разговор о центре сертификации логично начать с PKI — инфраструктуры открытых ключей. Находим определение в Википедии: «PKI — набор средств (технических, материальных, людских и т. д.), распределённых служб и компонентов, в совокупности используемых для поддержки криптозадач на основе закрытого и открытого ключей». Так что к PKI стоит относиться именно как к инфраструктуре, в состав которой входят те или иные компоненты.
По сути, PKI представляет собой систему, которая используется для создания, хранения и распределения цифровых сертификатов. Они, в свою очередь, должны максимально защищённым образом удостоверять, что определённый публичный ключ принадлежит той или иной сущности.
В качестве сущности может выступать пользователь, устройство или что угодно ещё, что можно ассоциировать с тем или иным ключом (процесс, программа, производитель и т. д.). Вот примеры задач, для которых обычно используется PKI:
- создание сертификатов для привязки публичного ключа к сущности;
- безопасное хранение сертификатов в репозитории (англ. repository — хранилище);
- отзыв сертификата (отметка, что сертификату нельзя доверять).
В систему PKI обычно входят:
- Центр сертификации (англ. Certificate Authority (CA)), которому будет посвящена основная часть этой статьи. Он непосредственно работает с сертификатом — выписывает, хранит, проверяет подлинность. Центр сертификации не следует путать с удостоверяющим центром. Также отдельно рассматривается «корневой центр сертификации» — сторона, чья честность неоспорима, а открытый ключ широко известен.
- Регистрационный центр (англ. Registration Authority (RA)). Согласно Википедии, «удостоверяющий центр доверяет регистрационному проверку информации о субъекте». Поэтому часто регистрационный центр полностью или частично объединяют с CA.
- Сертификат (англ. Certificate) — публичный ключ и идентификаторы сущности, имеющие подпись центра сертификации. В качестве идентификатора может выступать электронная почта пользователя. Если ЦС подписывает набор данных, который состоит из имени пользователя, его публичного ключа и электронной почты, то он как бы гарантирует, что эти данные подлинные. Далее под термином «сертификат» мы будем понимать сертификат стандарта X.509.
- Certificate Signing Request (CSR). По сути это запрос на подпись сертификата. В запросе обычно указывается сущность, её параметры и публичный ключ.
- Certificate Revocation List (CRL), он же список отзывов, или отозванных сертификатов. По этому списку ЦС ведёт учёт «плохих» сертификатов. И если такой сертификат используется, то ЦС не подтвердит к нему доверие. Чаще всего причина — утрата ключей сертификата.
Для базового понимания структуры PKI этого списка достаточно. Теперь рассмотрим, как всё это применяется.
Центры сертификации: как они используются
Задача центра сертификации — подтверждать подлинность ключей шифрования с помощью сертификатов электронной подписи. Логику работы ЦС, как правило, можно описать тезисом «никто не доверяет друг другу, но все доверяют ЦС».
Допустим, условная сущность Аlice имеет сертификат, подписанный ЦС Comp, а сущность Bob пытается проверить подлинность этого сертификата. Проверка будет успешной, если Bob и Alice доверяют одному и тому же ЦС. Для решения такой проблемы в ОС Alice и ОС Bob установлено множество сертификатов различных ЦС.
Установив сертификат ЦС в систему, можно доверять тем сертификатам, которые он подписал. Если сертификат (в частности для HTTPS) выдан, но не подписан каким-нибудь доверенным ЦС, то его называют самоподписанным и он считается недоверенным — если, конечно, не заставить систему доверять такому сертификату.
Здесь могут возникать разные ошибки. Протестировать реакцию браузера на нарушения в работе SSL можно на сайте badssl.com.
Рассмотрим, как браузер реагирует на разные сертификаты. У Firefox, например, для идентификации есть такой набор сертификатов ЦС:
Вот пример с HTTPS. Есть ресурс www.geekbrains.ru, соединение с которым браузер считает доверенным:
Если открыть подробности, то можно увидеть почему:
Браузер считает подключение доверенным потому, что сертификат HTTPS подписан ЦС Comodo CA. Эта организация своим сертификатом подтверждает, что сертификату, выданному для сайта GeekBrains, можно доверять. Получается примерно такая схема:
- браузер доверяет организации Comodo CA;
- браузер открывает сайт GeekBrains и видит там сертификат HTTPS, подписанный Comodo CA;
- браузер считает, что если организация, которой он доверяет, уверена в сайте GeekBrains (они же подтвердили их сертификат), то такое соединение для конечного пользователя можно считать доверенным.
Если коротко, то для успешной проверки доверия (в рамках HTTPS) с использованием центра сертификации необходимо, чтобы:
- в системе были соответствующие корневые сертификаты ЦС, которые будут использоваться для подтверждения сертификата конкретного сайта;
- у выданных для сайтов сертификатов не было ошибок.
Не вдаваясь в подробности, отметим, что ошибки могут быть разными. К примеру, если в браузере будет отсутствовать сертификат, который подтверждает подлинность сертификата HTTPS, то соединение автоматически пометится как недоверенное:
Если открыть дополнительные сведения (что я всегда советую делать), то можно подробнее узнать о проблеме. Здесь видно, что на сайте установлен самоподписанный сертификат, то есть не подписанный каким-либо другим сертификатам. Его подлинность нельзя проверить, и соединение считается недоверенным.
Другой пример — сайт wrong.host.badssl.com. Сертификат выдан для другого хоста, о чём и уведомляет браузер:
А вот пример для сайта, у которого истёк срок действия сертификата:
Как проверяется доверие на практике?
Для каждого сертификата в соответствии с его назначением определяется хранилище в системе — туда его можно установить вручную. Например, есть хранилище доверенных сертификатов: если поместить в него сертификат, то система будет доверять ему.
В Windows сертификаты можно просмотреть через оснастку certmgr.msc:
Если поместить сертификат в хранилище «Доверенные корневые центры сертификации», то такому центру система будет доверять. А поскольку это хранилище корневых центров сертификации, система потом будет доверять и всем объектам, которые подписаны этим сертификатом.
В ОС Ubuntu Linux сертификаты хранятся в каталоге /etc/ssl/cetrs. Причём часть из них — ссылки на другой объект:
Разворачиваем собственный ЦС
Чтобы лучше понять все процессы, лежащие в основе PKI, рассмотрим на практике развёртывание небольшого ЦС на виртуальной машине под управлением Ubuntu 18 (без выхода в глобальную сеть). Мы не будем жёстко придерживаться правил и стандартов выдачи сертификатов — просто разберём работу с ними.
С учетом того, что. все эксперименты мы проводим в виртуальной среде (без выхода в глобальную сеть), мы можем использовать любое доменное имя — например www.simple.org. Однако надо помнить, что в глобальной сети такое имя вполне может быть зарегистрировано за каким-нибудь сайтом.
Допустим, нам надо настроить веб-сервер так, чтобы соединение к нему шло по протоколу HTTPS и сервер заодно проверял клиента по сертификату. Пользователь у нас один, веб-сервер на Apache 2. Схема нашего центра сертификации будет такой:
Начальные настройки
Сперва заполним файл /root/.rnd, который используется как источник начальных случайных значений в генераторе псевдослучайных чисел OpenSSL. Суть использования этого файла описана на сайте OpenSSL. Нам надо заполнить свой файл случайными данными, как вариант — скопировав из /dev/urandom 32768 байт в файл .rnd таким образом:
Далее создадим сертификат для CA:
Опции для сертификата берутся из файла /etc/ssl/openssl.cnf. Сам файл довольно большой, мы не будем приводить здесь его содержимое. В реальности стоит создать свой конфигурационный файл с необходимыми опциями и блоками — и использовать его для генерации сертификатов.
На выходе получим два файла: ключ и сертификат.
Оба файла надо беречь. Если они попадут к злоумышленнику, он сможет использовать их для генерации сертификатов. Посмотреть сертификат можно при помощи этой команды (вывод обрезан для краткости):
Далее на основе полученного сертификата (напомним, что это сертификат корневого CA) можно сгенерировать сертификат для сервера. Вначале генерируем закрытый ключ для сервера:
Теперь используем этот ключ для генерации запроса на выдачу сертификата (CSR):
Отметим, что данные, которые вы вводите в поля, должны совпадать со значениями в тех полях, что указывались при создании сертификата корневого сервера. Теперь возьмём корневой сертификат CA и запрос — и сгенерируем на их основе сертификат для сервера:
Должно получиться 5 файлов.
Файл server.req можно удалить — а при необходимости создать заново. Теперь надо перенастроить веб-сервер для работы с сертификатами.
Настройка Apache 2 для использования сертификатов
Переходим в каталог /etc/apache2:
Создаём каталог для хранения сертификатов:
Включаем модуль SSL для веб-сервера. Тестирование проводилось на ОС Ubuntu Linux, поэтому модуль достаточно просто включить:
Аналогично нужно включить поддержку заголовков:
Теперь создадим конфигурационный файл для модуля SSL. Пример содержимого для него можно взять на Syslink.pl. Команды такие:
Сам файл будет содержать следующие параметры (чтобы было проще работать, мы отключили заголовки Strict-Transport-Securrity, X-Frame-Options и X-Content-Type-Options):
Далее созданный конфиг надо активировать:
Теперь переходим в каталог /etc/apache2/sites-available:
И делаем на всякий случай резервные копии всех хранящихся там файлов:
Теперь ещё раз проверяем подключённые модули headers и SSL:
Далее нам надо перенести созданные сертификаты (сертификат CA и сертификат сервера) в каталог /etc/ssl/certs, а ключ сертификата сервера — в каталог /etc/ssl/private:
Далее откроем конфиг сайта (/etc/apache2/sites-available/000-default-ssl.conf) и добавим туда следующие опции:
Теперь перезагружаем веб-сервер:
Проверяем доступность сайта:
Видим, что Firefox не может проверить сертификат сайта. Чтобы смог, надо импортировать цепочку сертификатов, подтверждающих сертификат сервера, в список доверенных. Создадим цепочку:
У полученного файла не забываем сменить атрибуты на 555:
Теперь откроем в браузере менеджер сертификатов и импортируем полученную цепочку (кнопка Import):
Далее можно просмотреть сертификаты и настроить доверие — вдруг что-то упущено:
Когда сертификаты добавлены в список доверенных, можно снова зайти на сайт и увидеть, что соединение помечается как доверенное:
Сейчас время настроить аутентификацию для клиентов.
Настройка аутентификации клиентов
Веб-сервер Apache поддерживает аутентификацию клиента. Это значит, что мы можем выписать клиенту сертификат SSL, а сервер сможет его проверить. Если у пользователя не будет сертификата — аутентификация не пройдёт. Для активации такой возможности надо добавить в конфиг default-ssl.conf такие опции:
После этого к сайту сможет подключиться только тот пользователь, сертификат которого:
- установлен в браузере, если клиентом является браузер, — тогда сертификат будет предъявлен при подключении к серверу;
- подписан сертификатом доверенного УЦ.
Сначала сгенерируем сертификат для клиента. Первым делом создаём ключ:
Затем на основе ключа сгенерируем CSR:
Теперь на базе запроса сгенерируем сам сертификат:
И импортируем сертификат в формате p12:
В итоге у нас должен получиться файл client.p12. Нужно поменять права на файл, иначе сертификат не импортируется:
Теперь можно импортировать его в браузер по аналогии с корневыми сертификатами:
После импорта должно получиться примерно так:
После этого перезапускаем веб-сервер и возвращаемся на сайт. Видим окно выбора сертификата того пользователя, которого мы импортировали в браузер:
После выбора сертификата пользователя можно успешно зайти на сайт:
В этой статье мы рассмотрели сборку простейшего ЦС. Его сертификат мы использовали для подтверждения других сертификатов, обеспечив таким образом доверие между всеми участниками. Но в собранной нами системе есть пара существенных недостатков:
- если пользователей будет больше одного, то мы столкнёмся с проблемами при учёте выдаваемых сертификатов;
- при настройке ЦС стоит грамотно выбирать параметры для используемых сертификатов, а для этого нужен свой конфигурационный файл.
Но если необходимо обеспечить защиту информации в пределах локальной сети, то подобный ЦС будет интересным и грамотным решением.
Напоследок предлагаю ряд полезных материалов для изучения:
Источники, которые использовались при подготовке статьи:
Хотите в подробностях изучить работу центров сертификации и другие вопросы информационной безопасности? Тогда приглашаем вас на факультет GeekUniversity!
Про PKI «на пальцах» за 10 минут
Предложил коллегам провести внутреннюю мини-лекцию по сабжу — идея зашла. Сел писать план лекции и… чот психанул — в итоге очнулся, дописывая небольшой гайд. Подумал, что будет полезно добавить сюда что-то для быстрого понимания, что такое PKI, зачем она нужна и как работает, так как пока готовился, чтобы освежить память, искал информацию в том числе на полюбившемся «Хабрахабре», но статей в таком формате не нашел.
Пишу на примере наших повседневных задач, которые знакомы многим: беспарольный доступ к серверам OpenVPN и защита доступа к ресурсам с помощью HTTPS.
Без теории не обойтись
PKI (Public Key Infrastructure, инфраструктура открытых ключей) — это про безопасность. Подразумевается, что у каждой сущности в инфраструктуре есть свой ключ, которым она однозначно идентифицируется. То есть, если ключ украден, пострадавшей сущностью может представиться укравший. PKI нужна для того, чтобы оперативно минимизировать последствия такой кражи. Ключ представлен двумя частями: публичной и приватной.
Аналог — это RSA ключи для SSH, но инфраструктурой их назвать сложно, так как отсутствует централизованный механизм управления ими. Также разница в том, что публичная часть ключа в паре ключей для SSH неизменна, а сертификат (публичную часть ключа участника PKI) можно перевыпустить в любой момент.
В PKI существует один (на самом деле, должно быть минимум два) или несколько Certification Authority — центров сертификации (удостоверяющих центров), отдающих публичные части своих ключей клиентам, которым выдают подписанные ими сертификаты. Таким образом, участники инфраструктуры «понимают», кто ими управляет, и действителен ли сертификат, выданный им или их «товарищам», в настоящий момент времени (одним из важнейших атрибутов сертификатов является срок их действия). Либо же сервер, у которого есть публичная часть ключа CA инфраструктуры, в которой он и его клиенты работают, понимает, что к нему пришел клиент с действительным сертификатом, и разрешает ему что-то, или запрещает в противном случае.
OpenVPN: как это бывает
На самом деле во многих компаниях на этот случай уже есть «PKI» и у него есть имя, потому что это кто-то из сотрудников. Назовем такого человека, к примеру, Полуэкт (с) и расскажем, как обычно это работает, а потом я расскажу, как это должно быть в идеале.
При появлении в компании нового сотрудника Полуэкт создает и присылает ему архив, в котором, помимо конфигурации собственно OpenVPN клиента, находятся файлы (на примере сотрудника Иванова А.А.):
- a.ivanov-office.key — его приватный ключ, самая мякотка, которую нужно хранить как зеницу ока и никому не показывать (аналог в SSH — файл id_rsa);
- a.ivanov-office.csr — Certificate Signing Request, запрос на подпись сертификата, в котором описано, для кого нужно выписать сертификат, сгенерирован на основе предыдущего файла, чтобы не «палить» приватный ключ (для работы самого OpenVPN нафиг не нужен);
- a.ivanov-office.crt — вожделенный сертификат, который он предъявляет OpenVPN серверу, чтобы тот разрешил ему подключение (по сути это публичная часть ключа);
- ca.crt — сертификат нашего CA, чтобы OpenVPN клиент предъявил его серверу, чтобы тот сопоставил его с приватной частью, которая лежит у него, и убедился, что сертификат подписывал именно он, а не кто-то другой. «Деталька», которая обозначает принадлежность OpenVPN клиента Иванова А.А. к PKI, в которой работает сервер.
В компании Acme все эти файлы генерирует Полуэкт…
А теперь как должно быть
На моем примере, упрощенно:
-
я у себя локально генерирую свой приватный ключ (можно и, пожалуй, логично, использовать уже готовый из
- готовлю запрос на подпись сертификата — CSR, для чего заполняю небольшую анкету:
Please enter the following ‘extra’ attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
(пароль в конце лучше не указывать, а то придется его вводить каждый раз при подключении, а VPN у нас по сертификатам как раз, чтобы этого не было; тем более у нас в Pixonic есть OTP от Google);
- отправляю получившийся файл a.vrublevskiy-office.csr Полуэкту;
- Полуэкт, получив мой запрос и имея обе части ключа CA (здесь — ca.key и ca.crt), выпускает для меня сертификат, подписывая его ключом CA (модные хипстеры пользуются easy-rsa, но мы суровые бородатые админы):
- Полуэкт отправляет мне получившийся файл.
Нужна ли вам эта фишка — вопрос для обсуждения. Соответственно, то, как ее внедрить, пока что выходит за рамки этой статьи.
И про срок действия клиентского сертификата: если предположить, что я устроился в Pixonic по временному контракту на 3 месяца, и мы его не продлили, то в описанной ситуации мой доступ к VPN автоматически отключится через 90 дней с момента выпуска сертификата. Чего не случится с SSH-доступом, если коллеги забудут отключить аккаунт во FreeIPA или удалить строчку из authorized_keys руками. C — сесуриту.
Теперь по Борщеву HTTPS
Предположим, вы хотите «включить SSL» для вашего сайта, чтобы у посетителей появился красивый замочек в браузере. Тут, собственно, все то же самое, но с некоторыми нюансами:
9. Что такое центр сертификации ключей?
Для решения проблем, связанных с управлением ключами в системах электронного документооборота с неограниченным количеством участников информационного обмена, необходимо создать специальную инфраструктуру поддержки управления ключами, так называемую инфраструктуру открытых ключей.
В основе инфраструктуры открытых ключей (ИОК) лежит специальный субъект — центр сертификации ключей (ЦСК), основной целью которого является обеспечение безопасного обмена открытыми ключами между участниками электронного взаимодействия.
ЦСК имеет право:
— предоставлять услуги ЭП и обслуживать усиленные сертификаты ключей;
— получать и проверять информацию, необходимую для регистрации пользователя и формирования сертификата ключа непосредственно у юридического или физического лица или у их представителя.
— принимать меры для обеспечения безопасности информации во время сертификации ключей и хранения сертификатов ключей;
— устанавливать во время формирования сертификата ключа, соответствия открытого ключа и секретного ключа пользователя;
— обеспечивать защиту персональных данных, полученных от пользователя, в соответствии с законодательством;
— своевременно отменять, блокировать и возобновлять сертификаты ключей в случаях, предусмотренных Законом;
— проверять законность обращений об отмене и блокировке сертификатов ключей и сохранять документы, на основе которых были отменены или блокированы сертификаты ключей;
— круглые сутки принимать заявки об отмене, блокировании и возобновлении сертификатов ключей;
— вести электронные реестры действующих, отмененных и блокированных сертификатов ключей и документацию, перечень которой определяется контролирующим органом;
— обеспечивать круглосуточный доступ пользователей к сертификатам ключей и соответствующим электронным реестрам через общедоступные телекоммуникационные каналы;
— обеспечивать хранение сформированных сертификатов ключей на протяжении срока, предусмотренного законодательством для хранения соответствующих документов на бумажной основе;
— предоставлять консультации по вопросам, связанным с цифровой подписью.
Центры сертификации ключей (ЦСК) являются единственными субъектами системы ЭП, которые предоставляют услуги сертификации открытых ключей непосредственно конечным пользователям.
С технической точки зрения, функции, которые выполняет ЦСК, условно возможно разделить на основные (функции управления сертификатами) и дополнительные.
К основным функциям относятся:
— генерация собственной ключевой пары;
— регистрация (идентификация) конечного пользователя;
— сертификация открытых ключей пользователей (процесс формирования сертификатов открытых ключей для конечных пользователей);
— публикация (распространение) сертификатов в открытом каталоге для обеспечения доступа к ним конечных пользователей;
— обеспечение отзыва сертификатов (блокировка или отмена действия сертификата при условии возникновения определенных обстоятельств).
— обеспечение проверки легитимности сертификата (распространение списков отозванных сертификатов);
Что такое центр сертификации (ЦС)?
A центр сертификации (CA)также иногда упоминается как Центр сертификацииявляется компанией или организацией, которая действует для проверки подлинности сущностей (таких как веб-сайты, адреса электронной почты, компании или отдельные лица) и связывает их с криптографическими ключами посредством выпуска электронных документов, известных как цифровые сертификаты.
Цифровой сертификат обеспечивает:
Аутентификацияслужа в качестве учетных данных для проверки личности объекта, которому он выдан.
Шифрование, для безопасной связи через незащищенные сети, такие как Интернет.
Целостность документов подписанный с сертификатом, чтобы они не могли быть изменены третьей стороной в пути.
Как правило, заявитель на получение цифрового сертификата генерирует пара ключей состоящий из закрытый ключ и еще один Открытый ключвместе с запрос на подпись сертификата (CSR), CSR представляет собой закодированный текстовый файл, который содержит открытый ключ и другую информацию, которая будет включена в сертификат (например, имя домена, организация, адрес электронной почты и т. д.). Пара ключей и CSR генерация обычно выполняется на сервере или рабочей станции, где будет установлен сертификат, и тип информации, включенной в CSR варьируется в зависимости от уровня проверки и предполагаемого использования сертификата. В отличие от открытого ключа, закрытый ключ кандидата хранится в безопасности и никогда не должен показываться CA (или кому-либо еще).
После генерации CSRзаявитель отправляет его в центр сертификации, который самостоятельно проверяет правильность содержащейся в нем информации и, если это так, подписывает сертификат цифровой подписью с выдачей секретного ключа и отправляет ее заявителю.
Когда подписанный сертификат представляется третьей стороне (например, когда это лицо обращается к веб-сайту держателя сертификата), получатель может криптографически подтвердить цифровую подпись ЦС с помощью открытого ключа ЦС. Кроме того, получатель может использовать сертификат, чтобы подтвердить, что подписанный контент был отправлен кем-то, у кого есть соответствующий закрытый ключ, и что информация не была изменена с момента подписания. Ключевой частью этого аспекта сертификата является так называемая цепочка доверия.
In SSL /TLS, S/MIME, подпись кодаи другие применения Сертификаты X.509иерархия сертификатов используется для проверки действительности издателя сертификата. Эта иерархия известна как цепь доверия, В цепочке доверия сертификаты выпускаются и подписываются сертификатами, которые находятся выше в иерархии.
A цепь доверия состоит из нескольких частей:
1. доверять якорь, который является исходным центром сертификации (CA).
2. По крайней мере, один промежуточный сертификат, служащая «изоляцией» между CA и сертификатом конечного объекта.
3. сертификат конечного объекта, который используется для проверки личности объекта, такого как веб-сайт, бизнес или лицо.
Легко увидеть цепочку доверия для себя, изучив HTTPS сертификат сайта. Когда ты проверка SSL /TLS сертификат в веб-браузере, вы найдете разбивку цепочки доверия этого цифрового сертификата, включая якорь доверия, любые промежуточные сертификаты и сертификат конечного объекта. Эти различные точки проверки подкрепляются действительностью предыдущего уровня или «ссылки», возвращающейся к доверительной привязке.
В приведенном ниже примере показана цепочка доверия от веб-сайта SSL.com, ведущая от сертификата веб-сайта конечного объекта обратно к корневому ЦС через один промежуточный сертификат:
Корень центр сертификации (CA) служит доверять якорь в цепочке доверия. Достоверность этого якоря доверия жизненно важна для целостности цепи в целом. Если CA публично доверенный (например, SSL.com), корневые сертификаты ЦС включаются крупными производителями программного обеспечения в свои браузеры и операционные системы. Это включение гарантирует, что сертификаты в цепочке доверия, ведущей обратно к любому из корневых сертификатов CA, будут доверять программному обеспечению.
Ниже вы можете увидеть якорь доверия с веб-сайта SSL.com ( SSL.com EV Root Certification Authority RSA R2 ):
Корневой ЦС или доверенный якорь могут подписывать и выдавать промежуточные сертификаты, Промежуточные сертификаты (также известные как промежуточный, подчиненный или выдающие CA) обеспечивают гибкую структуру для присвоения действительности якоря доверия дополнительным промежуточным и конечным сертификатам в цепочке. В этом смысле промежуточные сертификаты выполняют административную функцию; каждое промежуточное звено может использоваться для определенной цели — например, для выдачи SSL /TLS или сертификаты подписи кода — и даже могут быть использованы для совещаться доверие корневого центра сертификации к другим организациям.
Промежуточные сертификаты также обеспечивают буфер между сертификатом конечного объекта и корневым ЦС, защищая закрытый корневой ключ от компрометации. Для общедоступных центров сертификации (включая SSL.com) на форуме CA / Browser Базовые требования фактически запретить выпуск сертификатов конечных объектов непосредственно из корневого центра сертификации, который должен быть надежно отключен. Это означает, что цепочка доверия любого публично доверенного сертификата будет включать как минимум один промежуточный сертификат.
В примере, показанном ниже, SSL.com EV SSL Intermediate CA RSA R3 является единственным промежуточным сертификатом в цепочке доверия веб-сайта SSL.com. Как следует из названия сертификата, он используется только для выдачи EV SSL /TLS сертификаты:
Цена на сертификат конечного объекта является последним звеном в цепи доверия. Сертификат конечного объекта (иногда известный как листовой сертификат or сертификат абонента), служит для передачи доверия корневому центру сертификации через посредников в цепочке такой организации, как веб-сайт, компания, Правительствоили отдельное лицо.
Сертификат конечного объекта отличается от якоря доверия или промежуточного сертификата тем, что он не может выдавать дополнительные сертификаты. В каком-то смысле это последнее звено цепи. В приведенном ниже примере показан SSL /TLS сертификат с сайта SSL.com:
Цепочка доверия обеспечивает безопасность, масштабируемость и соответствие стандартам для ЦС. Он также обеспечивает конфиденциальность, доверие и безопасность для тех, кто полагается на сертификаты конечных объектов, таких как операторы веб-сайтов и пользователи.
Владельцам веб-сайтов и другим пользователям сертификатов конечных объектов важно понимать, что для их сертификата необходима полная цепочка доверия для успешного предоставления доверия ЦС. Информацию о диагностике и устранении ошибок браузера, вызванных неполной цепью доверия, см. На странице наша статья по установке промежуточных сертификатов и руководство по сообщениям об ошибках браузера.