Дисклеймер
В этой статье выражено личное мнение автора, его видение мира, его путь, и это все не претендует на абсолютную верность и объективность. Автор не несет никакой ответственности за последствия использования данной информации, он только надеется что эта информация поможет сделать кому-то жизнь проще.
Зачем нам все это надо?
Война… Война никогда не меняется… (с) Fallout
Да, война за свои данные никогда не меняется и не останавливается. Она идет каждую минуту, каждую секунду, каждый тик процессора.
Но к черту эту пафосную фигню, оставим это маркетологам по продаже продуктов по безопасности. Сегодняшняя статья маленькая, но надеюсь весьма полезная — как сделать себе сертификат подписанный своим собственным центром сертификации.
Чего НЕ будет в статье
- как настроить свой собственный центр сертификации
- авторизация по сертификатом
- внедрение x509
- какой-то экзотики связной с сертификатами
Что будет в статье
- как создать сертификат подписанный локальным сервером сертификации
- как создать сертификат даже при условии что система не умеет генерировать запрос
Кому интересно — прошу под кат
Важно
Предполагается что:
- в вашей компании используется в основном инфраструктура MS
- у вас уже развернут PKI
- все у вас хорошо (в той или иной степени), и вам понадобилось создать еще один сертификат, который по какой-то причине надо сделать руками
Идея этой статьи возникла уже давно, еще в те времена когда мы только начинали думать над своим собственным 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
Комментарии (21)
aamonster
30.09.2018 23:24+2Идиотский вопрос: а нельзя было то же самое сделать просто командной строкой openssl? (На винде — под WSL).
UPD: нагугленный пример — m.habr.com/post/192446. Проще вашего метода.
Впрочем, учитывая, что пригодиться такой сертификат может скорей для отладки, чем для реальной работы — можно просто поставить какой-нибудь https-сниффер, он сам всё сделает.Dr_Wut Автор
30.09.2018 23:34-4Нет, ибо вы потеряете все прелести интегрированного в инфраструктуры MS центра сертификации — а их там огромное количество, с которыми openssl тягаться будет тяжеловато.
aamonster
30.09.2018 23:38+1WAT?
Мы говорим тупо о генерации сертификата. Который потом можно скормить той же виндозной инфраструктуре.Dr_Wut Автор
30.09.2018 23:41-5*facepalm*
У уже есть PKI, везде все настроено — нужен еще один серт — вы предлагаете пилить еще один центр сертификации чтобы «можно было сгенерить серт 5-ю строчками» По вашему это нормально? При условии что вам придется еще раз добавлять всем ключ ЦС в доверенные, хотя у нас уже есть одинaamonster
01.10.2018 06:55В котором месте я предлагал "поднимать ещё один центр сертификации"? У нас есть коммандлайновая тулза, которая просто сгенерит пачку файлов. Всё.
Dr_Wut Автор
01.10.2018 00:54-7Товарища минусующие, вы хоть напишите за что минусуете, а то у меня создается впечатление что тут просто у красноглазиков пукан подгорает от того, что это в MS инфраструктуре ))))
P.S. Минусы будут подтверждением моей правоты
P.S.S. Как минимум 6 человек добавили в закладки — значит людям то это надоSuvitruf
01.10.2018 01:24+2Удобно.
Dr_Wut Автор
01.10.2018 02:30-1Ну зато какой эффект, слова мои подтверждаются — конструктивных замечаний 0 — зато куча минусов. Отсюда вывод — "не читал, но осуждаю". Ну а так как хабр индексируется основной цели я все равно достигну — у людей будет возможность решить свою проблему чуточку быстрее наткнувшись на эту статью.
nochkin
01.10.2018 02:57+1Минусы к обсуждению имеют малое отношение. Это больше про полезность статьи для общества.
К правоте уж точно никак не относится.
Tanner
01.10.2018 05:17Если бы вы сразу указали, что это хаутушка для Windows, или хотя бы тег соответствующий добавили, то явно получили бы меньше минусов.
asand3r
01.10.2018 07:36С чего бы это? Я как администратор Windows считаю, что статья имеет мало пользы и больше походит на кривенькое How-to для себя, без четкого понимания каждого описанного шага. От таких статей больше вреда, на самом деле.
Tanner
01.10.2018 08:16Я про качество статьи ничего не сказал, заметьте. Я сказал только, что минусов было бы меньше, если бы скоуп был определён. Или вы с этим не согласны?
peresada
01.10.2018 08:04Голосовать могут только постоянные Хабравчане, среди таких по большей части довольно опытные ребята, которые могут увидеть, что статья не заслуживает положительного рейтинга по разным причинам. То, что статью добавили в закладки 12 раз — мало о чем говорит, хорошие Туториалы набирают в десятки раз больше закладок, кроме того, определенный % закладок делают боты для разных дайджестов и сторонних ресурсов.
asand3r
Странно выглядит сравнение локально выданного сертификата с сертификатом от Let's Encrypt. Точнее говоря, просто некорректно.
Про PKI от Microsoft уж точно полно инфы, стоит только сходить на MSDN или docs.microsoft.com:
msdn.microsoft.com/ru-ru/library/hh831740%28v=ws.11%29.aspx?f=255&MSPPError=-2147217396
docs.microsoft.com/ru-ru/windows-server/networking/core-network-guide/cncg/server-certs/server-certificate-deployment-planning
Не вижу связи, честно говоря.
Dr_Wut Автор
>Странно выглядит сравнение локально выданного сертификата с сертификатом от Let's Encrypt. Точнее говоря, просто некорректно
О как! Расскажите пожалуйста почему? =) По сути эти два сервиса отличаются только тем, что корневые ЦС от Let's Encrypt уже есть в вашей системе, а локальный вы добавляете руками.
>Про PKI от Microsoft уж точно полно инфы, стоит только сходить на MSDN или docs.microsoft.com:
msdn.microsoft.com/ru-ru/library/hh831740%28v=ws.11%29.aspx?f=255&MSPPError=-2147217396
docs.microsoft.com/ru-ru/windows-server/networking/core-network-guide/cncg/server-certs/server-certificate-deployment-planning
Читайте пожалуйста внимательно — я не писал что нет инфы про PKI, я говорил что мало инфы о алгоритме выдачи самих сертификатов. Это очень разные вещи.
asand3r
Потому, что сертификат, выданный локальным центром сертификации не является доверенным вне вашей сети.
Окей. Но и тут я бы поспорил, конечно.
Dr_Wut Автор
Чем отличается то, что написал я, от того, что написали вы?
Есть, но я как уже писал — обычно урывками. Я постарался это все структурировать и записать в одном месте.
nochkin
Разница в доверии со стороны клиента.
Есть цели когда доверие пофиг, тут уже всё равно какой серт.
SirEdvin
Ну… да. Единственная задача, которую решает let's encrypt — это бесплатный ssl сертификат на сайт, который будет доступен в интернете. Ну и бонусом его еще можно вешать на корп. сайты что бы не страдать с добавлением везде своего корневого сертификата.
Dr_Wut Автор
Let's Encrypt решает частную задачу. Как минимум вы не сможете получить там:
acyp
1. habr.com/post/345298
2. сомневаюсь. у меня правда тоже такой механизм реализован на самоподписных, но позднеее, чем реализовал по такой схеме находил статью с использованием letsencrypt. переделывать было уже лень.
3. если для авторизации, то см п. 2. если для чего-то иного, то на мой взгляд перебор. подход типа "… и никакого секса, а для верности зальем в бетон...". все бы ничего, но речь шла о защите от зппп.
4. но есть же! вторая смена (6 мес эксплуатации), полет нормальный.