Добавление промежуточных сертификатов в файл pkcs12

Ответ 1

Добавление промежуточных сертификатов в файл pkcs12...

Вот как я это делаю на своих веб-серверах и почтовых серверах.

Во-первых, www-example-com.crt - это сертификат веб-сервера, подписанный Startcom. Startcom предлагает бесплатные сертификаты класса 1, которым доверяют большинство моих браузеров и мобильных устройств, поэтому я их использую. Сертификат находится в формате PEM (----- BEGIN CERT ----- и ----- END CERT -----).

Во-вторых, я открываю www-example-com.crt и добавляю Startcom Class 1 Intermediate. Я получаю промежуточное звено от Startcom Индекс /certs. Теперь мой www-example-com.crt имеет два закодированных в PEM закодированных сертификатах.

В-третьих, я выполняю следующие действия для создания файла PKCS12/PFX для использования в IIS.

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

В вашем случае ваш www-example-com.crt будет иметь в нем как минимум три сертификата PEM:

----- BEGIN CERT -----
< My JBoss Certificate >
----- END CERT -----

----- BEGIN CERT -----
< My Issuing CA >
----- END CERT -----

----- BEGIN CERT -----
< My CA >
----- END CERT -----

Третий сертификат в цепочке - My CA - является необязательным. Это вам не нужно, если ваши клиенты используют My CA в качестве якоря доверия. Если вы используете клиентов Entrust как привязку доверия, тогда вам нужно будет включить его.

Если вы cat ваш www-example-com.crt и у него нет нескольких сертификатов, не продолжайте. Не выполняйте openssl pkcs12, пока ваш серверный сертификат не получит все необходимые промежуточные сертификаты, необходимые для проверки цепочки.

Не включайте сертификат CA Entrust.

Я сомневаюсь, что знаки Entrust с их CA напрямую. Вероятно, они тоже используют промежуточное звено. Поэтому ваша цепочка сертификатов должна выглядеть так:

----- BEGIN CERT -----
< My JBoss Certificate >
----- END CERT -----

----- BEGIN CERT -----
< My Issuing CA >
----- END CERT -----

----- BEGIN CERT -----
< My CA >
----- END CERT -----

----- BEGIN CERT -----
< Entrust Intermediate >
----- END CERT -----

Entrusts предоставляет сертификаты CA и Intermediate в сертификатах Entrust Root. Я не могу сказать вам, какой из них вам нужен, потому что вы не укажете URL-адрес или не покажете нам цепочку, которую у вас есть. Но я предполагаю, что это будет один или несколько из:

• Доверяйте сертификат цепи L1E
• Доверяйте сертификат цепи L1C
• Доверять сертификат цепи L1E (SHA2)
• Доверять сертификат цепи L1C (SHA2)

Вы можете проверить свою цепочку с помощью OpenSSL `s_client. На этот раз вы будете использовать Entrust certifcate:

echo -e "GET / HTTP/1.0\r\n" | openssl s_client -connect myserver:8443 \
                                       -CAfile entrust-ca.pem

Вы можете получить entrust-ca.pem из Доверенных корневых сертификатов. Запустите его и сообщите нам, какие ошибки вы получите. Или лучше, разместите URL-адрес вашего сервера, чтобы мы могли видеть, что происходит.

Ответ 2

У меня есть сертификат, который имеет следующую цепочку сертификации: Entrust- > My CA- > Мой выдающий CA- > My JBoss Certificate....

Думаю, у вас есть две проблемы. Во-первых, это СЗС, а вторая - незавершенная цепочка клиентов.

Во-первых, простая проблема. Сервер должен отправить сертификат конечной сущности (сервера) и любые промежуточные сертификаты, необходимые для сборки цепочки. Сервер отправляет промежуточные сертификаты, чтобы избежать проблемы с каталогом. "Какая директория" является хорошо известной проблемой в PKI. По сути, клиент не знает, куда идти, чтобы получить отсутствующий промежуточный сертификат.

Итак, ваше первое решение заключается в том, что сервер отправляет цепочку с помощью:

• Ваш промежуточный сертификат ( "Мой выдающий CA" )
• Сертификат сервера ('My JBoss Certificate')

Во-вторых, у вас есть проблема ненадежного эмитента. Клиент должен доверять вашему внутреннему ЦС выдачи.

Итак, ваше второе решение - обеспечить, чтобы ваш клиент доверял вашему внутреннему ЦС ( "Мой ЦС" ). В этом случае клиенту не требуется даже использовать Entrust, поскольку точка доверия внедрена в ваш внутренний CA.

Возможно, сервер может отправить цепочку с помощью "Мой CA", "Мой выдающий CA" и "My JBoss Certificate". В этом случае клиент должен доверять "Entrust".

Если клиент не доверяет "Entrust" или "My CA", тогда вы получите ошибки проверки.

Я сделал один файл .pem всех сертификатов, которые будут работать. Это не так. Может ли кто-нибудь объяснить, что я делаю неправильно или даже если это возможно?

В этом случае нам нужно будет увидеть сертификаты, чтобы понять, что происходит. Можете ли вы опубликовать URL-адрес, который обслуживает сертификат, и использует цепочку; и опубликовать ваш внутренний сертификат CA ( "Мой CA" ) онлайн?

Здесь быстрый и грязный способ проверить соединение с OpenSSL s_client:

echo -e "GET / HTTP/1.0\r\n" | openssl s_client -connect myserver:8443 \
                                       -CAfile my-issuing-ca.pem

OpenSSL по умолчанию ничего не доверяет (в отличие от браузеров), поэтому вам нужно указать свой якорь доверия с помощью -CAfile.

Эта команда должна заканчиваться чем-то вроде следующего.

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)

Если в команде OpenSSL появляется сообщение "ОК", проблема связана с браузером и точкой доверия.