Простейший центр сертификации для Linux
Все мы рано или поздно сталкиваемся с тем что нужно выдавать сертификаты для защищенных протоколов HTTPS, IMAPS, SMTPS, для создания VPN-подключений или для подписи почтовых сообщений. В этой статье я опишу настройку простейшего центра сертификации (одноуровневой иерархии PKI), сразу замечу – это не лучший вариант для продакта, но это базис с которого лучше все начать разибираться с PKI.
Настройку PKI будем рассматривать на базе Centos 6.3, главным действующим лицом станет фирма с громким названием ООО “Руки и ноги” или по английски OOO “Hands and Feets”, у этой фирмы есть свой веб сайт ca.handsandfeets.ru, через который она будет распространять CRL.
1. Чуть-чуть теории
Прежде чем приступать к настройке стоит разобраться в нескольких основополагающих вопросах.
Что такое сертификат? Сертификат – это набор полей в формате x.509, содержащий идентификатор субъекта (например, имя пользователя или компьютера), время действия, имя издателя, назначение, используемые алгоритмы хеширования и шифрования, правила проверки подлинности и открытый ключ, а также цифровую подпись, которая позволяет удостоверить подлинность и целостность сертификата.
Как формируется цифровая подпись? От всех значащих полей сертификата считается хеш-функция и шифруется закрытым ключом центра сертификации. В само-подписанных сертификатах или сертификатах корневого центра сертификации результаты хеш-функции шифруются закрытым ключом непосредственного субъекта сертификации.
Как проверяется сертификат? Предположим, мы подключаемся к веб-серверу по протоколу https и получаем его сертификат.
- Проверяем его срок годности.
- Проверяем находится ли ЦС которым был выпущен сертификат, списке доверительных ЦС на нашем ПК.
- Проверяем подпись сертификата, те считаем заново хеш-сумму от всех значащих полей сертификата, расшифровываем цифровую подпись сертификата при помощи открытого ключа ЦС и сравниваем с нашей хеш-суммой, если совпадает – значит сертификат действительный.
- Если в сертификате указана точка распространения списка отзыва сертификатов (CDP), то забираем от-туда список отзыва сертификатов (CRL), проверяем его цифровую подпись и отсутствие в этом списке нашего сертификата.
- Проверяем дополнительные поля, например, может ли этот сертификат использоваться для шифрования веб-трафика.
Этот процесс нужно очень хорошо понимать.
Что такое центр сертификации? Центр сертификации (ЦС) – это некоторый набор софта, главная функция которого выдача, контроль и отзыв сертификатов. Каждый ЦС имеет свой сертификат и закрытый ключ. Закрытый ключ нужно хранить как зеницу ока, потому что он используется для подписи всех выдаваемых сертификатов и списков отзыва (CRL). Cертификату ЦС должны по априори доверять все компьютеры в сети.
Что такое PKI? PKI (Public Key Infrastructure, Инфраструктура Открытого Ключа) – это набор средств и правил необходимых для поддержания иерархии сертификатов. Проще говоря – это совокупность сертификатов, правил их выдачи и отзыва, правил хранения ключей, центров сертификации и тд.
Что такое одноуровневая PKI? Одноуровневая иерархия PKI – это наиболее простое решение для управления сертификатами, это один корневой центр сертификации, который подписывает все выдаваемые сертификаты организации. Недостаток одноуровневой системы заключается в недостаточной защищенности, возможности компрометации закрытого ключа корневого центра сертификации.
2. Настройка корневого ЦС
Переходим в директорию /etc/pki/CA, с этого момента она станет нашей рабочей директорией и все 100% действий мы будем делать в пределах нее.
Создаем необхоимые для работы файлы, в index.txt будут записываться все выдаваемые сертификаты, в файлах serial будет храниться последний серийный номер выданного сертификата, а в crlnumber номер последнего списка отзыва сертификатов. Кажется мелочь, а работать без них ничего не будет.
Создаем директорию request, в нее мы будем складывать запросы на подпись сертификата.
Копируем файл с настройками центра сертификации и переходим к его редактированию.
Хочется заметить, что конфиг у openssl не очень-то маленький и парой строчек его не опишешь, поэтому чуть позже я рассчитываю написать отдельную статью, о том какие параметры и для чего нужны. Для этого примера нас вполне устраивает базовый конфиг openssl, нужно только немного его подправить, что бы все заработало как нужно. Дальше привожу те параметры которые нужно добавить, разкомментировать или изменить.
Теперь создадим сертификат корневого ЦС сроком на 5 лет, он спросит у нас пароль что бы зашифровать закрытый ключ и предложит заполнить несколько полей, в принципе немного раньше мы задали для них значения по умолчанию, поэтому смело щелкаем Enter, за исключением Common Name (CN) туда мы вводим полное название нашего ЦС OOO Hands And Feets Certification Authority.
Создадим список отзыва сертификатов (CRL), пока он будет пустым. Однако очень важно что бы он существовал и был доступным, если клиент не сможет получить CRL, то сертификат скорее всего будет признан недействительным. После запуска openssl запросит пароль от закрытого ключа ЦС необходимый для подписи CRL.
Теперь нужно опубликовать в интернете сертификат ЦС и список отзыва. У фирмы ООО “Руки и ноги” есть сайт ca.handsandfeets.ru, для простоты эксперимента предположим, что у нас настроен VirtualHost на сервере Apache, который перенаправляет все запросы с ca.handsandfeets.ru в директорию /var/www/html/pki. Настройка Apache более подробна описана в статье “Настройка NameVirtualHost”. Создадим две символические ссылки.
В итоге у нас получился полностью работоспособный корневой центр сертификации.
3. Работа с сертификатами
Что делать с центром сертификации дальше? Здесь мы рассмотрим две основополагающие функции, то для чего нужен ЦС – это выдача и отзыв сертификатов.
3.1 Выдача сертификатов
Предположим что нам нужно выдать сертификат для защищенного при помощи SSLv3 сайта sslpdm.handsandfeets.ru. Создадим запрос к центру сертификации, как и при создании корневого ЦС он задаст нам кучу вопросов, мы на все щелкаем Enter, а в Common Name вводим имя узла sslpdm.handsandfeets.ru
Отправляем запрос на сертификат sslpdm.handsandfeets.ru.csr на подпись в ЦС и на выходе мы получим готовый подписанный сертификат. Для подписи потребуется ввести пароль закрытого ключа ЦС и дважды согласиться щелкнув y.
Сертификат для сервера sslpdm.handsandfeets.ru будет лежать в файле certs/sslpdm.handsandfeets.ru.crt, а закрытый ключ в файле private/sslpdm.handsandfeets.ru.key.
3.2 Отзыв сертификатов
Следующая задача отозвать скомпрометированный сертификат веб-сервера sslpdm.handsandfeets.ru. Первой командой мы помечаем сертификат в базе ЦС как отозванный, а второй обновляем список отзыва сертификатов CRL. Для выполнения обоих команд потребуется пароль от закрытого ключа ЦС.
4. Чуть-чуть заключения
Помнится наверно лет пять назад я наткнулся на длинную статью о том как настроить почтовый сервер на базе postfix и courier-imap, в ней якобы обязательным условием для запуска сервисов была генерация соответствующих сертификатов. Тогда вся работа с openssl показалась мне кучей шаманских действий, и в итоге я эту статью отложил и сделал по другой. Честно говоря этот маневр всего лишь немного оттянул время, и в конце-концов мне пришлось сначала генерировать самоподписанные сертификаты, а потом через еще какое-то время строить полноценную PKI.
Не забывайте цифровые сертификаты – это очень нужная и важная штука
5 Коммент. : “Простейший центр сертификации для Linux”
Источник
Корневой сертификат удостоверяющего центра Active Directory на станции Linux
Задача — Корневой сертификат удостоверяющего центра AD-CA на Linux
Условие1. поднять PKI-AD, при этом корневой центр сертификации должен быть установлен на отдельной станции ROOT-CA.
Условие2. так как станция ROOT-CA используется крайне ограниченные время и только на выпуск CRT и CRL, то на 99% станция находится отключенном состоянии, бюджет на данную станцию равен нулю.
Размышления
Размышления крайне просты: для экономии бюджета PKI-AD будет установлена непосредственно на сервер Active Directory, а вот ROOT-CA требуется поднять на Linux.
Далее по тексту:
ROOT-CA – станция либо сертификат корневого центра.
PKI AD-CA – станция с ролью “Службы сертификатов Active Directory”
Решение
Подготовка ROOT-CA. (CentOS7)
Корневой сертификат ROOT-CA, будем выпускать на CentOS, там-же будем подписывать сертификат для PKI AD-CA.
Для решения данной задачи на машине с Linux необходимо установить пакет easy-rsa, который содержится в репетиторе epel-release
yum install epel-releas
yum install easy-rsa
Более подробно с документацией к easy-rsa можно ознакомится на GitHub/OpenVPN
После того как мы установили easy-rsa мы можем создать главный удостоверяющий центр сертификации.
(Все операции буду выполнять из под пользователя root)
Создадим в директории пользователя, каталог — в котором будем хранить наш PKI
Далее нужно скопировать последнюю версию easy-rsa в наш каталог ROOTca,
В моём случаи последняя версия 3.0.8. Её и будем копировать.
Копируем easy-rsa в каталог ROOTca
cp -R /usr/share/easy-rsa/3.0.8/*
теперь нам необходимо создать файл ответов vars, и отредактировать его
создаем и сразу редактируем
собираем файл vars, у меня получилось так:
Теперь все готово, можно начинать!
Внимание! Вовремя всех действий, вы должны находится в директории ROOTca
Инициализируем наш центр сертификации
Отлично, мы готовы выпустить наш ROOT-CA
Выпускаем
Система попросит придумать пароль для секретного ключа нашего ROOT-CA
(для наших задач, пароль должен быть не менее 4 символов)
Проверяем параметры выпускаемого сертификата, они берутся из vars, соглашаемся либо меняем на нужные.
. В какой-то момент система спросит название “Common Name”. Это название будет основным названиям нашего сертификата
Common Name (eg: your user, host, or server name) [Easy-RSA CA]: Указываем CompanyName Certificate 2021.
По окончанию мы получим корневой сертификат ROOT-ca нашего PKI
Он располагается пути /root/ROOTca/pki/ca.crt
Копируем корневой сертификат на станцию c PKI AD-CA
Сервер с PKI AD-CA (Windows Server)
Проверяем полученный файл на станции PKI AD-CA
Открываем ca.crt и проверяем содержимое
ca.crt
Все отлично! Переименуем ca.crt в ROOT-ca.crt, так как-то удобнее. Теперь нужно подготовить службу Центра сертификации Windows.
Устанавливаем роль “Службы сертификатов Active Directory”
в моем случае, устанавливаю “Службы сертификатов Active Directory” на отдельный ПК, все действия для PKI AD-CA идентичны
После установки переходим к настройке — Службы сертификатов Active Directory
Более детально с настройкой и установкой можно ознакомится на docs.microsoft.com
в момент настройки выбираем следующие опции:
Наш сервер будет- подчиненным ЦС
Нам нужно создать новый закрытый ключ
Шифрование — выбираем по вкусу
Указываем имя CA
Запрос сертификата — указываем через REQ файл
По окончанию настройки мы получаем следующее сообщение:
Хорошо, теперь у нас есть файл pki-ca_PKI-CA-CA.req
Копируем полученный файл на машину с Linux ROOT-ca в директорию /root/ROOTca/pki/
Все готово к выпуску сертификата для PKI AD-CA
Перед тем как выпустить сертификат нужно импортировать req файл в PKI
импортируем
./easyrsa import-req /root/ROOTca/pki/pki-ca_PKI-CA-CA.req CompanyName-AD
Где CompanyName-AD – название центра PKI AD-CA
Проверяем что получилось
./easyrsa show-req CompanyName-AD
Пора выпустить сертификат для CompanyName-AD
./easyrsa sign-req ca CompanyName-AD
Так как мы выпускаем сертификат для “Центра сертификации” указываем именно ca, если нужно выпустить на отдельный сервер указываем server.
мы получили наш сертификат для PKI AD-CA по пути /root/ROOTca/pki/issued/CompanyName-AD.crt
Копируем его на станцию с PKI AD-CA
Также нам нужны списки отзыва CRL, с генерируем и их
(Напоминаю что действия наших списков 92 дня см файл vars,в течении 92 дней нужно повторить операцию передачи CRL)
Копируем crl.pem также на станцию с AD-PKI
Сервер с PKI AD-CA (Windows Server)
Сейчас у нас есть все, что нам нужно.
Корневой сертификат: ROOT-ca.crt
Сертификат CA для нашего сервера: CompanyName-AD.crt
Списки отзыва: crl.pem
Импорт ROOT-ca
Нам нужно сделать ROOT-ca.crt стал валидным сертификатом в системе Windows, напоминаю, что сейчас он с крестом и нас, конечно, такой вариант не устраивает.
Запускам MMC-консоль и подключаем оснастку “Сертификаты” для учетной записи компьютера.
Переходим по пути: Сертификаты\Доверительные корневые центры\Сертификаты
Добавим наш сертификат ROOT-ca.crt в «Доверительные корневые центры»
Для этого правой кнопкой по папке “сертифкаты” -> импорт
Указываем путь к сертификату ROOT-ca.crt и импортируем его.
После импорта сертификат должен появиться в списке
Теперь, проверяем сам файл ROOT-ca.crt
Так-то куда лучше!
(Данный сертификат нужно также распространить через групповые политики, на все ПК в AD)
Импорт CRL.
Нам также нужно импортировать списки отзыва, для этого необходимо переименовать файл crl.pem в ROOTca.crl
(теперь можно изучить файл ROOTca.crl)
Импортируем его точно также как и сертификат в доверительные корневые центры ROOT-ca.crt
Активация PKI AD-CA
Теперь можно приступить к активации нашего CA PKI AD-CA
Запускаем средство «Центр сертификации»
Перед установкой сертификата в CA, лучше предварительно настроить публикацию CDP и AIA
Активируем CA
Правой кнопкой мыши по серверу PKI AD-CA > Все задачи > Установить сертификат ЦС
Далее, указываем файл CompanyName-AD.crt и подтверждаем.
Если мы все сделали правильно, установка сертификата в CA должна пройти без ошибок и предупреждений.
Если вы не можете импортировать CompanyName-AD.crt система просит P7B файл.
Необходимо выполнить слияние CompanyName-AD.crt с ROOT-ca.crt в OpenSSL следующей командой:
openssl crl2pkcs7 -nocrl –certfile ROOT-ca.crt -certfile CompanyName-AD.crt -out CompanyName-AD.p7b
Запуск PKI AD-CA
теперь мы можем запустить службу Центра сертификации
Правой кнопкой мыши по серверу PKI AD-CA > Все задачи > Запуск службы
Итог
мы получили рабочий PKI — Active Directory и можем начать выпуск сертификатов для пользователей, станций, серверов. При этом ROOT-ca находится на станции с Linux, и нам не пришлось отдавать под данную задачу отдельный сервер с Windows.
Источник
