Pki 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”

Источник

PKI, собственный CA для локальных веб ресурсов.

Доброго времени суток.

Пару дней пытаюсь изучить вопрос реализации локального центра сертификации, для внутри доменных веб-ресурсов (Zabbix, Glpi).

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

Прошу поделится «бест практикс» в решении подобной задачи. Какими методы можно использовать? Просьба поделится опытом.

Заранее благодарю, и с настующим комъюнити!

Тебе не нужен виндовый CA, openssl покроет твой функционал на 100500%

Сертификат это публичный ключ с некоторой доп инфой, т.е. за каждым сертификатом стоит публичный и приватный ключик. Для своего CA тебе надо:

1. Сгенерировать пару ключей для root сертификата и выпустить для них сертификат — это будет обычный самоподписанный (подписанный своим же приватным ключем) сертификат
2. Корневой сертификат . Без приватного ключа . добавь в список доверенных CA на все системы где собираешся использовать сертификаты которые будешь выпускать
3. Начинаешь генерить сертификаты для девайсов — генерации пары ключей, генерация на основе ключей запроса на новый сертификат (csr), выпуск сертификата (Подпись csr с использованием приватного root ключа)

Недавно открыл для себя Hashicorp Vault в качестве CA — очень удобно при условии автоматизации (т.к. JSON). Использую с ансиблом.

Openvpn предлагает easy-rsa. С gui есть xca. Сейчас имеет смысл получать от let’s encrypt. Вопрос в том, как их потом установить. Вручную, или через систему централизованного управления конфигурациями.

Прошу поделится «бест практикс» в решении подобной задачи.

гугл забит разного качества хаутушками. Какие ещё бестрпрактикс и сукесторис ты ждёшь?

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

Согласен, гугл забит. Но трудно отфильтровать годный гайд.

Один из хорошо и логично написанных — OpenSSL Certificate Authority

Сейчас имеет смысл получать от let’s encrypt.

А как быть, если локальный домен не зареган в сети?

Тогда никак. Поэтому стоит подумать об этом в самом начале, чтобы потом не переделывать. Получается примерно как с белыми и серыми адресами.

Промежуточный итог

Развернул локальный корневой/промежуточный CA. Проблем нету, все понятно.

При подписании сертификата локальной веб-службы, на выходе имею два файла:

Подскажите пожалуйста, требуется ли разворачивать сертификат веб-ресурса, и цепочки доверия на клиентской машине (Windows). Или же достаточно задеплоить на веб-сервер?

Заранее спасибо за ответ.

Получается на клиентские тачки, требуется установить сертификат промежуточного центра, или сертификат с цепочкой доверия?

Пункт 2 в первом ответе.

Упс, виноват. Спасибо.

Или же достаточно задеплоить на веб-сервер?

Если самоподписанный, то конечно нет.

Проблема ещё в чём. Браузеры могут и не использовать системное хранилище, особенно Mozilla.

В Firefox работает после добавления через настройки браузера. В IE работает после добавления в локальное хранилище. А chrome напрочь отвергает валидность сертификата.

Solved!

Вообщем, получилось разобрать в теме локального PKI. Прикрутил к парочке локальных серверов, работает!

Также разобрался в проблеме валидности сертификата, при обращении из Google chrome. Как оказалось, при генерации csr является обязательным указание поля SAN

В конфиге выглядит так

И хочу отметить один нюанс насчет csr-запроса из под виндузятни. При формировании запроса средствами IIS, также возникнет проблема валидности. Решением оказалось сформировать «кастомный» настраиваемый запрос через оснастку.

Вариантов на самом деле несколько:

