Лучший отвечающий
Запрос сертификата с Microsoft CA для vmware

Вопрос
-
Сгенерил запрос, через веб-интерфейс запросил, получил файл DER.
Меня смущает что нет ключика обозначающего наличие закрытого ключа при открытии полученого файла. Так и должно быть или это я где-то накосячил?
28 ноября 2014 г. 6:51
Ответы
-
На самом деле это поведение by design. Закрытый ключ остается у клиента, запросившего сертификат, и не раскрывается. Вы должны руководствоваться инструкциями VMware, куда подкладывается сгенерированный файл сертификата. Либо бывает вариант, когда закрытый ключ и сертификат хранятся в одном файле в формате PKCS12. Выясните, и если в вашем случае это действительно необходимо, я расскажу, как эти файлы объединить.
- Помечено в качестве ответа Дмитрий Трясов 28 ноября 2014 г. 11:52
28 ноября 2014 г. 8:56Модератор -
Я же не вижу, что именно вы делаете. Есть вариант, когда вы запрашиваете сертификат, заполняя форму Advanced Certificate Request. Тогда есть возможность экспортировать сертификат с закрытым ключом (если установлен флажок Mark private keys as exportable). Либо есть форма Submit a Certificate Request or Renewal Request, когда вы подаете на CA запрос на сертификат в кодировке Base64. В этом случае CA вообще ни в каком виде не получает закрытый ключ, он есть только на стороне клиента.
Запрос на сертификат представляет собой сгенерированный открытый ключ + атрибуты, и все это подписано на закрытом ключе из той же самой сгенерированной пары открытый/закрытый ключи.
- Помечено в качестве ответа Дмитрий Трясов 28 ноября 2014 г. 10:08
28 ноября 2014 г. 9:34Модератор -
Я пользуюсь утилитой OpenSSL:
openssl.exe pkcs12 -export -in cert.pem -inkey cert.key -out cert.pfx
Если нужно включить еще цепочку вышестоящих сертификатов центров сертификации, то их (pem-файлы) требуется "склеить" в один, например, в текстовом редакторе и добавить в параметре -certfile CA_chain.pem
- Помечено в качестве ответа Дмитрий Трясов 28 ноября 2014 г. 11:51
28 ноября 2014 г. 11:46Модератор
Все ответы
-
Иными словами, вы хотите экспортировать файл сертификата с закрытым ключом в формате PKCS12 (файл с расширением .pfx), правильно? Или вы сгенерировали запрос на сертификат в среде VMware?
- Изменено osr_MVP, Moderator 28 ноября 2014 г. 7:58
28 ноября 2014 г. 7:56Модератор -
Опыт работы есть только с запросами сертификатов через MMC-консоль Windows.
Запрос сгенерил в VmWare, соответсвенно код который между BEGIN CERTIFICATE REQUEST и END CERTIFICATE REQUEST ввожу в request, шаблон сделал как описано на сайте vmware.
В каталоге который сгенерила софтина vmware есть файл с расширением key, судя по всему это и есть закрытый ключ. Может ли быть в запросе указано, что создать только сертификат, без закрытого ключа?
28 ноября 2014 г. 8:24 -
На самом деле это поведение by design. Закрытый ключ остается у клиента, запросившего сертификат, и не раскрывается. Вы должны руководствоваться инструкциями VMware, куда подкладывается сгенерированный файл сертификата. Либо бывает вариант, когда закрытый ключ и сертификат хранятся в одном файле в формате PKCS12. Выясните, и если в вашем случае это действительно необходимо, я расскажу, как эти файлы объединить.
- Помечено в качестве ответа Дмитрий Трясов 28 ноября 2014 г. 11:52
28 ноября 2014 г. 8:56Модератор -
By design для Веб-интерфейса?
При запросе через MMC-консоль получаю сразу и private и сертификат.
В моем случае это судя по всему не нужно. Просто как генерится открытый ключ если закрытый хранится у пользователя? Или он уже содержится в запросе?
28 ноября 2014 г. 9:18 -
Я же не вижу, что именно вы делаете. Есть вариант, когда вы запрашиваете сертификат, заполняя форму Advanced Certificate Request. Тогда есть возможность экспортировать сертификат с закрытым ключом (если установлен флажок Mark private keys as exportable). Либо есть форма Submit a Certificate Request or Renewal Request, когда вы подаете на CA запрос на сертификат в кодировке Base64. В этом случае CA вообще ни в каком виде не получает закрытый ключ, он есть только на стороне клиента.
Запрос на сертификат представляет собой сгенерированный открытый ключ + атрибуты, и все это подписано на закрытом ключе из той же самой сгенерированной пары открытый/закрытый ключи.
- Помечено в качестве ответа Дмитрий Трясов 28 ноября 2014 г. 10:08
28 ноября 2014 г. 9:34Модератор -
То есть Create and submit a request to this CA - это генерация ключей на стороне центра сертификации
а
Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file
это использование уже существующих ключей?
28 ноября 2014 г. 10:10 -
Вопросы чую глупые задаю, может толковое почитать дадите чего?28 ноября 2014 г. 10:14
-
Я так понял надо про это почитать:
Supported request formats: CMC, PKCS #7, or PKCS #10
28 ноября 2014 г. 10:32 -
То есть Create and submit a request to this CA - это генерация ключей на стороне центра сертификации
а
Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file
это использование уже существующих ключей?
Во втором случае однозначно, уже существующих. Что касается первого варианта, это генерация ключей на стороне не центра сертификации, а веб-сервера, интерфейсом которого вы пользуетесь для запроса сертификата. Обычно веб-сервер и центр сертификации физически установлены на одном компьютере, вот и получается, что закрытый ключ генерируется на стороне центра сертификации. Однако закрытые ключи хранятся в Protected Storage, а хранилища сертификатов компьютера/пользователя и база CA - это разные хранилища.28 ноября 2014 г. 10:41Модератор -
Ну спасибо вам, вроде все понятно теперь. А что вы говорили насчете соединить в формат PKCS12, как это сделать?
- Изменено Дмитрий Трясов 28 ноября 2014 г. 11:28
28 ноября 2014 г. 11:27 -
Я пользуюсь утилитой OpenSSL:
openssl.exe pkcs12 -export -in cert.pem -inkey cert.key -out cert.pfx
Если нужно включить еще цепочку вышестоящих сертификатов центров сертификации, то их (pem-файлы) требуется "склеить" в один, например, в текстовом редакторе и добавить в параметре -certfile CA_chain.pem
- Помечено в качестве ответа Дмитрий Трясов 28 ноября 2014 г. 11:51
28 ноября 2014 г. 11:46Модератор -
Могу еще полтыщи вопросов сюда накидать - но уж наглеть не буду.
Спасибо вам большое за подробные разъяснения :)
28 ноября 2014 г. 11:51 -
Можно еще вопрос? У нас тут в отделе спор уже пошел :)
Сертификат подписан УЦ - это означает что вычислен хэш сертификата, зашифрован закрытым ключем и вложен в сертификат. Так?
28 ноября 2014 г. 12:27 -
Конечно задавайте! :)
Когда "сертификат клиента выдан центром сертификации", это означает, что {открытый ключ клиента + атрибуты + область действия} подписаны на закрытом ключе центра сертификации (или удостоверяющего центра). Любой другой клиент PKI сможет проверить валидность и неизменность данного сертификата на общедоступном открытом ключе центра сертификации, который берется из сертификата CA. Сертификат центра сертификации проверяется аналогично на сертификате вышестоящего CA и т.д. до корневого сертификата, который подписан не на закрытом ключе вышестоящего CA, а на своем же закрытом ключе. Доверие к корневому сертификату у клиентов PKI - безусловное, не основанное на PKI.
28 ноября 2014 г. 13:01Модератор -
Подписание {открытый ключ клиента + атрибуты + область действия} - это вычисление хэша и шифрование, так?
И все это хранится в сертификате в поле SignatureValue, правильно?
- Изменено Дмитрий Трясов 28 ноября 2014 г. 13:06
28 ноября 2014 г. 13:06 -
Да, подписание фактически означает шифрование хеш-функции массива данных (закрытым ключом). На проверяющей стороне происходит дешифровка хеш-функции (открытым ключом) и одновременно вычисляется хеш-функция того же массива данных. Совпадение двух значений хеш-фунции означает успешную проверку сертификата.
Просто уточню, что в сертификате никакая информация не шифруется, она находится в общедоступном виде. Тот факт, что сертификат в текстовом редакторе выглядит как бессмысленный набор символов, означает его кодирование в формат, удобный для передачи, но не шифрование с целью сокрытия информации.
- Изменено osr_MVP, Moderator 28 ноября 2014 г. 13:17
28 ноября 2014 г. 13:17Модератор -
Это я понимаю :)
Но все-таки если сертификат нам выдал УЦ, внутри него(внутри сертификата) находится шифрованный хэш сертификата подписанного закрытым ключом УЦ. Так?
- Изменено Дмитрий Трясов 28 ноября 2014 г. 13:24
28 ноября 2014 г. 13:23 -
Внутри любого сертификата находится шифрованный хэш данных, составляющих данный сертификат. В общем случае УЦ есть тот же CA с улучшенной функциональностью в плане управления. Если это не так, то дайте ссылку на документацию к вашему УЦ, и я попробую разобраться с механизмом выдачи сертификатов.28 ноября 2014 г. 14:14Модератор
-
Да у меня вопросы на теорию, просто вам явно можно доверять и отложить в голове это как фундаментальный материал :)
По ходу созрел вопрос:
Предположим я получил сертификат, который заверен неким CA, для того чтобы расшифровать хэш и убедиться в валидности сертификата мне нужен открытый ключ выдающего СА.
Откуда я его беру?
Из поля Authority Information Access в сертификате?
- Изменено Дмитрий Трясов 28 ноября 2014 г. 14:26
28 ноября 2014 г. 14:26 -
Есть разная практика. Если в сертификате прописан AIA, то клиент PKI может получить вышестоящий сертификат по пути AIA. Однако нередко приходится включать в сертификат и цепочку промежуточных сертификатов, иначе не работает. По этому поводу можно посмотреть статью
https://support.microsoft.com/kb/954755/en-us
Способ доверенного распространения корневых сертификатов не зависит от PKI. В домене это политики открытого ключа, причем доверие основано на аутентификации Kerberos. Механизм обновления корневых сертификатов сторонних мировых центров сертификации описан в статье
28 ноября 2014 г. 14:43Модератор -
Спасибо вам за разъяснения!!! :)1 декабря 2014 г. 5:32