Недавно при настройке целой цепочки серверов для удаленного доступа пришлось по многу раз генерировать сертификаты с разными параметрами, пока все не заработало как надо. Не все возможно, как оказалось, сделать через визарды и оснастку управления сертификатами. К тому же одно и то же действие лучше автоматизировать.
Проблемы были решены с помощью стандартной утилиты командной строки certreq.exe (ее параметры) и командного файла:
· Сначала запускаем оснастку mmc
· Добавляем Certificates для Local Computer
· Открываем раздел Local Computer\Certificate Enrollment Requests
· Если там есть необработанные запросы, то удаляем их – это важно!
· Открываем раздел Local Computer\Personal
· Чистим его от старых и не нужных сертификатов
· Открываем командную строку и последовательно выполняем команды (можно из командного файла):
certreq -new c:\tsg.inf c:\tsg.req
certreq -submit c:\tsg.req c:\tsg.cer
certreq -accept -machine c:\tsg.cer
После этого открываем оснастку управления нужной службы и выполняем привязку нашего сертификата стандартным образом.
Особо обращаю внимание, что надо чистить Local Computer\Certificate Enrollment Requests от старых запросов. Иначе сертификаты будут импортироваться, но без ключей!
Не всегда центр сертификатов бывает доступен. Например, когда сервер в DMZ или просто закрыт фаэрволом может даже собственным. Ничего страшного: запросы можно делать с любого другого компьютера. Главное указать Exportable = TRUE. Это даст нам возможность экспортировать сертификат вместе с ключом в файл .pfx, перенести его на целевой компьютер и импортировать. При импорте на целевом компьютере можно указать, что ключ не подлежит экспорту и тем самым уменьшить вероятность его компроментации.
Содержимое файла tsg.inf создано на основе статьи KB321051:
[Version]
Signature=»$Windows NT$
[NewRequest]
Subject = «CN=server.domainname,OU=цех,O=фирма,L=город,S=регион,C=RU» ; must be the FQDN
;EncipherOnly = FALSE
Exportable = TRUE ; TRUE = Private key is exportable
KeyLength = 2048 ; Common key sizes: 512, 1024, 2048,
; 4096, 8192, 16384
KeySpec = 1 ; Key Exchange
;KeyUsage = 0xA0 ; Digital Signature, Key Encipherment
MachineKeySet = True
ProviderName = «Microsoft RSA SChannel Cryptographic Provider»
ProviderType = 12
RequestType = CMC
; Omit entire section if CA is an enterprise CA
[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1 ; Server Authentication
[RequestAttributes]
CertificateTemplate = WebServer ;Omit line if CA is a stand-alone CA
; SAN=»dns=server.domainname, dns=another.domainname»
Как вы можете видеть, есть закомментированная строчка для создания SAN сертификата (Subject Alternative Name) – далеко не всегда можно получить такой сертификат через визард.
Еще одно замечание про ISA 2006 SP1 и SAN сертификат. ISA 2006 SP1 полностью поддерживает SAN сертификаты. Но есть одна тонкость. Когда я сгенерировал сертификат как:
Subject = «CN=external.domainname»
SAN=»dns=internal.domainname”
Сервер ISA подхватил только имя, указанное в поле SAN! Правильно будет так:
Subject = «CN=external.domainname”
SAN=»dns= external.domainname,dns=internal.domainname”
Так с помощью утилиты certreq.exe мне удалось сэкономить немного своего времени. Надеюсь вам тоже. :-)
Filed under: Без рубрики |
ILYA Sazonov: ITPro 
1. У тебя в командах кавычки побились.
2. «Не всегда центр сертификатов бывает доступен. Например, когда сервер в DMZ или просто закрыт фаэрволом может даже собственным. Ничего страшного: запросы можно делать с любого другого компьютера. Главное указать Exportable = TRUE. Это даст нам возможность экспортировать сертификат вместе с ключом в файл .pfx, перенести его на целевой компьютер и импортировать» — а вот это нельзя рекомендовать. Ай-ай-ай.
1. Кавычки мне не подвластны: WordPress управляет ими по своему разумению :-)))
2. Точнее Артем, пожалуйста: что именно нельзя рекомендовать? А то получается, что сертификат можно только автоматически получать, но нельзя перенести его на изолированный компьютер, в DMZ, а коммерческий сертификат вообще невозможно установить. Тем более непонятно, т.к. при импорте сертификата можно указать, что ключ будет неэкспортируемым.
Артём на самом деле прав со вторым пунктом. Поскольку описанный метод распространения сертификатов является примером того, как не надо делать. Чтобы PKI была похожа на PKI надо следовать каким-то правилам и концепциям. Например, у каждого пользователя в AD есть своя учётная запись и пароль от неё. Пароль от учётной записи знает только её владелец и никто больше. Ведь администратор не задаёт пользователям назначенный пароль и не заставляет использовать только его. Администратор только создаёт временный пароль, который пользователь меняет на свой и новый пароль выходит из под контроля администратора.
Давайте подумаем: сертификат — это нечто позволяющее однозначно идентифицировать кого-то (пользователя или компьютера), а закрытый ключ от этого сертификата является неким аналогом этого пароля. И тут вы предлагаете его свободно экспортировать и куда-то переносить. Тем более именно в эти моменты чаще всего и происходят «утери и компрометации» ключей, потому что что-то забыли, что-то не доглядели и т.д.. Правильно будет генерировать запрос на целевом компьютере, который можно засабмитить на любой CA сервер (хоть свой собственный, хоть верисайна, без разницы). Таким образом вы следуете одному из главному концепту — ключ находится только у владельца. Я давно «проповедую» эту концепцию и активно её поддерживаю стандартыми воркфловами по управлению. Вот несколько примеров:
http://en-us.sysadmins.lv/Lists/Posts/ViewPost.aspx?ID=21
http://en-us.sysadmins.lv/Lists/Posts/ViewPost.aspx?ID=5
> Чистим его от старых и не нужных сертификатов
ээ, нее. Так тоже никуда не годится, потому что правильно будет их отзывать. Политика автоэнроллмента автоматически спрячет их. И дело не только в этом. При удалении сертификата закрытый ключ от него не удаляется. Следовательно, его можно в 2 счёта восстановить. Вы считаете, что удалили сертификат, а он уже гуляет по всей сети и используется поддельными службами и/или пользователями.
> Особо обращаю внимание, что надо чистить Local Computer\Certificate Enrollment Requests от старых запросов. Иначе сертификаты будут импортироваться, но без ключей!
да ну, это не так. При генерации запроса, генерируется и ключевая пара. Закрытый ключ используется для подписи реквеста. Следовательно система при импорте сертификата безошибочно находит нужный запрос и ассоциированный ключ, чтобы пристыковать к нему сертификат.
> Правильно будет так:
открою маленький секрет, если вы не в курсе ещё: когда используется расширение SAN, всем глубоко фиолетово, что записано в поле Subject. Т.е. если используете SAN, вы используете только SAN, поскольку нельзя использовать Subject и SAN одновременно. Поэтому я в подобных случаях чаще или вообще оставляю пустой Subject или просто указываю DN для идентификации принадлежности компании/отделу/кабинету.
Я не настаиваю на такой практике :-) Вы конечно правы. Но … Тут как раз имеем отличие теории от практики: у меня нет другого администратора безопасности, и нет другого администратора ISA, и нет другого администратора почтовой системы, и нет коммерческой CA — мне пришлось делать все самому. Правильная концепция не работает, хоть тресни. Точнее она работает — по ней работать невозможно :-) Думаю, я не одинок в такой ситуации.
Кстати открою страшную тайну. Если вам приходилось настраивать Exchange 2010 и запрашивать с помощью визарда сертификат с внутреннего CA, то обратите внимание на его характеристики… :-) — будет о чем пообщаться с Microsoft!
Что касается зачистки Certificate Enrollment Requests — напоролся на эти грабли, потому и написал. Видимо есть какие-то тонкости: теоретически должно работать как вы пишите, а практически нет (в моей конфигурации по-крайней мере).
> Точнее она работает – по ней работать невозможно
да ладно, все работают, а вы не можете? Просто нужно привыкнуть к этому. Тем более всё это можно автоматизировать.
> Если вам приходилось настраивать Exchange 2010 и запрашивать с помощью визарда сертификат с внутреннего CA, то обратите внимание на его характеристики… – будет о чем пообщаться с Microsoft!
не, пока не приходилось, но могу представить. Вы думаете, что MS следует бест-практисам? Видите ли, я в курсе как работают многие продуктовые команды (да и вы должны знать). Они делают свои вещи как положено, а смежные (та же интеграция с PKI) как умеют и с нужными продакт-тимами не особо консультируются. Но это не значит, что с PKI надо работать как советует команда эксченджа или системцентра. Это, кстати, и отличает настоящего специалиста от быдлоадмина. Нужно вникать в каждую технологию и делать как положено.
> Видимо есть какие-то тонкости: теоретически должно работать как вы пишите, а практически нет (в моей конфигурации по-крайней мере).
нет, там никаких тонкостей нет, всё достаточно просто. Почему оно не работает в вашей конфигурации — это уже вопрос к вашей конфигурации. Видимо, что-то делаете не так.
А по поводу кавычек — заключайте код в тег PRE, тогда и не будут биться.
Я представляю собой пример живого администратора ISA, Exchange и ещё кучи других прикладных служб, который работает в соответствии с принципами, озвученными Вадимом. Результат положительный. В том плане, что всё работает, и никто ещё не умер.
Единственное исключение — замечательный продукт «Forefront Unified Access Gateway (UAG)». Ему зачем-то требуется, чтобы сертификаты на всех узлах массива NLB были одинаковым. А для этого, действительно, приходится импортировать их с ключами. Причём очевидно, что это ограничение не Windows NLB и не TMG, а исключительно управляющего интефейса UAG. Но тут можно сделать скидку на то, что этот продукт только недавно был приобретён Microsoft. И версия 2010 — первая, которая была выпущена самой корпорацией. Будем надеяться, что в будущих версиях такой ерунды уже не будет.
Что же касается Exchange Server 2010 — то не надо грязи. Во-первых, его встроенный коммандлет «New-ExchangeCertificate» имеет правильный параметр «PrivateKeyExportable», который можно и нужно устанавливать в «$False». Во-вторых, если встроенные средства генерации запросов по какой-то причине не устраивают — сам Exhange отлично может использовать сертификаты, которые были сгенерированны штатными средствами Windows, без использования собственных утилит Exchange.