Простейший центр сертификации для 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”
Источник
Удостоверяющий Центр на базе OpenSSL, SQLite3 и Tcl/Tk
Представлен проект удостоверяющего центра CAFL63, созданного на базе утилиты OpenSSL, использующего СУБД SQLite3 для поддержки базы данных и имеющего развитый графический интерфейс на базе Tcl/Tk. УЦ создан с учетом требований Федерального закона от 6 апреля 2011г. №63-ФЗ «Об электронной подписи», а также «Требований к форме квалифицированного сертификата ключа проверки электронной подписи», утвержденных приказом ФСБ России от 27.12.2011 № 795. Дистрибутивы УЦ доступны для платформ Linux и Windows.
развитый графический интерфейс на базе Tcl/Tk
«Хлорид кальция!» (с) он еще и развитый.
UPD: Глянул на скрины. Жесткач в чистом виде! Персиковые табы на голубом фоне.
Не, что-то это за гранью добра и красоты. Тридцать лет назад формочки DBase и то симпатичнее смотрелись. Судя по выбору инструментов, кому-то курсовую работу надо было написать.
Во-первых, что такое удостоверяющий центр?
развитый графический интерфейс на базе Tcl/Tk
По прочтении сего плакал. Лет десять назад реакция была бы той же.
Господи, зачем я прошел по ссылке. Это точно не запоздалая первоапрельская шутка? Или запоздалая на пару десятилетий серьезная новость.
Ну цвета там и в самом деле такие, хм, странные. Кроме того, для реального использования такая система всё-равно не годится, по крайней мере пока решение не будет официально сертифицировано. Однако описанный опыт тоже интересен.
Это далеко не все. Автор знает толк в Tcl/Tk:
Уважаемый автор, при всем уважении к Вашему возрасту, вы как-то сильно отстали от развития IT в целом и Linux в частности. Софт не распространяют в rar архивах с инструкцией как из-под рута его положить в систему. И кстати, архивы для Linux похоже битые.
Зачем это если есть XCA?
А где можно исходники скачать?
Ой да ладно. Больштнство линукс-разработчиков настолько ленивые, что вовсе не делают гуй
После просмотра скринов, глаза начали слезиться кровью..
а зачем ему gui?
и что вообще такое *удостоверяющий центр*, что он делает?
Исходников нет. Лицензия не указана. Переместите в раздел Проприетарное ПО.
Вот это куй знает, тема сисек не раскрыта автором до конца.
Хотя наврал раскрыта по ссылке нужно пройти. Судя по цветам, автор походу любитель кислоту закидывать.
Вспомнил FoxPro и прослезился. Кстати почему часть по русски, а часть интерфейса на английском? «Netscape Type» И дико радует ветеран.
Хардкорно. Когда решу присесть на наркоту, обязательно проконсультируюст с автором, он, явно, знает толк.
Присоединяюсь к вопросу — что подразумевается под словосочетанием «удостоверяющий центр»?
Ооооо. чччёёёрт!
Не. Ну автор, ну предупреждать хоть надо что по ссылке лютый п*ц!
Интерфейс? Да, на дворе шёл 2018 год и рота красноармейцев.
Но, в принципе, это мелочи. Ладно.
Во-первых, что такое удостоверяющий центр?
Это некая такая контора или отдел в конторе, чей открытый сертификат достаточно широко известен и распространён, а честность либо неоспорима, либо в принципе не подвергается сомнению. Далее УЦ (в классике CA) своим ключом подтверждает выпускаемые им сертификаты. Здесь предполагается что есть запросы на сертификаты от юрлиц и от физлиц, а УЦ выпускает для них сертификаты, которыми в дальнейшем юр- и физлица пользуются, например, на веб-сервере для организации https. Ну или для работы с сайтом «Госуслуги», что не столь суть в данном случае. Это всё что нужно знать об УЦ и нахрен он нужен.
В данном случае, на основании «Требований к форме квалифицированного сертификата ключа проверки электронной подписи», эти сертификаты будут нести в себе определённую информацию, что, без сомнения, является нужным, важным и полезным делом.
Но, Господи. Ну зачем так насиловать обслуживающий персонал УЦ? Ведь уже есть проект boulder от того же EFF (да, более известный как Let’s encrypt), для которого уже есть открытый протокол ACME, позволяющий создавать и использовать короткоживущие сертификаты (90 суток по умолчанию) в полностью автоматическом режиме?
Исходный код сервера https://github.com/letsencrypt/boulder Да, хипстота сейчас возбудится, он на Go.
Т.е., «сервер» УЦ, пригодный при необходимости к работе в полностью автоматическом режиме есть? Есть. «Протокол» и его реализация для клиентов есть? Есть.
Что там остаётся-то? Нарисовать пару формочек для одобрялки-отклонялки/генерации сертификата/вывода списка сертификатов как валидных, так и отозванных и т.д. и т.п.? Нарисуйте их на чём угодно. Хоть на tcl/tk, хоть на пистоне, да хоть на чём. На том же С с GTK+ или C++ c Qt! Это-то не проблема же!
Дальше. А скажите, на хер там персональная СУБД типа SQLite? Т.е., в УЦ должен быть один и только один компьютер, на котором выпускаются сертификаты? А, если их будет два или, о ужас, не дай Бог, три? Что тогда делать? Организовать перенос данных между компьютерами такого «УЦ» на, дайте угадаю, USB-флешке? Что, Вы это. серьёзно? В 2018г.? Ну тот же boulder использует MariaDB, считай, MySQL. Т.е., доступ к сертификатам может быть организован для персонала по внутренней сети УЦ без лишнего невразумительного секса.
В общем, тут кроме гуйни какая-то херня и по архитектуре и по реализации.
И да. Чтоб мне тут два раза не вставать, я сразу скажу что основная проблема не в функционировании УЦ. Не в том, на чём там сервер и/или гуйня написана. основная проблема УЦ в том, чтобы убедить окружающих что данная контора, выпустившая данный сертификат, заслуживает доверия. Вот тогда сертификат данного УЦ будет внесён в корневые и не будет на клиентах вылетать предупреждений типа что сертификат хрен его знает чей, требуется подтверждения исключения пользователем. Но это уже другая история и за другие деньги.
В общем и целом как тренировочный подход принять можно, но попытка не результативна.
Про УЦ в ответе ниже.
Это некая такая контора или отдел в конторе, чей открытый сертификат достаточно широко известен и распространён, а честность либо неоспорима, либо в принципе не подвергается сомнению. Далее УЦ (в классике CA) своим ключом подтверждает выпускаемые им сертификаты. Здесь предполагается что есть запросы на сертификаты от юрлиц и от физлиц, а УЦ выпускает для них сертификаты, которыми в дальнейшем юр- и физлица пользуются, например, на веб-сервере для организации https. Ну или для работы с сайтом «Госуслуги», что не столь суть в данном случае. Это всё что нужно знать об УЦ и нахрен он нужен.
Про УЦ в ответе ниже.
Во-первых, что такое удостоверяющий центр?
Это некая такая контора или отдел в конторе, чей открытый сертификат достаточно широко известен и распространён, а честность либо неоспорима, либо в принципе не подвергается сомнению. Далее УЦ (в классике CA) своим ключом подтверждает выпускаемые им сертификаты. Здесь предполагается что есть запросы на сертификаты от юрлиц и от физлиц, а УЦ выпускает для них сертификаты, которыми в дальнейшем юр- и физлица пользуются, например, на веб-сервере для организации https. Ну или для работы с сайтом «Госуслуги», что не столь суть в данном случае. Это всё что нужно знать об УЦ и нахрен он нужен.
Интерфейс настолько похож на xca, что кажется если бы не вырвиглазный салатно-голубой цвет, бьющий по глазам, то проект был бы вообще не нужен.
Присоединяюсь к вопросу — что подразумевается под словосочетанием «удостоверяющий центр»?
Я все таки сходил по ссылке и поглядел. Это просто гуй к openssl ( к примеру чтобы не вспоминать команду openssl x509 -text -in servername.crt ) и поскольку там тикл скорее всего на пистоне.
Кстати не совсем понял зачем ЭТО нужно для винды вроде у них было какое то хранилище сертификатов.
Это некая такая контора или отдел в конторе, чей открытый сертификат достаточно широко известен и распространён, а честность либо неоспорима, либо в принципе не подвергается сомнению.
Вообще то свой сертификат если ВЫ хотите чтобы ему доверяли ВЫ должны подписать в центре сертификации.
Источник
