На компьютере не установлен ни один из следующих разрешенных сертификатов

Обновлено: 30.06.2024

Secure Sockets Layer (SSL) и Transport Layer security (TLS) – это протоколы, которые обеспечивают безопасный обмен данными по компьютерной сети или каналу.

Они обычно используются при просмотре веб-страниц и электронной почте.

В этом уроке мы рассмотрим:

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

Что такое TLS

TLS основан на SSL и был разработан в качестве замены в ответ на известные уязвимости в SSLv3.

SSL — это широко используемый термин, который сегодня обычно относится к TLS.

Обеспечение безопасности

SSL/TLS обеспечивает шифрование данных, целостность данных и аутентификацию.

Это означает, что при использовании SSL/TLS вы можете быть уверены, что

Никто не читал ваше сообщение
Никто не изменил ваше сообщение
Вы общаетесь с предполагаемым лицом (сервером)

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

Как узнать, что никто не прочитал сообщение?
Откуда вы знаете, что никто не изменил сообщение?

Решения этих проблем заключаются в следующем:

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

Оба этих процесса требуют использования ключей.

Эти ключи представляют собой просто числа (обычно 128 бит), которые затем объединяются с сообщением с использованием определенного метода, широко известного как алгоритм, например. RSA для шифрования или подписи сообщения.

Симметричные ключи, открытые и закрытые ключи

Почти все современные методы шифрования используют открытые и закрытые ключи.

Они считаются гораздо более безопасными, чем старые симметричные ключи.

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

Это то же самое, что и ключи (от двери, от машины), с которыми мы имеем дело в повседневной жизни.

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

С открытым и закрытым ключами используются два ключа, которые математически связаны (они входят в пару ключей), но отличаются друг от друга.

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

Чтобы расшифровать сообщение, вам нужен закрытый ключ.

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

Этот тип расположения ключей очень безопасен и используется во всех современных системах шифрования/подписи.

Ключи и SSL-сертификаты

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

Открытые ключи могут быть доступны любому, отсюда и термин "общедоступный".

В связи с этим возникает вопрос доверия, а именно:

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

Например, вы получили ключ, якобы принадлежащий вашему банку.

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

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

Сертификат служит той же цели, что и паспорт в повседневной жизни.

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

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

Цифровой сертификат обеспечивает удобный способ распространения доверенных открытых ключей шифрования.

Получение цифрового сертификата

Вы получаете цифровой сертификат от признанного центра сертификации (ЦС). Точно так же, как вы получаете паспорт в паспортном столе.

На самом деле процедура очень похожа.

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

Центр сертификации выполняет некоторые проверки (зависит от центра сертификации) и возвращает вам ключи, заключенные в сертификате.

Сертификат подписывается выдавшим его центром сертификации, что гарантирует ключи.

Теперь, когда кому-то нужны ваши открытые ключи, вы отправляете им сертификат, они проверяют подпись на сертификате, и если она подтверждается, они могут доверять вашим ключам.

Пример использования

Это соединение используется в Интернете для отправки электронной почты в Gmail и т. д., а также при онлайн-банкинге, совершении покупок и т. д.

Вот видео, в котором все вышеперечисленное раскрывается более подробно:

Типы цифровых сертификатов

Если вы пытаетесь приобрести сертификат для веб-сайта или использовать его для шифрования MQTT, вы столкнетесь с двумя основными типами:

Сертификаты с проверкой домена (DVC)
Сертификаты расширенной проверки (EVC)

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

Уровень шифрования, который они обеспечивают, идентичен

Сертификат с проверкой домена (DV) — это цифровой сертификат X.509, обычно используемый для безопасности транспортного уровня (TLS), когда личность заявителя была подтверждена путем подтверждения определенного контроля над доменом DNS.-WikI

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

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

Ограничения на использование сертификатов — подстановочные знаки и SAN

Как правило, сертификат действителен для использования с одним полным доменным именем (FQDN).

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