1) можно красноглазить на чистом openssl. Придется вкурить теории(ее придется вкуривать в любом случае, хотя бы до понимания что такое «приватный ключ», «корневой сертификат», «промежуточный сертификат») и написать пяток bash-скриптов. Если есть много времени и желания понять как это всё работает изнутри и не боишься красноглазить — вариант неплохой. Да, в результате ты скорее всего тупо изобретешь велосипед, но зато его размер, вес и диаметр колес будут уникальны 🙂
2) easy-rsa из состава openvpn. Почти что вариант 1, только скрипты за тебя уже понаписали. Скрипты не так чтобы супер, но если нет желания красноглазить и пользоваться другими вариантами — вполне себе.
3) xca. Графическая оболочка. Кроссплатформенная, на Qt. Базу сертификатов пишет в файл, опционально шифрует. Если есть минимум знаний по теории, не хочется писать скрипты и при этом НЕ нужно выписывать сертификаты массово — вариант самый что ни на есть подходящий. Я в одной небольшой конторе использую — вполне себе
4) EJBCA. То, чем пользуйсь я на основной работе. Штука ынтерпрайзная, есть свое API, консольный клиент, веб-морда. Умеет в интеграцию с оффтопиковым Autoenrollment(сам не щупал, но кому-то может быть очень важно, если нет желания поднимать вендовый CA). Документация достаточно подробная. Из минусов — Java+Wildfly в качестве платформы куда он ставится. Если нет опыта с JBoss/Wildfly — готовься к тысячелетиям боли и чтению вороха талмудов, а также к правке километров xml-файлов. Щито поделать, ынтерпрайз он такой.

Был еще OpenCA, но он, увы, сдох.

Update: а еще надо бы мне взять на заметку дочитывать тред до конца, а то мои размышления тут особо уже и не нужны :-/

Ого, спасибо за представленные решения, и комментарий к каждому! Думаю ваш ответ будет хорошим толчком для тех кто в поисках подобного.

Источник

Про PKI «на пальцах» за 10 минут

Предложил коллегам провести внутреннюю мини-лекцию по сабжу — идея зашла. Сел писать план лекции и… чот психанул — в итоге очнулся, дописывая небольшой гайд. Подумал, что будет полезно добавить сюда что-то для быстрого понимания, что такое PKI, зачем она нужна и как работает, так как пока готовился, чтобы освежить память, искал информацию в том числе на полюбившемся «Хабрахабре», но статей в таком формате не нашел.

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

Без теории не обойтись

PKI (Public Key Infrastructure, инфраструктура открытых ключей) — это про безопасность. Подразумевается, что у каждой сущности в инфраструктуре есть свой ключ, которым она однозначно идентифицируется. То есть, если ключ украден, пострадавшей сущностью может представиться укравший. PKI нужна для того, чтобы оперативно минимизировать последствия такой кражи. Ключ представлен двумя частями: публичной и приватной.

Аналог — это RSA ключи для SSH, но инфраструктурой их назвать сложно, так как отсутствует централизованный механизм управления ими. Также разница в том, что публичная часть ключа в паре ключей для SSH неизменна, а сертификат (публичную часть ключа участника PKI) можно перевыпустить в любой момент.

В PKI существует один (на самом деле, должно быть минимум два) или несколько Certification Authority — центров сертификации (удостоверяющих центров), отдающих публичные части своих ключей клиентам, которым выдают подписанные ими сертификаты. Таким образом, участники инфраструктуры «понимают», кто ими управляет, и действителен ли сертификат, выданный им или их «товарищам», в настоящий момент времени (одним из важнейших атрибутов сертификатов является срок их действия). Либо же сервер, у которого есть публичная часть ключа CA инфраструктуры, в которой он и его клиенты работают, понимает, что к нему пришел клиент с действительным сертификатом, и разрешает ему что-то, или запрещает в противном случае.

OpenVPN: как это бывает

На самом деле во многих компаниях на этот случай уже есть «PKI» и у него есть имя, потому что это кто-то из сотрудников. Назовем такого человека, к примеру, Полуэкт (с) и расскажем, как обычно это работает, а потом я расскажу, как это должно быть в идеале.

При появлении в компании нового сотрудника Полуэкт создает и присылает ему архив, в котором, помимо конфигурации собственно OpenVPN клиента, находятся файлы (на примере сотрудника Иванова А.А.):

