Как сделать сертификат сайта доверенным

Обновлено: 04.07.2024

Хотя есть похожие вопросы и даже хорошие ответы, они либо не занимаются конкретно localhost, либо задают вопрос об одном конкретном варианте / решении (самоподписанный против CA).

Какие есть варианты? Как они сравниваются? Как мне это сделать?

1 ответ

tl;dr Создать сертификат, выданный собственным центром сертификации (см. скрипт ниже)

Вот что я нашел. Поправь меня, где я не прав.

Есть CA (центры сертификации). Они выдают сертификаты (подписывают CSR) для других CA (промежуточных CA) или серверов (сертификаты конечных объектов). Некоторые из них являются корневыми авторитетами. У них есть самоподписанные сертификаты, выданные самим. То есть обычно существует цепочка доверия, которая идет от сертификата сервера к корневому сертификату. И никто не может поручиться за корневой сертификат. Таким образом, ОС имеют хранилище корневых сертификатов (или хранилище политики доверия), общесистемный список доверенных корневых сертификатов. Браузеры имеют свои собственные списки доверенных сертификатов, которые состоят из общесистемного списка и сертификатов, которым доверяет пользователь.

В Chromium вы управляете сертификатами в chrome://settings/ Certificates. В Firefox Preferences > Privacy & Security > Certificates > View Certificates , Оба имеют вкладку Authorities, которая представляет собой список доверенных корневых сертификатов. И вкладка Серверы, список сертификатов доверенных серверов.

Чтобы получить сертификат, вы создаете CSR (запрос на подпись сертификата), отправьте его в CA. CA подписывает CSR, превращая его в доверенный сертификат в процессе.

Сертификаты и CSR - это набор полей с информацией плюс открытый ключ. Некоторые поля называются расширениями. CA сертификат является сертификатом с basicConstraints = CA:true ,

Вы можете проверить ошибки сертификата в Chromium в Developer Tools > Security ,

Доверительные сертификаты в масштабе всей системы

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

trust ставит сертификаты CA в категорию "авторитет" ( trust list ), или категория "другие записи" в противном случае. Сертификаты CA отображаются на вкладке Authorities в браузерах или на вкладке Servers.

Firefox не доверяет сертификатам сервера из хранилища корневых сертификатов ОС, в отличие от Chromium. Оба доверяют сертификатам CA из хранилища корневых сертификатов ОС.

Доверие сертификатам в браузере

В Chromium вы можете добавлять (импортировать) сертификаты на вкладке Серверы. Но они заканчиваются либо на вкладке Authorities (сертификаты CA, и вы не видите диалоговое окно параметров доверия после выбора файла), либо на вкладке Others (если сертификат не CA).

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

Самозаверяющие сертификаты

Моя система поставляется со следующими настройками по умолчанию (расширения, которые будут добавлены) для сертификатов:

Взято из /etc/ssl/openssl.cnf, раздел v3_ca. Подробнее об этом здесь.

Кроме того, Chromium считает сертификат недействительным, если он не имеет subjectAltName = DNS:$domain ,

Несамостоятельно подписанные расширения сертификатов

Из раздела [ usr_cert ] из /etc/ssl/openssl.cnf :

Когда браузеры доверяют самоподписанному сертификату

Чтобы Chromium доверял самозаверяющему сертификату, он должен иметь basicConstraints = CA:true , а также subjectAltName = DNS:$domain , Для Firefox даже этого недостаточно:

Когда браузеры доверяют сертификату, выпущенному собственным CA

Firefox не нуждается в расширениях, но Chromium требует subjectAltName ,

openssl шпаргалка

openssl genpkey -algorithm RSA -out "$domain".key - сгенерировать закрытый ключ ( человек)

openssl req -x509 -key "$domain".key -out "$domain".crt - создать самозаверяющий сертификат ( мужчина)

Без -subj он будет задавать вопросы, касающиеся отличительного имени (DN), например, общего имени (CN), организации (O), населенного пункта (L). Вы можете ответить на них "заранее": -subj "/CN=$domain/O=$org" ,

Добавить subjectAltName расширение, вам нужно либо иметь конфиг, где все это указано, либо добавить раздел в конфиг и сказать openssl его имя с -extensions переключатель:

openssl req -new -key "$domain".key -out "$domain".csr - создать CSR, это может занять -subj вариант ( человек)