Подстановочный сертификат распространяется на все поддомены под определенным доменным именем.

Чтобы охватить несколько разных доменных имен одним сертификатом, необходимо приобрести сертификат с SAN (альтернативное имя субъекта).

Как правило, они позволяют защитить 4 дополнительных доменных имени в дополнение к основному доменному имени. Например, вы можете использовать один и тот же сертификат для:

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

Зачем использовать коммерческие сертификаты?

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

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

Коммерческие сертификаты необходимы, когда вам нужна широкая поддержка вашего сертификата.

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

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

Кодировки сертификатов и расширения файлов

Сертификаты могут быть закодированы как:

Двоичные файлы (.DER)
Файлы ASCII (base64) (.PEM)

.DER
.PEM (электронная почта с повышенной конфиденциальностью)
.CRT
.CERT

Примечание. Реальной связи между расширением файла и кодировкой нет. Это означает, что файл .crt может быть файлом в кодировке .der или файлом в кодировке .pem.

Вопрос. Как узнать, есть ли у вас закодированный файл .der или .pem?

Ответ. Вы можете использовать инструменты openssl, чтобы найти тип кодировки и конвертировать между кодировками. См. это руководство — сертификаты DER, CRT, CER и PEM.

Вы также можете открыть файл, и если это текст ASCII, то это сертификат в кодировке .PEM

Примеры сертификатов

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

Важно отметить, что они начинаются и заканчиваются строками Begin Certificate и End Certificate.

Сертификаты можно хранить в отдельном файле или вместе в одном файле, называемом пакетом.

Корневой пакет ЦС и хешированные сертификаты

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

В системах Linux на базе Debian эти корневые сертификаты хранятся в папке /etc/ssl/certs вместе с файлом ca-certificates.crt.

Этот файл представляет собой набор всех корневых сертификатов в системе.

Он создается системой и может быть обновлен при добавлении новых сертификатов с помощью команды update-ca-certificates.Смотрите здесь

Файл ca-certifcates.crt выглядит так

Папка certs также содержит каждый отдельный сертификат или символическую ссылку на сертификат вместе с хешем.

Хэш-файлы создаются командой c_rehash и используются, когда указан каталог, а не файл. Например, инструмент mosquitto_pub можно запустить как:

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

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

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

Возможно, у клиента уже установлен корневой сертификат, но, вероятно, нет сертификатов промежуточных ЦС.

Поэтому сертификаты часто предоставляются как часть пакета сертификатов.

Этот пакет будет состоять из всех сертификатов ЦС в цепочке в одном файле, который обычно называется CA-Bundle.crt.

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

Видео

Вот мое видео, в котором рассматриваются вышеизложенные вопросы.
Вот найденное мной видео Майкрософт, объясняющее вышеизложенное.

Распространенные вопросы и ответы

В. Что такое надежный магазин?

A- Это список сертификатов ЦС, которым вы доверяете. Все веб-браузеры поставляются со списком доверенных ЦС.

В. Могу ли я добавить свой ЦС в доверенное хранилище браузера?

A- Да, в Windows, если щелкнуть сертификат правой кнопкой мыши, вы должны увидеть вариант установки

В. Что такое самоподписанный сертификат?

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

В. Что такое отпечаток сертификата?

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

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

Он также используется при ручной проверке сертификата.

Подробнее см. здесь

В. Что произойдет, если сертификат сервера будет украден?

A- Его можно отозвать. Существует несколько способов, с помощью которых клиент (браузер) может проверить, отозван ли сертификат, см. здесь

Ресурсы

Связанные руководства:

119 комментариев

