Как заставить браузер доверять SSL-сертификату localhost?
Хотя, есть аналогичные вопросы , и даже хорошие ответы , они либо не касаются себя локальной конкретно, или попросить об одной конкретной опции / решении (самоподписных против CA).
Какие есть варианты? Как они сравниваются? Как мне это сделать?
tl; dr Создать сертификат, выданный собственным ЦС (см. сценарий ниже)
Вот что я нашел. Поправьте меня, где я ошибаюсь.
Есть ЦС (центры сертификации). Они выдают сертификаты (подписывают 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 ) или в категорию «другие записи». Сертификаты ЦС отображаются на вкладке «Авторитеты» в браузерах или на вкладке «Серверы».
Firefox не доверяет сертификатам сервера из корневого хранилища сертификатов ОС, в отличие от Chromium. Оба доверяют сертификатам CA из корневого хранилища сертификатов ОС.
Доверять сертификатам в браузере
В Chromium и Firefox вы можете добавлять (импортировать) сертификаты на вкладку Authorities. Если вы попытаетесь импортировать сертификат не CA, вы получите сообщение «Not a Certificate Authority». После выбора файла появляется диалоговое окно, в котором вы можете указать настройки доверия (когда доверять сертификату). Соответствующая настройка для обеспечения работы сайта — «Доверять этому сертификату для идентификации веб-сайтов».
В Chromium вы можете добавлять (импортировать) сертификаты на вкладке «Серверы». Но они попадают либо на вкладку «Авторитеты» (сертификаты CA, и после выбора файла вам не открывается диалоговое окно настроек доверия), либо на вкладку «Другие» (если сертификат не CA).
В Firefox вы не можете точно добавить сертификат на вкладку «Серверы». Вы добавляете исключения. И там можно доверять сертификату без расширений (плохой).
Самозаверяющие расширения сертификатов
Моя система поставляется со следующими настройками по умолчанию (будут добавлены расширения) для сертификатов:
Взято из /etc/ssl/openssl.cnf , раздел v3_ca . Подробнее об этом здесь .
Кроме того, Chromium считает сертификат недействительным, если его нет subjectAltName = DNS:$domain .
Несамоподписанные расширения сертификатов
Когда браузеры доверяют самозаверяющему сертификату
Чтобы Chromium мог доверять самозаверяющему сертификату, он должен иметь basicConstraints = CA:true и subjectAltName = DNS:$domain . Для Firefox даже этого недостаточно:
Когда браузеры доверяют сертификату, выпущенному собственным ЦС
Firefox не требует расширений, но Chromium требует subjectAltName .
openssl шпаргалка
openssl genpkey -algorithm RSA -out «$domain».key — сгенерировать закрытый ключ ( человек )
openssl req -x509 -key «$domain».key -out «$domain».crt — сгенерировать самоподписанный сертификат ( man )
Без -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 — просмотреть CSR ( мужчина )
openssl x509 -in $domain.crt -text -noout — просмотреть сертификат ( мужчина )
Создать самоподписанный сертификат
(для работы вам понадобится исключение в Firefox)
Сгенерировать сертификат, выданный собственным ЦС
Конфигурация веб-сервера
PS Я использую Chromium 65.0.3325.162, Firefox 59.0 и openssl-1.1.0.g .
Судя по всему, в Windows нет trust утилиты. Под Windows есть два хранилища : хранилища локального компьютера и хранилища сертификатов текущего пользователя. Нет смысла использовать хранилище сертификатов локального компьютера, поскольку мы заставляем его работать только для нашего текущего пользователя. Затем есть основания. Наиболее интересны два предопределенных из них: Trusted Root Certification Authorities и Intermediate Certification Authorities Stores. Обычно называют в командной строке в качестве корня и СА .
Вы можете получить доступ к диспетчеру сертификатов Chrome, выполнив команду chrome: // settings /? Search = Manage% 20certificates, затем щелкнув Управление сертификатами. Наибольший интерес представляют вкладки «Доверенные корневые центры сертификации» и «Промежуточные центры сертификации».
Один из способов получить сертификаты менеджера — через командную строку :
Результаты будут следующими (для хранилищ сертификатов локального компьютера и текущего пользователя):
Другими вариантами могут быть двойной щелчок по сертификату в проводнике, импорт сертификатов из диспетчера сертификатов Chrome, использование оснастки Certificates MMC Snap-in (запуск certmgr.msc ) или использование CertMgr.exe .
Для тех, кто grep установил, вот как быстро проверить, где находится сертификат:
Таким образом, установка сертификата CA в хранилище Current User> Trusted Root Certification Authorities кажется лучшим вариантом. И убедитесь , что не забыть перезапустить браузер .
Как заставить браузер доверять локальному SSL-сертификату?
Хотя есть similar вопросы и даже хорошие ответы, они либо не заботятся о локальном хосте. или спросите об одном конкретном варианте / решении (самоподписанный или CA).
Какие есть варианты? Как они сравниваются? Как мне это сделать?
3 ответа
tl; dr Создать сертификат, выданный собственным ЦС (см. сценарий ниже)
Вот что я нашел. Поправьте меня, где я ошибаюсь.
Есть ЦС (центры сертификации). Они выдают сертификаты (подписывают 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 ) или в категорию «другие записи» в противном случае. Сертификаты ЦС отображаются на вкладке «Авторитеты» в браузерах или на вкладке «Серверы».
Firefox не доверяет сертификатам сервера из корневого хранилища сертификатов ОС, в отличие от Chromium. Оба доверяют сертификатам CA из корневого хранилища сертификатов ОС.
Доверять сертификатам в браузере
В Chromium и Firefox вы можете добавлять (импортировать) сертификаты на вкладку Authorities. Если вы попытаетесь импортировать сертификат не CA, вы получите сообщение «Not a Certificate Authority». После выбора файла появляется диалоговое окно, в котором вы можете указать настройки доверия (когда доверять сертификату). Соответствующая настройка для обеспечения работы сайта — «Доверять этому сертификату для идентификации веб-сайтов».
В Chromium вы можете добавлять (импортировать) сертификаты на вкладке «Серверы». Но они попадают либо на вкладку «Центры» (сертификаты CA, и после выбора файла вам не открывается диалоговое окно настроек доверия), либо на вкладку «Другие» (если сертификат не CA).
В Firefox вы не можете точно добавить сертификат на вкладку «Серверы». Вы добавляете исключения. И там можно доверять сертификату без расширений (плохой).
Самозаверяющие расширения сертификатов
Моя система поставляется со следующими настройками по умолчанию (будут добавлены расширения) для сертификатов:
Кроме того, Chromium считает сертификат недействительным, если в нем нет subjectAltName = DNS:$domain .
Несамоподписанные расширения сертификатов
Когда браузеры доверяют самозаверяющему сертификату
Чтобы Chromium мог доверять самозаверяющему сертификату, он должен иметь basicConstraints = CA:true и subjectAltName = DNS:$domain . Для Firefox даже этого недостаточно:
Когда браузеры доверяют сертификату, выпущенному собственным ЦС
Firefox не нуждается в расширениях, но Chromium требует subjectAltName .
openssl шпаргалка
openssl genpkey -algorithm RSA -out «$domain».key — сгенерировать закрытый ключ (man)
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 «$ домен» .csr -days 365 -out «$ домен» .crt \ -CA ca.crt -CAkey ca.key -CAcreateserial — подписать CSR (мужчина)
Не работает без -CAcreateserial . Он создает файл ca.srl , в котором хранится серийный номер последнего сгенерированного сертификата. Чтобы добавить subjectAltName , вам понадобится переключатель -extfile :
openssl req -in $domain.csr -text -noout — просмотреть CSR ( man )
openssl x509 -in $domain.crt -text -noout — просмотреть сертификат ( man )
Создать самоподписанный сертификат
(вам понадобится исключение в Firefox, чтобы оно работало)
Сгенерировать сертификат, выданный собственным ЦС
Конфигурация веб-сервера
P.S. Я использую 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 кажется лучшим вариантом. И убедитесь , что не забыли перезапустить браузер.
Как выпустить самоподписанный SSL сертификат и заставить ваш браузер доверять ему
Все крупные сайты давно перешли на протокол https. Тенденция продолжается, и многие наши клиенты хотят, чтобы их сайт работал по защищенному протоколу. А если разрабатывается backend для мобильного приложения, то https обязателен. Например, Apple требует, чтобы обмен данными сервера с приложением велся по безопасному протоколу. Это требование введено с конца 2016 года.
На production нет проблем с сертификатами. Обычно хостинг провайдер предоставляет удобный интерфейс для подключения сертификата. Выпуск сертификата тоже дело не сложное. Но во время работы над проектом каждый разработчик должен позаботиться о сертификате сам.
В этой статье я расскажу, как выпустить самоподписанный SSL сертификат и заставить браузер доверять ему.
Чтобы выпустить сертификат для вашего локального домена, понадобится корневой сертификат. На его основе будут выпускаться все остальные сертификаты. Да, для каждого нового top level домена нужно выпускать свой сертификат. Получить корневой сертификат достаточно просто.
Сначала сформируем закрытый ключ:
Затем сам сертификат:
Нужно будет ввести страну, город, компанию и т.д. В результате получаем два файла: rootCA.key и rootCA.pem
Переходим к главному, выпуск самоподписанного сертификата. Так же как и в случае с корневым, это две команды. Но параметров у команд будет значительно больше. И нам понадобится вспомогательный конфигурационный файл. Поэтому оформим все это в виде bash скрипта create_certificate_for_domain.sh
Первый параметр обязателен, выведем небольшую инструкцию для пользователя.
Создадим новый приватный ключ, если он не существует или будем использовать существующий:
Запросим у пользователя название домена. Добавим возможность задания “общего имени” (оно используется при формировании сертификата):
Чтобы не отвечать на вопросы в интерактивном режиме, сформируем строку с ответами. И зададим время действия сертификата:
В переменной SUBJECT перечислены все те же вопросы, который задавались при создании корневого сертификата (страна, город, компания и т.д). Все значение, кроме CN можно поменять на свое усмотрение.
Сформируем csr файл (Certificate Signing Request) на основе ключа. Подробнее о файле запроса сертификата можно почитать в этой статье.
Формируем файл сертификата. Для этого нам понадобится вспомогательный файл с настройками. В этот файл мы запишем домены, для которых будет валиден сертификат и некоторые другие настройки. Назовем его v3.ext. Обращаю ваше внимание, что это отдельный файл, а не часть bash скрипта.
Да, верно, наш сертификат будет валидным для основного домена, а также для всех поддоменов. Сохраняем указанные выше строки в файл v3.ext
Возвращаемся в наш bash скрипт. На основе вспомогательного файла v3.ext создаем временный файл с указанием нашего домена:
Переименовываем сертификат и удаляем временный файл:
Скрипт готов. Запускаем его:
Получаем два файла: mysite.localhost.crt и device.key
Теперь нужно указать web серверу пути к этим файлам. На примере nginx это будет выглядеть так:
Запускаем браузер, открываем https://mysite.localhost и видим:
Браузер не доверяет этому сертификату. Как быть?
Нужно отметить выпущенный нами сертификат как Trusted. На Linux (Ubuntu и, наверное, остальных Debian-based дистрибутивах) это можно сделать через сам браузер. В Mac OS X это можно сделать через приложение Keychain Access. Запускаем приложение и перетаскиваем в окно файл mysite.localhost.crt. Затем открываем добавленный файл и выбираем Always Trust:
Обновляем страницу в браузере и:
Успех! Браузер доверяет нашему сертификату.
Сертификатом можно поделиться с другими разработчиками, чтобы они добавили его к себе. А если вы используете Docker, то сертификат можно сохранить там. Именно так это реализовано на всех наших проектах.
Делитесь в комментариях, используете ли вы https для локальной разработки?