• a.ivanov-office.key — его приватный ключ, самая мякотка, которую нужно хранить как зеницу ока и никому не показывать (аналог в SSH — файл id_rsa);
• a.ivanov-office.csr — Certificate Signing Request, запрос на подпись сертификата, в котором описано, для кого нужно выписать сертификат, сгенерирован на основе предыдущего файла, чтобы не «палить» приватный ключ (для работы самого OpenVPN нафиг не нужен);
• a.ivanov-office.crt — вожделенный сертификат, который он предъявляет OpenVPN серверу, чтобы тот разрешил ему подключение (по сути это публичная часть ключа);
• ca.crt — сертификат нашего CA, чтобы OpenVPN клиент предъявил его серверу, чтобы тот сопоставил его с приватной частью, которая лежит у него, и убедился, что сертификат подписывал именно он, а не кто-то другой. «Деталька», которая обозначает принадлежность OpenVPN клиента Иванова А.А. к PKI, в которой работает сервер.

Это простые текстовые файлики в специальном формате PEM. Очень удобно, в отличие от, например, мозголомных Java Keystore или PFX от Microsoft: можно сливать сертификаты в один файл простым cat’ом для образования цепочек CA (так называемых bundle, что полезно для nginx, например, в конфигурации которого нет отдельной директивы для указания сертификата CA), можно совмещать сертификаты CA и свой, и даже свой приватный ключ, если зачем-то понадобится. И еще полезность: можно прописать сертификат CA прямо в конфигурации OpenVPN клиента, между тегами . Наверное, должно быть можно и сертификат прописать подобным образом. Впрочем, я уже отвлекаюсь на частности.

В компании Acme все эти файлы генерирует Полуэкт…

А теперь как должно быть

На моем примере, упрощенно:

я у себя локально генерирую свой приватный ключ (можно и, пожалуй, логично, использовать уже готовый из

/.ssh/id_rsa):

openssl genrsa -out openvpn.key 2048

• готовлю запрос на подпись сертификата — CSR, для чего заполняю небольшую анкету:

openssl req -new -key openvpn.key -out a.vrublevskiy-office.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter ‘.’, the field will be left blank.
——
Country Name (2 letter code) [XX]:RU
State or Province Name (full name) []:.
Locality Name (eg, city) [Default City]:Moscow
Organization Name (eg, company) [Default Company Ltd]:Pixonic
Organizational Unit Name (eg, section) []:Sysadmins Dept
Common Name (eg, your name or your server’s hostname) []:Alexander Vrublevskiy
Email Address []:a.vrublevskiy@pixonic.ru

Please enter the following ‘extra’ attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

(пароль в конце лучше не указывать, а то придется его вводить каждый раз при подключении, а VPN у нас по сертификатам как раз, чтобы этого не было; тем более у нас в Pixonic есть OTP от Google);

• отправляю получившийся файл a.vrublevskiy-office.csr Полуэкту;

• Полуэкт, получив мой запрос и имея обе части ключа CA (здесь — ca.key и ca.crt), выпускает для меня сертификат, подписывая его ключом CA (модные хипстеры пользуются easy-rsa, но мы суровые бородатые админы):

openssl x509 -req -in a.vrublevskiy-office.csr -CA ca.crt -CAkey ca.key -out a.vrublevskiy-office.crt -days 90

• Полуэкт отправляет мне получившийся файл.

Возникает резонный вопрос: к чему такие сложности? В чем «фишка» PKI? Отвечаю. Дело в том, что в этой цепочке фишка просто отсутствует. А называется она — CRL (Cerificate Revocation List). Это список отозванных сертификатов, который публикует CA, и в который Полуэкт может внести мой сертификат, выпущенный и подписанный ранее, в случае, если выяснилось, что, к примеру, я упоролся веществами и смог продиктовать свой приватный ключ конкурентам (ну или у меня украли ноут).

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

И про срок действия клиентского сертификата: если предположить, что я устроился в Pixonic по временному контракту на 3 месяца, и мы его не продлили, то в описанной ситуации мой доступ к VPN автоматически отключится через 90 дней с момента выпуска сертификата. Чего не случится с SSH-доступом, если коллеги забудут отключить аккаунт во FreeIPA или удалить строчку из authorized_keys руками. C — сесуриту.

Теперь по Борщеву HTTPS

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

Источник