Большое спасибо!
Может быть, вы или кто-нибудь может мне помочь?
Я написал приложение, написанное на C++, которое использовало mqtt в качестве клиента для публикации некоторых данных, принимаемых от аппаратных датчиков. Я использую библиотеку PAHO.
Текущая версия брокера использовала незащищенный mqtt (только защищенный паролем), но теперь клиент решает перейти на безопасность TLS. Единственное, что нужно брокеру, это сертификат (в приложении mqtt.fx он вызывает файл сертификата CA. И когда я заполняю это поле путем к правильному файлу CA, все работает как нужно)
Но я не могу понять, что эквивалентно «файлу сертификата SA» в MQTTClient_SSLOptions в библиотеке PAHO. Я пробовал все поля, которые имеют тип char* или const char*, и это не работает.
Мой код: (в этом примере я только пытаюсь открыть и что-то сделать)

int main() conn_opts = MQTTClient_connectOptions_initializer;
ssl_opts = MQTTClient_SSLOptions_initializer;
pubmsg = MQTTClient_message_initializer;
conn_opts.MQTTVersion =MQTTVERSION_3_1_1;
// проверяем, какие данные нужны для SSL-соединения
// путь к ssl-сертификату

ssl_opts = MQTTClient_SSLOptions_initializer;
ssl_opts.trustStore = «путь_к_файлу_CA»;
ssl_opts.sslVersion = 3;
ssl_opts.ssl_error_cb = SSL_err_handler;
conn_opts.ssl = & ssl_opts;
ssl_opts.struct_version =3;
conn_opts.struct_version = 1;

На самом деле я не использую клиент c, но посмотрю и посмотрю, смогу ли я найти пример.
С уважением
Стив

Спасибо во всех случаях.

Хороший вариант для начала

Очень хорошо объяснил.Очень понятно и подход продуман!

когда именно используется закрытый ключ? Я полагал, что он находится на стороне сервера, и я предполагаю, что он используется только для согласования сеансового ключа?

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

Эта статья рассказывает о сертификатах, но не создает их для себя… забавно ^^

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

Спасибо, отлично! полезное объяснение очень простым способом!

Отличный пост. Отличный контент с простыми примерами в реальном времени делает этот блог особенным. Большое спасибо. Благодарим вас за обмен знаниями.

Спасибо за отличную статью. У меня есть вопрос. Я создал свой собственный веб-сайт и установил сертификаты на сервер. Теперь мой сайт работает. Как передать сертификаты клиентам?

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

Привет, Стив, отличная статья!

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

Извините, но я не знаю.
С уважением,
Стив

Отличная статья. Теперь я лучше понимаю то, чего всегда старался избегать!
Вопрос: Когда вы передаете открытый ключ и сообщение зашифровано с помощью этого ключа, единственный человек, который может расшифровать, — это человек с закрытым ключом. В таком случае, зачем нам нужен сертификат для проверки источника открытого ключа? Это просто еще один уровень защиты (например, на случай кражи закрытого ключа?)
Большое спасибо. Отметить

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

Мне нужно знать, в таких случаях требуется ли удалять старый сертификат после обновления обновленного сертификата. Есть ли вероятность того, что java может попытаться использовать старый сертификат, и соединение ssl может завершиться ошибкой. Какой алгоритм здесь использует Java. Будет ли он проверять все сертификаты из хранилища ключей или остановится после нахождения первого сертификата с таким же cn и остановится на этом, даже если срок действия сертификата истек.

Не знаю, как это делает Java, но я бы удалил или заархивировал старую версию, так как она больше недействительна.

Спасибо, наконец-то я понял, как это работает!

Спасибо за статью, Стив, самое понятное объяснение, которое я читал.

Спасибо за статью.

Спасибо за прекрасное объяснение! Очень полезно и понятно.

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

Вы создаете свой собственный сертификат Центра сертификации, который становится вашим верхним уровнем. Это эквивалент центра сертификации Verisign, который вы видите в хранилище сертификатов вашего браузера.

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

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

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

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

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

Применимо к: Windows 7 с пакетом обновления 1, Windows Server 2012 R2
Исходный номер базы знаний: 2831004

Симптомы

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

Проблема с сертификатом безопасности этого веб-сайта.

Сертификат безопасности, представленный этим веб-сайтом, не был выдан доверенным центром сертификации.

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

