Центр сертификации для linux

Простейший центр сертификации для 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”

Источник

Сертификат для Linux в центре сертификации Active Directory Certificate Services

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

В этой статье мы создадим правильный сертификат с указанием альтернативного DNS-имени, без которого программы могут возвращать ошибку сертификата.

1. Формируем файл запроса (на компьютере с Linux)

Для начала создаем каталог, в котором планируем хранить сертификаты и перейдем в него, например:

mkdir -p /etc/ssl/adcs

Создаем закрытый ключ:

openssl genrsa -out private.key 2048

* в данном примере создан 2048-и битный ключ с именем private.key

Создаем файл с описанием запроса:

[req]
default_bits = 2048
prompt = no
default_md = sha256
req_extensions = req_extensions
distinguished_name = dn

[dn]
C=RU
ST=SPb
L=SPb
O=Global Security
OU=IT Department
emailAddress=hostmaster@dmosk.ru
CN = *.dmosk.local

[req_extensions]
subjectAltName = @alter_name

[alter_name]
DNS.1 = *.dmosk.local

* где стоит обратить внимание на следующее:

• sha256 (или SHA-2) — алгоритм шифрования;
• *.dmosk.local — имя узла, к которому мы будем обращаться. Это очень важный пункт — нужно, чтобы имя совпадало с именем, по которому будут выполняться обращения. В данном примере создается wildcart (домен и все его поддомены)
• subjectAltName — альтернативные имена стали иметь значение с 2017 года, когда некоторые браузеры перестали принимать сертификаты без указания альтернативных DNS-имен.

Далее создаем ключ запроса сертификата:

openssl req -new -key private.key -out request.csr -config openssl.conf

* где private.key — закрытый ключ, который был сформирован на предыдущем шаге; request.csr — файл, который будет сформирован. В нем будет запрос на открытый ключ;

После выполнения команды, в каталоге появится файл request.csr. Выведем его содержимое, чтобы посмотреть запрос:

Должны увидеть что-то на подобие:

——BEGIN CERTIFICATE REQUEST——
MIIC1jCCAb4CAQAwgZAxCzAJBgNVBAYTAlJVMQwwCgYDVQQIDANTUGIxDDAKBgNV
BAcMA1NQYjEYMBYGA1UECgwPR2xvYmFsIFNlY3VyaXR5MRYwFAYDVQQLDA1JVCBE
ZXBhcnRtZW50MR4wHAYDVQQDDBVzaW1wbGVwbGFuLnNhdHMubG9jYWwxEzARBgNV
BAMMCnNpbXBsZXBsYW4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDZ
ze/WOQgnlbfzlEsQUsmfUTnkYq0rCpzgjY360lFvqek5Y8NIFX/25PRbUy4N3D8r
c/7mXt2dXmcnn7zeRQOB2g0AY8Wmeg3R6C+JH7TwxtkMj7FO8R59URxFN84lu9Sj
26Aw+Ax7474XnAoUBMSmUXbV2mAP5Xm83sjvjE1OcHXN8SPbc+EchZuLVLsIGXHz
Emz7V4D/ecahfSc2hCRG2Pc7SeFIADYdjyoLtykz5WyiIoXkpEfSNQHlt2/A1kJ5
h9/GPXMVJVL02FgsI5HIGZyGnYWA+cP7sHoEDZNpLHHuEtfwx3bLxJPFnZDa0rPO
LhV/ux1e6b9ikrge0xp9AgMBAAGgADANBgkqhkiG9w0BAQsFAAOCAQEAPVD2aVH8
ZDz+6s8ecKr08eT3mA9cRCa7dZYFj4/vO/ZYrDH9QS45gd0sYG+RN+JMGaFaY+X7
faE4m0BysPIbhEYLRY5GJYxmOGm05gM2HfPrcnnWXZbPQu/n5pR4ptvPYL7bilGb
z6hXb8ZtXUXwz1F2OgTPOPu4+w8lI23pzHRHlCXcVSoZxe/A2XwusB5MrtyMEYtj
rB2kcOqQRkt9uIv5IobwnYaVGDk/7wl/zkb9K+RKZt4izKfFaSSyPn7wvpKSIaAf
S3SQjJ0tBckLbtwKrxdFB0B8bpyIKUtHmpX/zOmityC8PLXe6/vQ/DmM3B6QC4Ba
KdnRkOSPv8BGog==
——END CERTIFICATE REQUEST——

2. Выпускаем сертификат

Копируем содержимое файла запроса (request.csr) и открываем веб-страницу центра сертификации — как правило, это имя сервера или IP-адрес + certsrv, например, http://192.168.0.15/certsrv/.

В открывшемся окне переходим по ссылкам Запроса сертификата — расширенный запрос сертификата.

В поле «Сохраненный запрос» вставляем скопированный запрос, в а поле «Шаблон сертификата» выбираем Веб-сервер:

Нажимаем Выдать и скачиваем сертификат по ссылке Загрузить сертификат:

3. Установка сертификата на Linux

Переносим полученный сертификат на компьютер с Linux, например, при помощи WinSCP.

После необходимо сконвертировать DER-сертификат (от AD CS) в PEM-сертификат (для Linux). Для этого вводим следующую команду:

openssl x509 -inform der -in certnew.cer -out public.pem

* где certnew.cer — файл, который мы получили от центра сертификации AD CS (как правило, у него такое имя); public.pem — имя PEM-сертификата.

Сертификат готов к использованию. Мы сформировали:

Источник

Удостоверяющий центр на основе OpenSSL

Когда работал системным администратором, возникла у меня необходимость реализовать VPN на несколько десятков филиалов компании, интранет и почту на серверах в Москве с суровой защитой и доступом через VPN вообще отовсюду. При этом придумать всю систему и организовать её развёртывание предстояло в одно лицо. Бюджет был в тысячи полторы долларов, было это 4 года назад, некоторое время честно пытался найти более-менее приемлемое по цене ПО, потом нечестно пытался найти что-то на торрентах – пусто. В итоге – OpenSSL и OpenVPN. В этом вводном тексте хотелось бы поговорить об OpenSSL.

В конечном итоге были развёрнуты:

• центр выдачи сертификатов (CA – Certificate Authority, он-же УЦ – Удостоверяющий Центр, в отечественной терминологии организация, уполномоченная выпускать сертификаты),
• интранет-сайт с авторизацией доступа по клиентским сертификатам,
• VPN с взаимной аутентификацией серверов, клиентов и динамической маршрутизацией,
• Авторизация клиентов на корпоративном IM сервере с помощью тех-же сертификатов.

Судя по всему, к настоящему моменту система умерла… не знаю, как долго она продержалась после моего увольнения, скорее всего до момента истечения корневого сертификата (т.е. 2 года от момента запуска).

Описанное далее будет интересно скорее корпоративным технарям, нежели обычным пользователям. При условии, если: организация не государственная, есть цель сэкономить, есть желание попробовать некоторые «штуки» не вбухивая в R&D сумму с шестью нолями.

Предполагается, что читающие знакомы с понятиями VPN (в данном случае Virtual Private Network) и SSL (Secure Sockets Layer) и тем, что из себя представляют электронные сертификаты в формате x.509.

В полученной системе сертификаты можно было обновлять, отзывать, использовать для аутентификации, шифрования кода, файлов, почты, а в случае компрометации отозвать ветку, не убивая весь CA. Для этого пришлось очень внимательно отнестись к файлам настройки OpenSSL, построить процедуру генерации списка отозванных сертификатов (CRL – Certificate Revocation List) и корректную иерархию в CA. Только тогда выбранная реализация позволяла использовать сертификаты, в т.ч. и в автоматических процессах, где некому было нажимать кнопку «Да, я всё равно доверяю этому сертификату, хотя он и просрочен и выпущен неправильно и вообще не для этого предназначен».

Важно помнить (как оказалось), что выпуск и использование сертификатов электронной цифровой подписи это не только технический, но и организационный процесс, без которого преимущества использования подобного рода защиты сходят на нет. Диск с УЦ, к примеру, после выпуска всех сертификатов, лучше вынуть или отключить (если он USB) и убрать в сейф. И журнал завести.

Для интранет-сайта (первый эшелон – Apache, что там за ним было – не суть важно) была реализована многофакторная аутентификация. Обычно первым и единственным фактором при аутентификации выступает знание логина и пароля или логина и пин-кода; представляется серверу только клиент, а серверу не нужно доказывать что он — это он, отсюда возможность воровства логина/пароля и/или подмены сервера. В моём случае это было неприемлемо, поэтому к знанию логина/пароля добавилась необходимость иметь сертификат. Выгружались сертификаты из CA в формате PKCS12 (PFX) с паролем.

В конфиг сервера было добавлено что-то вроде:

SSLOptions +FakeBasicAuth +StdEnvVars
SSLVerifyClient require
SSLVerifyDepth 2
SSLRequire % in <"My LTD OpenSSL CA">

Т.е. разрешить всем, чей сертификат выдан My LTD OpenSSL CA (в реальности, конечно, название другое)

Также можно ограничить доступ по именам:

SSLOptions +FakeBasicAuth +StdEnvVars
SSLVerifyClient require
SSLVerifyDepth 2
SSLRequire % in <"Ivan A Ivanov", \
«Petr B Petrov»>

В логи сервера пишется с помощью вот такой вот конструкции:

Распространение сертификатов

