it-swarm.com.ru

Невозможно загрузить сертификаты при попытке создать файл pfx

Последние три часа я пытался создать файл .pfx, используя OpenSSL. Я следил за этим документом и следовал инструкциям в заголовке Get a certificate using OpenSSL.

Я на шаге здесь: openssl pkcs12 -export -out myserver.pfx -inkey myserver.key -in myserver.crt и использую консоль OpenSSL.exe.

Я получаю сообщение об ошибке: unable to load certificates

Я также пробовал это: x509 -text -in myserver.key и получил ошибку: 0906D06D06C:PEM_read_bio:no start line:.\crypto\pem\pem_lib.b.c:703:Expecting: TRUSTED CERTIFICATE Я также получаю эту ошибку, если я пытаюсь myserver.crt.

Кажется, я понимаю, что бы я ни делал.

Может кто-нибудь, пожалуйста, помогите?

14
davy

Я получаю сообщение об ошибке: невозможно загрузить сертификаты

myserver.crt должен быть в формате PEM. Есть ли ----- BEGIN CERTIFICATE ----- и ----- END CERTIFICATE -----?


Фактически myserver.crt должен быть цепочкой сертификатов (а не только сертификатом одного сервера). Цепочка должна включать все промежуточные сертификаты, необходимые клиенту для проверки цепочки.

Вы отправляете все промежуточные сертификаты для решения проблемы «какой каталог». «Какой каталог» является хорошо известной проблемой в PKI. По сути, клиент не знает, куда обратиться за отсутствующим промежуточным сертификатом. Чтобы избежать проблемы, вы отправляете все промежуточные продукты.

Я часто использую Startcom , потому что они предлагают бесплатные сертификаты класса 1. Когда я получаю от них подписанный сертификат сервера (например, www-example-com.crt), я добавляю к нему промежуточный сервер класса 1. Я получил их серверное промежуточное звено класса 1 с их веб-сайта Startcom CA certs . Я использую sub.class1.server.ca.pem.

С www-example-com.crt мой сертификат сервера выглядит так:

$ cat www-example-com.crt

-----BEGIN CERTIFICATE-----
< My Server Certificate >
-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----
< Startcom Intermediate >
-----END CERTIFICATE-----

Для полноты секретный ключ (например, www-example-com.key) также имеет формат PEM. Он использует -----BEGIN RSA PRIVATE KEY----- и -----END RSA PRIVATE KEY-----.

С моим сертификатом сервера в формате PEM (и с необходимыми промежуточными соединениями) и закрытым ключом я затем выдаю следующее (которое похоже на ту же команду, которую вы используете):

openssl pkcs12 -export -in www-example-com.crt -inkey www-example-com.key -out www-example-com.p12

Когда клиенты подключаются, они используют Startcom CA. Итак, чтобы проверить соединение (после загрузки в IIS):

openssl s_client -connect www.example.com:443 -CAfile startcom-ca.pem

Команда должна завершиться «Подтвердить ОК»:

SSL-Session:
    Protocol  : TLSv1
    Cipher    : DHE-RSA-AES256-SHA
    Session-ID: 37E5AF0EE1745AB2...
    Session-ID-ctx:
    Master-Key: 7B9F8A79D3CC3A41...
    Key-Arg   : None
    Start Time: 1243051912
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)

Я также попробовал это: x509 -text -in myserver.key и получил ошибку ...

x509 для сертификатов. Если вы хотите сбросить ключ, используйте команду OpenSSL pkey. См. Документацию по команде OpenSSL pkey(1) .

11
jww

Я следил за этим документом ...

Кстати, из документов, которые вы процитировал :

Базовые сертификаты - это сертификаты, в которых общее имя (CN) сертификат установлен на конкретный домен или поддомен, которые клиенты будет использовать для посещения сайта. Например, www.contoso.com. Эти сертификаты защищают только одно доменное имя, указанное CN.

Есть два стандарта для такого рода вещей. Первый - это RFC, а второй - требования к CA-Browser (CA/B). RFC являются общими, потому что они применяются к очень многим различным протоколам и услугам, и они создают широкую сеть для охвата многих существующих практик. Из-за этого RFC несколько небрежны - они допускают множество вещей, которые противоречат интуитивному. Например, посмотрите на допустимый keyUsage из RFC 5280 в Разделе 4.2.1.3.

CA и браузеры собрались вместе и создали форумы CA/B. Вместе они публикуют стандарты, которым следуют. Практики CA/B несколько более дисциплинированы (вы можете думать об этом как о подмножестве RFC). Если вы посмотрите на их Базовые требования , то обнаружите, что CN устарела и не должна использоваться. Если используется CN, то в SAN должно присутствовать то же имя:

9.2.2 Поле общего имени субъекта

Поле сертификата: субъект: общее имя (OID 2.5.4.3)

Обязательно/необязательно: устарело (не рекомендуется, но не запрещено)

Содержание: Если поле присутствует, оно ДОЛЖНО содержать один IP-адрес или Полное доменное имя, которое является одним из значений, содержащихся в Расширение subjectAltName сертификата (см. Раздел 9.2.1).

Суть: вы должны избегать помещения имени хоста или домена в CN. Вы избегаете этого, потому что это то, что CA согласился сделать, и именно этого ожидают браузеры. (А если вы не заходите на сайт через браузер, то делайте что хотите).

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

1
jww