Причина

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

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

Путь сертификации 1: сертификат веб-сайта – сертификат промежуточного центра сертификации – сертификат корневого центра сертификации (1)
Путь сертификации 2: сертификат веб-сайта – сертификат промежуточного центра сертификации – сертификат кросс-корневого центра сертификации – сертификат корневого центра сертификации (2)

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

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

Временное решение

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

Войдите на веб-сервер как системный администратор.

Добавьте оснастку "Сертификат" в консоль управления Microsoft, выполнив следующие действия:

Нажмите "Пуск" > "Выполнить", введите mmc и нажмите Enter.
В меню "Файл" нажмите "Добавить/удалить оснастку".
Выберите "Сертификаты", нажмите "Добавить", выберите "Учетная запись компьютера" и нажмите "Далее".
Выберите Локальный компьютер (компьютер, на котором запущена эта консоль), а затем нажмите Готово.
Нажмите "ОК".

Разверните раздел Сертификаты (локальный компьютер) в консоли управления, а затем найдите сертификат по пути сертификата, который вы не хотите использовать.

Если сертификат является сертификатом корневого центра сертификации, он содержится в доверенных корневых центрах сертификации. Если сертификат является промежуточным сертификатом ЦС, он содержится в промежуточных центрах сертификации.

Удалите или отключите сертификат одним из следующих способов:

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

Перезапустите сервер, если проблема не устранена.

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

Нажмите "Пуск" > "Выполнить", введите gpedit.msc и нажмите клавишу ВВОД.

Разверните узел "Конфигурация компьютера" > "Административные шаблоны" > "Система" > "Управление связью через Интернет", а затем нажмите "Параметры связи с Интернетом".

Дважды нажмите «Отключить автоматическое обновление корневых сертификатов», выберите «Включено» и нажмите «ОК».

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

Применимо к: Windows Server 2012 R2
Исходный номер базы знаний: 281271

Симптомы

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

Сценарий 1

В этом сценарии ЦС не публикует выданные сертификаты для объекта DS пользователя в дочернем домене, если выполняются следующие условия:

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

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

Кроме того, на сервере CA регистрируется следующее событие:

Сценарий 2

Рассмотрите следующий сценарий:

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

В этом сценарии центр сертификации не публикует выданные сертификаты для объекта сервера домена пользователя в одноуровневом домене или в родительском домене.

Причина

Для сценария 1: двухуровневая иерархия доменов

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

По умолчанию только пользователи домена из того же домена, что и ЦС, имеют разрешения на регистрацию.

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

ЦС в родительском домене не имеет разрешений на использование свойства userCertificate для пользователей в дочернем домене.

Для сценария 2: одноуровневый домен или родительский домен

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

После установки исправления KB327825 следующий список групп учетных записей пользователей в Windows теперь является защищенными группами учетных записей пользователей:

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

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

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

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

Рисунок 1. Индикаторы доверия веб-браузера

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

Рисунок 2. Предупреждение о незащищенном веб-сайте в браузере

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

3 основных объекта = цепочка доверия

Существует три основных типа объектов, составляющих действующую цепочку доверия: корневой, промежуточный и конечный объект. Давайте подробнее рассмотрим каждый из них в следующем разделе.

Корневой сертификат: якорь доверия

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

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

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

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

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

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

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

Сертификат сервера: конечная сущность

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

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

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

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

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

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

Использование ключа сертификата ЦС

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

Возможно, вы заметили, что промежуточные центры сертификации функционально аналогичны корневым центрам сертификации. Однако у них часто включено меньше функций использования клавиш. Действительный сертификат X.509 от доверенного издателя действителен только для использования, указанного в политиках сертификатов. Сертификаты, соответствующие этим правилам политики цепочки, могут по-прежнему быть недействительными для других целей с такими функциями, как безопасность/MIME (SMIME), Authenticode или Secure Sockets Layer (SSL). Может потребоваться дополнительная обработка, чтобы определить, действителен ли сертификат для конкретной политики.

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