Полученный сертификат вместе с ключами устанавливали на компьютере пользователя (в реестр, зашифрованным на пин-коде), очень частый случай, при этом пользоваться сертификатом можно только на этом компьютере и в случае переустановки операционной системы сертификат, чаще всего, необходимо получать заново, если конечно закрытый ключ генерировался на компьютере, а не выдан вам на дискете при посещении УЦ, что можно считать профанацией с особым цинизмом, ведь по факту владельцами вашего якобы закрытого ключа становится (с возможностью проставлять за вас «электронную подпись») также и УЦ, а при определённом уровне разгильдяйства — все сменяющие друг друга админы в УЦ. Зато у УЦ появляется возможность предоставлять сервис по «восстановлению» сертификата.

Т.к. я был сам себе УЦ, то был избавлен и от такого «сервиса» и от копирования сертификатов «на память» техническими специалистами (и не очень).

Разъездным сотрудникам сертификаты выдавались на аппаратном носителе – USB-ключе Aladdin. Банки и УЦ предлагали (и предлагают) юридическим лицам для этой цели использовать дискеты или современный вариант — флешки. Это более удобно, но приводит к другой опасности — возможности сделать дубликат. В идеальном случае ключи и сертификаты должны храниться на смарт-карте, которая дополнительно защищена pin-кодом, имеет собственный крипто-процессор на борту, генератор случайных чисел, который, как считается, сильно понижает шансы потенциальных взломщиков, буде те решаться подобрать ваш ключ. Кроме того, смарт-карты практически не поддаются копированию.
USB-ключи Aladdin eToken как раз и являются такими картами, только в виде USB-брелка.
В случае аутентификации шифруется лишь небольшой объём данных, необходимый для процедуры, но при желании можно шифровать и весь трафик между клиентом и сервером. В случае, если сертификат нужно использовать для шифрования на сервере с большим количеством клиентов, в сервер нужно ставить уже что-то посерьёзнее например, крипто-плату, бесплатный IBM HTTP Server (тот-же Apache, фактически), даже какое-то их количество поддерживает.
Никто конечно не мешает использовать смарт-карты, которые выглядят как обычные пластиковые карты, но тогда на каждом рабочем месте, на котором такую карту нужно будет использовать, должен стоять картридер.

После того, как мы получили у УЦ сертификат, поместили его на «токен», и закрыли токен пин-кодом, мы получаем возможность выполнить двухфакторную двустороннюю аутентификацию. Фактор первый — мы имеем токен, фактор второй — знаем от него пин-код. А имея сертификат можем выполнить проверку, что сервер действительно тот, за кого себя выдаёт, в этом случае bobik.ru и bоbik.ru уже спутать не получится, потому, что русская «о» во втором варианте даст несовпадение имени (для компьютера это всё-таки разные буквы).

Списки отозванных сертификатов

Благодаря тому, что в настройках сервера был прописан (и регулярно обновлялся) список отозванных сертификатов (CRL), всегда можно было оперативно приостановить доступ к сайту любого пользователя, в т.ч. в случае потери (или подозрения на потерю) USB-ключа, либо при увольнения сотрудника.

Многие отечественные CA местоположение CRL указывают, а выкладывать или обновлять сам список «забывают», и когда, скажем, тот-же Outlook не может проверить сертификат по списку отозванных и вывешивает предупреждение, консультант в CA по телефону может предложить вам это предупреждение проигнорировать. В случае, если клиентом является другой сервер, при невозможности проверки сертификата, он просто будет разрывать подключение.

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

Доводка OpenSSL

В общем всем понятно, что сертификат – штука хорошая, осталось правильно его выпустить. После довольно продолжительной обкатки и изучения «документации» в несколько сотен страниц (на самом деле это был учебник по PKI и криптографии от «Интуита») выяснилось, что имеющиеся в инете на тот момент примеры конфигурации OpenSSL пригодны только для целей «на поиграться», я некоторое время сталкивался с тем, что выпущенные мной сертификаты то не работали в Outlook, то в Thunderbird, то в Firefox. Самым всеядным оказался IE.

Чтобы всё было чуть серьёзнее нужна небольшая рихтовка:

• если вы хотите, чтобы ваша система прожила больше года, перед выпуском корневого сертификата CA увеличьте количество дней до 3650, потом верните обратно, для пользовательских сертификатов лучше оставить год или полгода
• в секции [ CA_default ]
  выставить параметр unique_subject в «yes» — это не позволит вам выпустить 2 идентичных сертификата
• в секции [ user_cert ]
  добавить
  ExtendedKeyUsage = clientAuth
• секция для серверов может выглядеть так
  [ server_cert ]
  basicConstraints = CA:FALSE
  nsCertType = server
  keyUsage = digitalSignature, keyEncipherment
  extendedKeyUsage = nsSGC, serverAuth
• в секции [ v3_ca]
  изменить
  basicConstraints = CA:TRUE, pathlen:5
• раскомментировать nsCertType и keyUsage
• добавить
  extendedKeyUsage = serverAuth, clientAuth

Как водится – готовый конфиг.

Источник