none
Запрос сертификата с Microsoft CA для vmware RRS feed

  • Вопрос

  • Сгенерил запрос, через веб-интерфейс запросил, получил файл DER. 

    Меня смущает что нет ключика обозначающего наличие закрытого ключа при открытии полученого файла. Так и должно быть или это я где-то накосячил? 

    28 ноября 2014 г. 6:51

Ответы

  • На самом деле это поведение by design. Закрытый ключ остается у клиента, запросившего сертификат, и не раскрывается. Вы должны руководствоваться инструкциями VMware, куда подкладывается сгенерированный файл сертификата. Либо бывает вариант, когда закрытый ключ и сертификат хранятся в одном файле в формате PKCS12. Выясните, и если в вашем случае это действительно необходимо, я расскажу, как эти файлы объединить.
    28 ноября 2014 г. 8:56
    Модератор
  • Я же не вижу, что именно вы делаете. Есть вариант, когда вы запрашиваете сертификат, заполняя форму Advanced Certificate Request. Тогда есть возможность экспортировать сертификат с закрытым ключом (если установлен флажок Mark private keys as exportable). Либо есть форма Submit a Certificate Request or Renewal Request, когда вы подаете на CA запрос на сертификат в кодировке Base64. В этом случае CA вообще ни в каком виде не получает закрытый ключ, он есть только на стороне клиента.

    Запрос на сертификат представляет собой сгенерированный открытый ключ + атрибуты, и все это подписано на закрытом ключе из той же самой сгенерированной пары открытый/закрытый ключи.

    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:46
    Модератор

Все ответы

  • Иными словами, вы хотите экспортировать файл сертификата с закрытым ключом в формате PKCS12 (файл с расширением .pfx), правильно? Или вы сгенерировали запрос на сертификат в среде VMware?
    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 г. 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 г. 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:27
  • Я пользуюсь утилитой OpenSSL:

    openssl.exe pkcs12 -export -in cert.pem -inkey cert.key -out cert.pfx

    Если нужно включить еще цепочку вышестоящих сертификатов центров сертификации, то их (pem-файлы) требуется "склеить" в один, например, в текстовом редакторе и добавить в параметре -certfile CA_chain.pem

    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:17
    Модератор
  • Это я понимаю :)

    Но все-таки если сертификат нам выдал УЦ, внутри него(внутри сертификата) находится шифрованный хэш сертификата подписанного закрытым ключом УЦ. Так?


    28 ноября 2014 г. 13:23
  • Внутри любого сертификата находится шифрованный хэш данных, составляющих данный сертификат. В общем случае УЦ есть тот же CA с улучшенной функциональностью в плане управления. Если это не так, то дайте ссылку на документацию к вашему УЦ, и я попробую разобраться с механизмом выдачи сертификатов.
    28 ноября 2014 г. 14:14
    Модератор
  • Да у меня вопросы на теорию, просто вам явно можно доверять и отложить в голове это как фундаментальный материал :)

    По ходу созрел вопрос:

    Предположим я получил сертификат, который заверен неким CA, для того чтобы расшифровать хэш и убедиться в валидности сертификата мне нужен открытый ключ выдающего СА.

    Откуда я его беру?

    Из поля Authority Information Access в сертификате?


    28 ноября 2014 г. 14:26
  • Есть разная практика. Если в сертификате прописан AIA, то клиент PKI может получить вышестоящий сертификат по пути AIA. Однако нередко приходится включать в сертификат и цепочку промежуточных сертификатов, иначе не работает. По этому поводу можно посмотреть статью

    https://support.microsoft.com/kb/954755/en-us

    Способ доверенного распространения корневых сертификатов не зависит от PKI. В домене это политики открытого ключа, причем доверие основано на аутентификации Kerberos. Механизм обновления корневых сертификатов сторонних мировых центров сертификации описан в статье

    http://support.microsoft.com/kb/931125/en-us

     
    28 ноября 2014 г. 14:43
    Модератор
  • Спасибо вам за разъяснения!!! :)
    1 декабря 2014 г. 5:32