openssl x509 -req -in "$domain".csr -days 365 -out "$domain".crt \ -CA ca.crt -CAkey ca.key -CAcreateserial - подписать КСО ( мужчина)

Не работает без -CAcreateserial , Это создает ca.srl файл, в котором хранится серийный номер последнего сгенерированного сертификата. Добавить subjectAltName тебе понадобится -extfile переключатель:

openssl req -in $domain.csr -text -noout - посмотреть КСО ( мужчина)

openssl x509 -in $domain.crt -text -noout - посмотреть сертификат ( человек)

Создать самозаверяющий сертификат

(для работы вам понадобится исключение в Firefox)

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

Конфигурация веб-сервера

PS Я использую Chromium 65.0.3325.162, Firefox 59.0 и openssl-1.1.0.g ,

Windows

Видимо, Windows не имеет trust полезность. В Windows есть два хранилища: локальный компьютер и хранилище сертификатов текущего пользователя. Нет смысла использовать хранилище сертификатов Local Machine, так как мы заставляем его работать только для нашего текущего пользователя. Затем есть магазины. Два предопределенных из них представляют наибольший интерес: доверенные корневые центры сертификации и промежуточные центры сертификации. Обычно упоминается в командной строке как root и CA.

Вы можете получить доступ к Диспетчеру сертификатов в Chrome, выполнив команду chrome://settings/? Search=Manage%20certificates и нажав Управление сертификатами. Наибольший интерес представляют вкладки "Доверенные корневые центры сертификации" и "Промежуточные центры сертификации".

Один из способов получения сертификатов менеджера - через командную строку:

Результаты следующие (для хранилищ локальных компьютеров и сертификатов текущего пользователя):

Другими вариантами будут двойной щелчок по сертификату в проводнике, импорт сертификатов из диспетчера сертификатов Chrome с использованием оснастки MMC "Сертификаты" (запуск certmgr.msc ) или используя CertMgr.exe ,

Для тех, у кого есть grep Установлено, вот как быстро проверить, где находится сертификат:

Таким образом, установка CA-сертификата в хранилище Current User > Trusted Root Certification Authorities кажется наилучшим вариантом. И не забудьте перезапустить браузер.

В SKU Шлюза приложений версии 2 используются доверенные корневые сертификаты для поддержки внутренних серверов. То есть сертификаты аутентификации, которые были необходимы в SKU версии 1, больше не нужны. Корневой сертификат — это закодированный в Base64 корневой сертификат формата X.509(.CER) из внутреннего сервера сертификатов. Он определяет корневой центр сертификации (ЦС), выдавший сертификат сервера. Затем сертификат сервера используется для обмена данными по протоколу TLS/SSL.

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

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

В этой статье раскрываются следующие темы:

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

Предварительные требования

OpenSSL на компьютере под управлением Windows или Linux.

Хотя для управления сертификатами могут быть доступны и другие инструменты, в этом учебнике используется OpenSSL. OpenSSL поставляется со многими дистрибутивами Linux, например Ubuntu.

Веб-сервер.

Например, Apache, IIS или NGINX для тестирования сертификатов.

SKU Шлюза приложений версии 2.

Создание сертификата корневого ЦС

Создайте сертификат корневого ЦС с помощью OpenSSL.

Создание корневого ключа

Войдите на компьютер, где установлен OpenSSL, и выполните следующую команду. Будет создан зашифрованный ключ.

Создание корневого сертификата и его самозаверение

Используйте следующие команды для создания запроса на подпись сертификата (CSR) и сертификата.

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

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

Создание сертификата сервера

Далее предстоит создать сертификат сервера с помощью OpenSSL.

Создание ключа сертификата

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

Создание запроса на подпись сертификата (CSR)

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

Используйте следующую команду, чтобы создать CSR:

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

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

Используйте следующую команду, чтобы создать сертификат:

Проверка созданного сертификата

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

Проверьте свой каталог и убедитесь, что в нем есть следующие файлы:

contoso.crt;
contoso.key;
fabrikam.crt;
fabrikam.key.

Настройка сертификата в параметрах TLS веб-сервера

На веб-сервере настройте TLS с помощью файлов fabrikam.crt и brikam.key. Если веб-сервер не может принять два файла, их можно объединить в один файл PEM или PFX с помощью команд OpenSSL.