Целью сертификата может быть одна из четырех настроек использования ключа и расширенных полей использования ключа, указанных в сертификате:

Три типа моделей доверия

Иерархическая модель доверия

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

Сеть доверия

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

Архитектура моста ЦС

Bridge CA преодолевает сложность модели Web of Trust. Здесь Bridge CA действует как центральная координирующая точка. Все остальные центры сертификации (известные как принципалы) должны доверять только центру сертификации моста.

Построение пути сертификата цепочки доверия

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

Операционная система Windows позволяет извлекать сертификаты из цепочек сертификатов следующими четырьмя способами:

Давайте подробнее рассмотрим каждый из этих методов.

Метод локального хранилища сертификатов

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

Подобное поведение можно наблюдать при изучении подписей Authenticode. При подписании бинарного файла в подпись может быть включена цепочка сертификатов, и эти сертификаты будут использоваться для построения цепочки путем проверки каждой подписи. Хотя этот метод выгоден, он не всегда доступен для приложений. Например, при подключении к SSTP VPN сервер VPN не отправляет клиенту промежуточные сертификаты.

Crypt32.dll и Центр обновления Майкрософт

Если ваш компьютер подключен к Интернету, механизм цепочки сертификатов проверит веб-сайт Центра обновления Майкрософт. И если он найден (как в примере выше), он скачивается и устанавливается в хранилище сертификатов. Если ваш компьютер не подключен к Интернету, CCE извлечет содержимое сертификата из библиотеки crypt32.dll и установит сертификат в контейнер доверенных корневых ЦС.

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

Internet Explorer: "Сертификат безопасности, представленный этим веб-сайтом, не был выдан доверенным центром сертификации".

Firefox 3: "www.example.com использует недействительный сертификат безопасности. Сертификат не является доверенным, поскольку сертификат эмитента неизвестен". или "www.example.com использует недействительный сертификат безопасности. Сертификат не является доверенным, поскольку он самозаверяющий".

В браузеры встроен список доверенных поставщиков сертификатов (например, DigiCert). Для некоторых сайтов поставщик сертификатов отсутствует в этом списке. В этом случае браузер предупредит вас о том, что центр сертификации (ЦС), выдавший сертификат, не является доверенным. Эта проблема также может возникнуть, если на сайте есть самозаверяющий сертификат. Хотя это предупреждение является довольно общим для Internet Explorer, Firefox 3 различает сертификат, выданный самим сервером (самозаверяющий сертификат), и другой тип ненадежного сертификата.

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

Получите сертификаты SSL Plus всего за 188 долларов США в год

Самоподписанные сертификаты

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

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

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

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

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

Чтобы решить эту проблему, установите файл промежуточного сертификата (или цепного сертификата) на сервер, на котором размещен ваш веб-сайт. Для этого войдите в консоль управления DigiCert, щелкните номер заказа, а затем выберите ссылку для загрузки сертификата. Этот файл должен называться DigiCertCA.crt. Затем следуйте инструкциям по установке для вашего сервера, чтобы установить файл промежуточного сертификата.

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

Проблемы промежуточного сертификата (дополнительно)

Если вы получаете сообщение об ошибке при использовании нашего тестера SSL-сертификатов, вы используете сервер Windows, а эмитент вашего сертификата указан как "DigiCert High Assurance EV CA-3", инструкции по устранению неполадок при установке SSL см. в этой статье. .

Ниже приведены еще несколько предупреждающих сообщений для разных браузеров.

Internet Explorer 6: «Информация, которой вы обмениваетесь с этим сайтом, не может быть просмотрена или изменена другими лицами. Однако существует проблема с сертификатом безопасности сайта. Сертификат безопасности был выпущен компанией, которой вы не доверяете. Посмотреть сертификат, чтобы определить, хотите ли вы доверять центру сертификации. Продолжить?"

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

Читайте также: