83. Самоподписанный SSL сертификат с помощью XCA - X Certificate and Key management.

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

Вкратце о сути вопроса.

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

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

Теория.

Напомним что работа сертификатов основана на принципе доверия и для проверки использует механизм цепочки - chain.

В мире есть несколько признанных организаций, которые выступают в роли доверенных авторитетов — это так называемые корневые центры сертификации (Root Certificate Authorities). Их задача — выдавать и управлять корневыми сертификатами, которые являются основой всей системы доверия в интернете. Именно их корневые сертификаты предустановлены в операционных системах, браузерах и на других устройствах.

Так же существуют промежуточные центры сертификации (Intermediate Certificate Authority). Их деятельность контролируется корневыми центрами.

Для чего это нужно?

• Безопасность: Корневые сертификаты крайне важны, поэтому их редко используют напрямую. Если что-то случится с промежуточным центром (например, его компрометируют), его сертификат можно отозвать, не затрагивая корневой.

• Упрощение управления: Один корневой центр может создать несколько промежуточных, каждый из которых специализируется, например, на различных типах сертификатов или регионах.

• Гибкость: Промежуточные центры позволяют выстраивать сложные иерархии для крупных организаций и инфраструктур.

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

Перед выдачей сертификата промежуточный центр сертификации проводит процесс проверки подлинности домена (Domain Validation, DV), организации (Organization Validation, OV), или расширенной проверки (Extended Validation, EV).

Например:

• В случае Domain Validation проверяется только право владения доменом. Обычно это делается через email, DNS-запись или файл, загружаемый на сервер сайта.
• Для Organization Validation проверяется не только домен, но и юридическая информация о компании, указанной как владелец сертификата.
• Extended Validation требует ещё более строгую проверку, включая личность заявителя, его связь с компанией и другие юридические аспекты.

Сертификат используемый на сервере называют End-Entity Certificate или Leaf Certificate, т.к. это и есть последняя сущность в цепочке доверия, или же листик на дереве у которого есть ствол и ветви.

Таким образом, каждый сертификат гарантирует, что домен действительно принадлежит владельцу, указанному в заявке, что предотвращает атаки типа man-in-the-middle и позволяет пользователям доверять соединению.

HTTPS в сети.

В итоге, имеем следующую ситуацию:

Некий Кто-то, купил себе домен в интернете чтобы открыть онлайн магазин. Купил в промежуточном центре сертификации сертификат, подтвердив своё право на владение указанным доменом. После того как закончил работать над сайтом добавил к нему купленный сертификат.

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

Перейдём ближе к проблеме.

В домашней сети используются частные IP-адреса (например, 192.168.x.x или 10.x.x.x), которые не маршрутизируются в интернете. Эти адреса предназначены только для локального использования и не могут быть подтверждены внешним центром сертификации. Грубо говоря, у каждого может быть дома своя сеть в диапазоне частных адресов, и нет возможности подтвердить что у того или иного адреса владельцем является именно Пользователь1 из одного города, а не Пользователь2 из другого города или даже соседней квартиры.

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

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

Практика.

После того как стало ясно что надо сделать, надо определиться с тем, как сделать задуманное. В предыдущей статье на эту тему, была описана процедура с помощью командной строки приложения OpenSSL. На этот раз обратимся к программе с графическим интерфейсом - X Certificate and Key management.

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

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

Прежде чем начать работу, несколько слов о главном принципе этой программы, за который огромнейшее спасибо её автору. А именно - шаблоны. Все настройки могут быть сохранены в шаблоны, из которых будут генерироваться нужные сертификаты. Коих, как уже известно, для полноценной и правильной работы нужно 3 штуки.

Поэтому подготовим 3 шаблона, по одному для каждого сертификата.

Создание шаблонов.

Идём на закладку шаблонов и создаём новый.

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

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

На вкладке расширений укажем что это будет центр сертификации. А так же укажем срок годности и в какое время он закончится.

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

На закладке Netscape убираем вообще всё.

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

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

На вкладке расширений укажем что это конечный сертификат и так же его срок годности.

Самый важный момент!

В строке Subject Alternative Name необходимо перечислить адреса домашней сети, на которые будет распространяться этот сертификат. Нет, нельзя указать маску или сделать copy/paste, придётся немного посидеть, но оно того стоит. Кроме айпи, можно указать адреса с использованием домашнего домена если такой имеется. К примеру если есть домен .myhome, и есть какой-то сервер роль и адрес которого это тестовая машина, то можно указать test.myhome в качестве ДНС имени.

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

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

Убеждаемся что на закладке Netscape ничего не выбрано и не написано и сохраняем. Шаблоны готовы, можно приступать к самому главному.

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

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

ROOT CA

Начнём по порядку, поэтому выбираем первый шаблон и применяем сохранённые в нём настройки ко всем полям (Apply all). Т.е. по сути, копируем заранее заложенные в него параметры в новый сертификат.

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

После чего жмём ОК и можно двигаться дальше, т.к. корневой ЦС готов.

Важно!!!

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

INTERMEDIATE CA

Создадим промежуточный ЦС.

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

Применяем настройки шаблона (Apply all) и на вкладке объекта создадим ключ для этого сертификата по аналогии с предыдущим шагом. Не рекомендуется использовать ключ корневого ЦС, пусть у этого будет свой.

End-Entity Certificate.

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

Применяем настройки шаблона (Apply all) и на вкладке объекта создадим ключ для этого сертификата по аналогии с предыдущим шагом. Готово.

Сохранение сертификатов.

Повторим что нам понадобится и где.

- Корневой ЦС - не обязателен, но возможен на каждом клиентском устройстве.

- Промежуточный ЦС- обязателен на каждом клиентском устройстве.

- Итоговый сертификат - на сервере.

- Ключ итогового сертификата - на сервере.

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

Промежуточный ЦС экспортируем таким же образом. Чтобы избежать недопонимания и расхождения с предыдущей статьёй, это тот самый ca.pem

Итоговый сертификат экспортируем в виде цепочки доверия.

Чтобы избежать недопонимания и расхождения с предыдущей статьёй, это тот же самый файл  fullchain.pem, получившийся из объединения cert.pem и ca.pem. Поэтому итоговый файл можно сразу сохранить под таким именем.

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

На вкладке ключей экспортируем ключ сертификата в формат файла приватного ключа.

Чтобы избежать недопонимания и расхождения с предыдущей статьёй, это тот же самый cert-key.pem в дальнейшем переименованный в privkey.pem. Так что итоговый файл можно сразу сохранить под таким именем.

В итоге имеем:

- (возможный) файл корневого ЦС.

- ca.pem - промежуточный ЦС.

- fullchain.pem - цепочка сертификатов.

- privkey.pem - ключ цепочки.

Применение ЦС.

В среде Windows.

Открываем консоль MMC

И добавляем оснастку управления сертификатами текущего компьютера

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

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

По аналогии импортируем промежуточный ЦС.

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

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

Ну или же можно воспользоваться уже упомянутым способом из первой статьи:

через PowerShell (конечно же запущенной с админскими правами), командами

Import-Certificate -FilePath "C:\certs\root.pem" -CertStoreLocation Cert:\LocalMachine\Root

и

Import-Certificate -FilePath "C:\certs\ca.pem" -CertStoreLocation Cert:\LocalMachine\CA

Или же из командной строки (так же запущенной с админскими правами):

certutil.exe -addstore root C:\certs\root.pem

и

certutil.exe -addstore CA C:\certs\ca.pem

Заключение.

В чём явный плюс данного метода?

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