Дисклеймер
В этой статье выражено личное мнение автора, его видение мира, его путь, и это все не претендует на абсолютную верность и объективность. Автор не несет никакой ответственности за последствия использования данной информации, он только надеется что эта информация поможет сделать кому-то жизнь проще.
Зачем нам все это надо?
Война… Война никогда не меняется… (с) Fallout
Да, война за свои данные никогда не меняется и не останавливается. Она идет каждую минуту, каждую секунду, каждый тик процессора.
Но к черту эту пафосную фигню, оставим это маркетологам по продаже продуктов по безопасности. Сегодняшняя статья маленькая, но надеюсь весьма полезная — как сделать себе сертификат подписанный своим собственным центром сертификации.
Чего НЕ будет в статье
- как настроить свой собственный центр сертификации
- авторизация по сертификатом
- внедрение x509
- какой-то экзотики связной с сертификатами
Что будет в статье
- как создать сертификат подписанный локальным сервером сертификации
- как создать сертификат даже при условии что система не умеет генерировать запрос
Кому интересно — прошу под кат
Идея этой статьи возникла уже давно, еще в те времена когда мы только начинали думать над своим собственным PKI. Мануалов как поставить свой центр сертификации было много, даже попадались весьма толковые, с объяснением что и как надо сделать. Но как правило, после установки центра сертификации (ЦС) начинается как раз самое веселое, которое почему-то обычно вообще не описывается. Ну или описывается отрывочно, в комментариях на форумах — ибо для тех кто понимает — это очевидно, а те кто не понимает… Тому приходиться туго =)
При генерации сертификата бывают два варианта простой и посложнее. Простой — система сама создала запроса, второй (посложнее) — система просто хочет от вас получить ключи. Так же есть веселый вариант когда вам нужно сделать сертификат для Linux-машин. Его тоже опишу.
Вариант 1. Простой
Приложение само умеет генерировать запрос на сертификат.
В этом случае мы получаем файл с расширением .csr или .req
Примечание: После создания в оснастке Exchange файла запроса .req, его нужно пересохранить в кодировке ANSI.
Чтобы получить заверенный сертификат нужно сделать следующее:
- Заходим на выдающий сервер (в зависимости от вашей конфигурации это может быть и корневой сервер сертификации)
- Запускаем из-под админа cmd
- Вводим CERTREQ -attrib «CertificateTemplate:WebServer» C:\%сert_patch%\%cert_name%.csr
attrib - это имя шаблона, по которому делается сертификат. Он определяет, что именно можно удостоверять этим сертификатом. Стандартно это проверка подлинности сервера, бывают еще проверка подлинности клиента, подпись кода, почта, еще много всякого разного C:\%сert_patch%\%cert_name%.csr - это путь к файлу запроса. Может быть csr (я так понимаю в основном *nix-системы) или req (я так понимаю windows)
- Вылезет окошко с выбором удостоверяющего центра:
- Если нам повезло и мы нигде не накосячили у нас появится окно с предложением сохранить файл с расширением .cer – это как раз то, что нам нужно – подписанная открытая часть.
- Полученный файлик мы скармливаем запросившему приложению и получаем правильный феншуйный сертификат у приложения.
Вариант 2. Сложный, но более гибкий.
Бывают случаи, когда приложение не умеет генерировать запросы и хочет получить в использование уже все готовое (открытый и закрытый ключ вместе)
С одной стороны это хуже, так как больше действий. С другой – лучше, мы можем забить больше нужной нам информации и правильных имен. Например, мы можем сделать красивый сертификат, который будет валидный при обращении как к короткому имений https://myserver так и по fqdn-имени https://myserver.company.local так и даже по ip https://192.168.0.3
Ну в общем так случилось, что приложение ничего не умеет, а сертификат ей все-таки нужен. В этом случае будем действовать так:
-
Создаем файл %name%.inf. В него вписываем:
[Version] -- Версия она и в Африке версия Signature="$Windows NT$" -- не знаю что это, возможно подскажут в комментариях [NewRequest] – надеюсь понятно без слов Subject = "CN=hardware.company.local"; --каноническое имя на которое выдается сертификат. В большинстве случаев оно и единственное. Если обращаться к сервису/железке не по этому имени (к примеру просто hardware), то сертификат будет считаться не действительным. Обходится прописыванием дополнительных имен (об этом ниже) Exportable = TRUE; -- обозначает можно ли выгружать приватный ключ. Если поставить false то этот сертификат можно будет использовать только на этом сервере. Никуда не унесешь KeyLength = 2048; -- длина ключа KeySpec = 1; -- не знаю что это, возможно подскажут в комментариях KeyUsage = 0xA0; -- не знаю что это, возможно подскажут в комментариях MachineKeySet = TRUE -- не знаю что это, возможно подскажут в комментариях ProviderName = "Microsoft RSA SChannel Cryptographic Provider" -- это провайдер шифрования. Имеет смысл менять ммм…. Никогда. Ну или точно знаешь зачем это нужно. RequestType = PKCS10; -- тип запроса. менять нужно если точно уверен что ты делаешь [EnhancedKeyUsageExtension] – блок описания для чего может использоваться этот сертификат OID=1.3.6.1.5.5.7.3.1 ; Server Authentication -- проверка подлинности сервера OID=1.3.6.1.5.5.7.3.2 ; Client Authentication – проверка подлинности клиента [RequestAttributes] – ну и складное на закуску, дополнительные имена в сертификат SAN = "dns=hardware.company.local&" -- полное имя DNS _continue_ = "dns=hardware&" -- сокращенное имя _continue_ = "ipaddress=192.168.0.1" -- ip-адрес если нужно добавить несколько ip-адресов, или dns-имен то добавляем соответствующую строчку. Одна строчка – одно имя или ip-адрес. В конце имени или ip адреса должен стоять знак &. В последней строчке знака & ставить не надо - это означает что дальше есть еще данные. В последней строчки этого знака быть не должно. CertificateTemplate = TermFarm; -- это имя шаблона, можно задать во время регистрации -- - этот значок обозначает начало коментария. Его не должно быть в файле.
-
После того, как мы создали файл inf заходим на выдающий сервер
-
Запускаем из-под админа cmd
-
Запускаем certreq -new C:\%сert_patch%\%cert_name%.inf (исходный файл inf) C:\%сert_patch%\%cert_name%.req (итоговый файл req)
-
Запускаем CERTREQ -attrib «CertificateTemplate:WebServer» C:\%сert_patch%\%cert_name%.req
attrib - это имя шаблона, по которому делается сертификат. Он определяет, что именно можно удостоверять этим сертификатом. Стандартно это проверка подлинности сервера, бывают еще проверка подлинности клиента, подпись кода, почта, еще много всякого разного C:\%сert_patch%\%cert_name%.csr - это путь к файлу запроса. Может быть csr (я так понимаю в основном *nix-системы) или req (я так понимаю windows)
-
Вылезет окошко с выбором удостоверяющего центра:
-
Если нам повезло и мы нигде не ошиблись у нас появится окно с предложением сохранить файл с расширением .cer – это как раз то, что нам нужно – подписанная открытая часть.
Казалось бы, вот оно счастье. Ан нет, нужно еще склеить полученное с закрытой частью. Для этого запускаем mmc из под админа -
Добавляем оснастку «Сертификаты»
-
Выбираем «учетная запись компьютера» (это важно, иначе не увидеть закрытую часть) и в итоге получаем вот такое:
-
Сертификаты -> Запросы заявок на сертификат ->Сертификат, правой клавишей мышки -> Все задачи -> импорт
(если посмотреть в список сертификатов, то мы должны увидеть наш сертификат (называться будет так же, как строка Subject в файле inf) -
Далее -> Тут выбираем полученный cer -> Далее -> Готово
-
Выбираем наш сертификат -> правая клавиша мыши -> все задачи -> экспорт
-
В появившемся окне Далее -> Да, экспортировать закрытый ключ (далее) -> Ставим галки «включить все сертификаты» и «экспортировать все расширенные свойства» (Далее) -> ставим галку «Пароль» и вбиваем невероятно сложный пароль 1 (на самом деле если куда-то далеко и кому то, то пароль действительно должен быть сложный) Далее -> выбираем куда сохранять -> Готово
-
Забираем сертификат и скармливаем ее программе/железке
Нюанс. Некоторые программы требую формат p12 или как то так, но вполне шикарно принимают и pfxУстановка pfx на Nginx
- Копируем pfx на машину с Nginx
- Получаем из pfx сертификат
openssl pkcs12 -in mydomain.pfx -clcerts -nokeys -out mydomain.com.cer
- Получаем из pfx закрытый ключ
openssl pkcs12 -in domain.pfx -nocerts -nodes -out mydomain.com.key
ссылка на оригинал статьи https://habr.com/post/424743/
Добавить комментарий