Как создавать надежные SSL-сертификаты для локальной разработки
Случалось ли так, что вы понимали — необходимо добавить HTTPS в приложение, запущенное на локальном хостинге или каком-нибудь еще местном домене вроде local.my-app.com ?
Есть некоторые различия в том, как браузеры работают с HTTP и HTTPS. Например, любые попытки загрузить JavaScript на HTTPS-странице по HTTP-ссылке будут заблокированы. Это значит, что если локальная разработка идет на HTTP, то добавленный тэг скрипта прекрасно будет работать на вашей машине, но сломается, как только вы развернете приложение на промежуточном или продакшен-окружении, где всё работает под HTTPS. Не очень вдохновляющая перспектива.
Но не волнуйтесь. Во избежание подобных проблем полезно установить HTTPS в локальной среде разработки, чтобы более точно отображать ситуацию на рабочем сервере. Тем не менее, заставить эту штуку работать не так-то легко. Никто не хочет постоянно видеть предупреждения о сертификатах. Но как тогда обеспечить безопасность локально?
Ответ прост: создать собственный сертификат, либо подписывающий сам себя, либо заверенный локальным корневым сервером, и внести его в хранилище доверенных сертификатов операционной системы. Далее этим сертификатом можно пользоваться на локальном веб-сервере.
В этой статье мы разберем процесс создания локального корневого сертификата (также известного, как источник сертификатов). Это позволит вам создавать сколько угодно сертификатов для доменных имен, но доверять только одному сертификату — корневому.
Важно отметить вот что: с 1 сентября 2020 года SSL-сертификаты не выдаются дольше, чем на тринадцать месяцев (397 дней). Поэтому для сертификатов, создаваемых в этой статье, мы ограничимся двенадцатью месяцами.
Создание сертификата
Источник сертификата (Certificate Authority)
1. Создайте закрытый ключ и самоподписанный сертификат
Опционально: если необходимо, можно заменить MY-CA в CN на что-нибудь другое.
Если вам захочется проверить информацию сертификата, его содержимое можно вывести, запустив следующий код:
2. Создайте файл сертификата с расширением .crt :
Сертификат доменного имени
В большинстве случаев достаточно зарегистрировать в сертификате вашу рабочую станцию. Тем не менее, если вы предпочитаете собственные доменные имена для локальных приложений, в созданный сертификат можно добавить несколько альтернативных имен.
1. Создайте файл расширения x509 v3:
Следуя этому шаблону, можно добавить сколько угодно доменных имен.
Примечание: пожалуйста, обновите DNS.4, DNS.5 и DNS.6 или удалите их, если у вас не настроены никакие локальные доменные имена.
2. Создайте закрытый ключ и запрос на подпись сертификата:
Опционально: страну, штат, город и организацию можно изменять.
3. Создайте самоподписанный сертификат:
Использование сертификата
Приложениям, обслуживающим ваш контент, понадобится доступ к файлам сертификата и закрытого ключа. Это может быть локальный веб-сервер (Apache или NGINX), локальный сервис или какой-то другой локальный инструмент, допустим, сборщик модулей DevServer.
Вот несколько примеров:
Apache
NGINX
webpack DevServer
Express.js
Как только вы настроите обслуживающий ваше приложение инструмент на работу с вашим сертификатом, ваше приложение будет доступно по URL’у с HTTPS.
Следуя приведенному выше примеру с Express, вы можете открыть вкладку браузера по адресу https://localhost:8000 и увидеть ваш контент:
Погодите секунду! Где же сообщение «это защищенный сервер»?
Вы рассчитывали увидеть кое-что другое, но именно этого и следовало ожидать — потому что источник сертификата еще не входит в число доверенных.
Доверие к сертификатам
Чтобы получить обозначение безопасного доступа, ваш новый источник сертификата должен считаться доверенным на вашей машине. Процесс присваивания этого статуса различается в зависимости от операционной системы и удовлетворит большинство браузеров. Если вы используете Firefox, процесс имеет некоторые отличия.
macOS — Chrome и Safari
1. Дважды кликните на корневом сертификате ( ca.crt ).
2. Выберите нужную связку ключей [keychain] ( login , если вы хотите, чтобы сертификат считался доверенным только в вашем аккаунте, или System , если сертификат должен считаться доверенным во всей системе).
3. Добавьте сертификат.
4. Откройте «Keychain Access» (если еще не открыт).
5. Выделите keychain, который выбрали раньше.
6. Вы должны увидеть сертификат MY-CA (это будет имя, которое вы, как CN, дали вашему источнику сертификата).
7. Дважды кликните по сертификату.
8. Разверните «Доверять» и выберите опцию «Доверять всегда» в пункте «При использовании этого сертификата».
9. Закройте окно сертификата и введите свой пользовательский пароль (если требуется).
Windows 10 — Chrome, IE11 и Edge
1. Дважды кликните на сертификате ( ca.crt ).
2. Кликните на кнопку «Установить сертификат».
3. Выберите, хотите ли вы хранить его на уровне пользователя или на уровне машины.
4. Кликните «Дальше».
5. Выберите «Разместить все сертификаты в следующем хранилище».
6. Кликните «Обзор».
7. Выберите «Доверенные корневые источники сертификатов».
9. Кликните «Дальше».
10. Кликните «Завершить».
11. Если появится подсказка, кликните «Да».
Firefox
Даже после того, как вы установите доверенный источник сертификата в хранилище, Firefox все равно будет выдавать предупреждения. Этого может не случиться в Windows 10, но почти наверняка случится в macOS. Справиться с этим достаточно просто. Firefox демонстрирует вот такой экран:
Чтобы добавить разрешения сертификату, кликните «Дополнительно…». Сразу же после этого кликните на «Принять риск и продолжить», чтобы дать понять, что вы знаете о риске.
Это нужно сделать всего один раз, но для каждого локального домена.
Заключение
Теперь, когда сертификат создан и доверие к нему обеспечено, вы без проблем можете посещать свой локальный домен! Обслуживание приложений стало безопасным, и вы можете спокойно продолжать разработку. Возвращаясь к примеру с Express, результат на экране будет таким:
Сайт полностью загружен, и рядом с URL в Chrome теперь отображается символ безопасного соединения.
Adding a self-signed certificate to the "trusted list"
I’ve generated a self-signed certificate for my build server and I’d like to globally trust the certificate on my machine, as I created the key myself and I’m sick of seeing warnings.
I’m on Ubuntu 12.04. How can I take the certificate and globally trust it so that browsers (Google Chrome), CLI utilities (wget, curl), and programming languages (Python, Java, etc.) trust the connection to https://example.com without asking questions?
6 Answers 6
The simple answer to this is that pretty much each application will handle it differently.
Also OpenSSL and GNUTLS (the most widely used certificate processing libraries used to handle signed certificates) behave differently in their treatment of certs which also complicates the issue. Also operating systems utilize different mechanisms to utilize "root CA" used by most websites.
That aside, giving Debian as an example. Install the ca-certificates package:
You then copy the public half of your untrusted CA certificate (the one you use to sign your CSR) into the CA certificate directory (as root):
NOTE: Certificate needs to have .crt extension for it to be picked up.
And get it to rebuild the directory with your certificate included, run as root:
and select the ask option, scroll to your certificate, mark it for inclusion and select ok.
Most browsers use their own CA database, and so tools like certutil have to be used to modify their contents (on Debian that is provided by the libnss3-tools package). For example, with Chrome you run something along the lines of:
Firefox will allow you to browse to the certificate on disk, recognize it a certificate file and then allow you to import it to Root CA list.
Most other commands such as curl take command line switches you can use to point at your CA,
or drop the SSL validation altogether
The rest will need individual investigation if the ca-certificates like trick does not sort it for that particular application.
Как выпустить самоподписанный 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 для локальной разработки?
Установка SSL сертификата на все компьютеры домена с помощью групповых политик
15.11.2022
itpro
Active Directory, Групповые политики
комментария 3
Рассмотрим процедуру централизованной установки сертификата на компьютеры домена и добавление его в список доверенных корневых сертификатов с помощью групповых политик. После распространения сертификата все клиентские устройства будут доверять сервисам, которые подписаны данным сертификатом. В нашем случае, мы распространим самоподписанный SSL сертификат Exchange (роль Active Directory Certificate Services в доменен не развернута) на компьютеры пользователей в Active Directory.
Если вы используете самоподписанный SSL сертификат для своего сервера Exchange, то на клиентах, при первом запуске Outlook будет появляться сообщение, что сертификат не доверенный и пользоваться им небезопасно.
Чтобы убрать это предупреждение, нужно на компьютере пользователя добавить сертификат Exchange в список доверенных сертификатов системы. Это можно сделать вручную (либо путем интеграции сертификата в корпоративный образ ОС), но гораздо более проще и эффективнее автоматически распространить сертификат с помощью возможностей групповых политик (GPO). При использовании такой схемы распространения сертификатов, все необходимые сертификат будет автоматически устанавливаться на все старые и новые компьютеры домена.
В первую очередь, нам нужно экспортировать самоподписанный сертификат с нашего Exchange сервера. Для этого на сервере откройте консоль mmc.exe и добавьте в нее оснастку Certificates (для локального компьютера).
Перейдите в раздел Certificates (Local Computer) -> Trusted Root Certification Authorities -> Certificates.
В правом разделе найдите ваш сертификат Exchange и в контекстном меню выберите All Tasks ->Export.
В мастере экспорта выберите формат DER encoded binary X.509 (.CER) и укажите путь к файлу сертификата.
Также вы можете получить SSL сертификат HTTPS сайта и сохранить его в CER файл с из PowerShell с помощью метода WebRequest:
$webRequest = [Net.WebRequest]::Create(«https://your-excha-cas-url»)
try < $webRequest.GetResponse() >catch <>
$cert = $webRequest.ServicePoint.Certificate
$bytes = $cert.Export([Security.Cryptography.X509Certificates.X509ContentType]::Cert)
set-content -value $bytes -encoding byte -path «c:\ps\get_site_cert.cer»
Итак, вы экспортировали SSL сертификат Exchange в CER файл. Нужно поместить сертификат в сетевой каталог, куда у всех пользователей должен быть доступ на чтение (вы можете ограничить доступ к каталогу с помощью NTFS разрешений, или дополнительно скрыть его с помощью ABE). К примеру, пусть путь к файлу сертификата будет таким: \\msk-fs01\GroupPolicy$\Certificates.
Перейдем к созданию политики распространения сертификата. Для этого, откройте консоль управления доменными политиками Group Policy Management (gpmc.msc). Чтобы создать новую политику, выберите OU на который она будет действовать (в нашем примере это OU с компьютерами, т.к. мы не хотим, чтобы сертификат устанавливался на сервера и технологические системы) и в контекстном меню выберите Create a GPO in this domain and Link it here…
Укажите имя политики (Install-Exchange-Cert) и перейдите в режим ее редактирования.
В редакторе GPO перейдите в раздел Computer Configuration –> Policies –> Windows Settings –> Security Settings –> Public Key Policies –> Trusted Root Certification Authorities (Конфигурация компьютера –> Конфигурация Windows –> Параметры безопасности –> Политики открытого ключа –> Доверенные корневые центры сертификации).
В левой части окна редактора GPO щелкните ПКМ и выберите пункт меню Import.
Укажите путь к импортируемому файлу сертификата, который мы разместили в сетевом каталоге.
В соответствующем шаге мастера (Place all certificates in the following store) обязательно укажите, что сертификат нужно разместить в разделе Trusted Root Certification Authorities (Доверенные корневые центры сертификации).
Политика распространения сертификатов создана. Возможно более точно нацелить ( таргетировать) политику на клиентов с помощью Security Filtering (см. ниже) или WMI фильтрации GPO.
Протестируйте политику, выполнив на клиенте обновление политик командой ( gpupdate /force ). Проверьте что ваш сертификат появился в списке доверенных сертификатов. Это можно сделать в оснастке управления сертификатами (раздел Trusted Root Certification Authorities -> Certificates) или в настройках Internet Explorer (Internet Options -> Content ->Certificates-> Trusted Root Certification Authorities или Свойства обозревателя -> Содержание -> Сертификаты -> Доверенные корневые центры сертификации).
Вы можете проверить, что в браузере при открытии вашего HTTPS сайта (в нашем примере это Exchange OWA) больше не появляется предупреждение о недоверенном SSL сертификате. Теперь при настройке Outlook на ваш почтовый сервер Exchange (в Outlook 2016 ручная настройки почтового сервера возможна только через реестр) в программе перестанет появляться окно с предупреждением о недоверенном сертификате.
Если вы хотите, чтобы политика распространения сертификата применялась только к компьютерам (пользователям) в определенной группе безопасности, выберите в консоли Group Policy Management вашу политику Install-Exchange-Cert. На вкладке Scope в секции Security Filtering удалите группу Authenticated Users и добавьте вашу группу безопасности (например, AllowAutoDeployExchCert). Если прилинковать эту политику на корень домена, ваш сертификат будет автоматически распространен на все компьютеры, добавленные в группу безопасности.
Одной политикой вы можете распространить сразу несколько клиентских SSL сертификатов. Подробную информацию о сертификатах, которые распространяются вашей политикой можно посмотреть в консоли GPMC на вкладке Settings. Как вы видите, отображаются поля сертификата Issued To, Issued By, Expiration Date и Intended Purposes.
Если на компьютерах нет доступа в интернет, таким образом вы можете распространить на все устройства домена доверенные корневые сертификаты. Но есть более простой и правильный способ обновления корневых и отозванных сертификатов в изолированных доменах.
Итак, вы настроили политику автоматического распространения сертификата на все компьютеры домена (на определенный организационной юнит или группу безопасности домена). Сертификат будет автоматически устанавливаться на все новые компьютеры, не требуя от служб техподдержки никаких ручных действий (в целях безопасности желательно периодически проверять списки доверенных сертификатов на клиентах на поддельные и отозванные).
Предыдущая статья Следующая статья 