Инструкции по импорту сертификата и его передаче в качестве сертификата сервера в службах IIS см. в статье Практическое руководство. Импорт и установка сертификата на веб-сервере в Windows Server 2003.

Инструкции по привязке TLS см. в статье Как настроить SSL для IIS 7.

Apache

Ниже приведен пример конфигурации виртуального узла, настроенного для SSL в Apache:

NGINX

Ниже приведен пример конфигурации серверного блока NGINX с конфигурацией TLS:

Доступ к серверу для проверки конфигурации

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

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

Проверка конфигурации с помощью OpenSSL

Для проверки сертификата можно также использовать OpenSSL.

Чтобы передать сертификат в Шлюз приложений, необходимо экспортировать CRT-сертификат в формат CER с кодировкой Base-64. Поскольку CRT-файл уже содержит открытый ключ в формате Base-64, просто измените расширение файла с CRT на CER.

Портал Azure

Azure PowerShell

Для отправки корневого сертификата можно также использовать Azure CLI или Azure PowerShell. Следующий код является примером для Azure PowerShell.

Хотя есть похожие вопросы и даже хорошие ответы, они либо не касаются конкретно localhost, либо спрашивают об одном конкретном варианте/решении (самоподписанный vs CA).

Какие есть варианты? Как они сравниваются? Как же мне это сделать?

2 ответа

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

tl;dr Генерирует сертификат, выданный собственным CA (см. Сценарий ниже)

Вот что я нашел. Поправь меня, где я ошибаюсь.

Существуют CA (центры сертификации). Они выдают сертификаты (подписывают CSR) для других CA (промежуточные CA) или серверов (сертификаты конечных сущностей). Некоторые из них являются коренными авторитетами. У них есть самоподписанные сертификаты, выданные ими самими. То есть обычно существует цепочка доверия, которая идет от сертификата сервера к корневому сертификату. И нет никого, кто мог бы поручиться за корневой сертификат. Таким образом, OS'es имеют хранилище корневых сертификатов (или хранилище политик доверия), общесистемный список доверенных корневых сертификатов. Браузеры имеют свои собственные списки доверенных сертификатов, которые состоят из общесистемного списка плюс сертификаты, которым доверяет пользователь.

В Chromium вы управляете сертификатами по адресу chrome://settings/certificates. В Firefox, Preferences > Privacy & Security > Certificates > View Certificates . У обоих есть вкладка "Полномочия", которая представляет собой список доверенных корневых сертификатов. И вкладка Серверы, список сертификатов доверенных серверов.

Чтобы получить сертификат, вы создаете CSR (запрос на подпись сертификата), отправляете его в CA. CA подписывает CSR, превращая его в доверенный сертификат в процессе.

Сертификаты и CSR-это набор полей с информацией и открытым ключом. Некоторые поля называются расширениями. сертификат CA - это сертификат с basicConstraints = CA:true .

Вы можете проверить ошибки сертификата в Chromium в Developer Tools > Security .

Доверительные сертификаты по всей системе

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

trust помещает CA сертификатов в категорию "authority" ( trust list ) или "other-entry" в противном случае. CA сертификаты отображаются на вкладке "Полномочия" в браузерах или на вкладке "Серверы".

Firefox не доверяет сертификатам сервера из корневого хранилища сертификатов OS, в отличие от Chromium. Оба доверяют сертификатам CA из хранилища корневых сертификатов OS.

Доверительные сертификаты в браузере

В Chromium вы можете добавить (импортировать) сертификаты на вкладке Серверы. Но они заканчиваются либо на вкладке "Полномочия" (сертификаты CA, и после выбора файла вам не открывается диалоговое окно "Настройки доверия"), либо на вкладке "Другие" (если сертификат не CA).

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

Самозаверяющие расширения сертификатов

Взято из /etc/ssl/openssl.cnf , раздел v3_ca . Подробнее об этом здесь .

Кроме того, Chromium считает сертификат недействительным, если в нем нет subjectAltName = DNS:$domain .

Non-self-signed расширения сертификатов

Когда браузеры доверяют самозаверяющему сертификату

Чтобы Chromium доверял самозаверяющему сертификату , у него должно быть basicConstraints = CA:true и subjectAltName = DNS:$domain . Для Firefox даже этого недостаточно: