Добавление промежуточных сертификатов в файл pkcs12
У меня есть сертификат, который имеет следующие сертификации: Доверьте->мой CA->мой выдающий CA - >мой сертификат JBoss. Теперь, если я установлю свой сертификат на свой экземпляр JBoss, любая страница, к которой я обращаюсь, работающая на этом экземпляре, будет казаться ненадежной, поскольку мой выдающий CA не распознается моим браузером. Я знаю,что у моего компьютера есть открытый ключ для полномочий подписи Entrust. Как установить сертификат, чтобы любой браузер мог видеть всю цепочку сертификатов?
Я сделал одиночный.PEM файл всех сертификатов, думающих, что это сработает. Это не так. Может кто-нибудь объяснить что я делаю неправильно или даже если это возможно?
2 ответов
добавление промежуточных сертификатов в файл pkcs12 ...
вот как я это делаю на своих веб-и почтовых серверах.
во-первых,www-example-com.crt является сертификатом веб-сервера, подписанным Startcom. Startcom предлагает бесплатные сертификаты класса 1, доверенные большинству браузеров и мобильных устройств, поэтому я их использую. Сертификат в формате PEM (----- BEGIN CERT ----- и ----- END CERT -----).
во-вторых, я открываю www-example-com.crt и добавьте промежуточный класс 1 Startcom. Я получаю промежуточные от 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 пока ваш сертификат сервера не будет иметь все необходимые промежуточные сертификаты, необходимые для проверки цепочки.
не включайте сертификат Entrust CA.
я сомневаюсь, доверить знаки с их 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 -----
доверяет предоставляет свои CA и промежуточные сертификаты на Доверить Корневые Сертификаты. Я не могу сказать вам, какой из них вам нужен, потому что вы не предоставите URL-адрес или не покажете нам цепочку. Но я предполагаю, что это будет один или несколько из:
- доверьте сертификат цепи l1e
- доверьте сертификат цепи l1c
- доверить цепь L1E Сертификат (алгоритм SHA2)
- доверьте сертификат цепи L1C (SHA2)
вы можете проверить свою цепь с помощью s_client OpenSSL. На этот раз вы будете использовать сертификат Entrust:
echo -e "GET / HTTP/1.0\r\n" | openssl s_client -connect myserver:8443 \
-CAfile entrust-ca.pem
вы можете узнать entrust-ca.pem С Доверить Корневые Сертификаты. Запустите его и сообщите нам, какие ошибки вы получаете. Или лучше, разместите URL-адрес на своем сервере, чтобы мы могли видеть, что происходит.
у меня есть сертификат, который имеет следующую цепочку сертификации: доверьте - >мой CA - >мой выдающий CA - >мой сертификат JBoss....
Я думаю, у вас здесь две проблемы. Сначала скреплял Калифорния, и второй неполный клиентскую сеть.
во-первых, простой вопрос. Сервер должен отправить сертификат end entity (server) и любые промежуточные сертификаты для требуемой сборки цепочки. Сервер отправляет промежуточные сертификаты, чтобы избежать "каталог" проблема. "Какой каталог" является хорошо известной проблемой в PKI. По сути, клиент не знает, куда идти, чтобы получить недостающий промежуточный сертификат.
Итак, ваше первое решение для сервера, чтобы отправить цепи, с:
- промежуточного сертификата (мой ЦС')
- Ваш сертификат сервера ('мой сертификат JBoss')
во-вторых, у вас есть проблема ненадежного эмитента. Клиент должен доверять вашей внутренней выдаче КАЛИФОРНИЯ.
таким образом, ваше второе решение-убедиться, что ваш клиент доверяет вашему внутреннему CA ('My CA'). В этом случае клиенту не нужно даже использовать Entrust, так как точка доверия коренится во внутреннем CA.
вы можете отправить серверу цепочку с "мой CA", "мой выдающий CA" и "мой сертификат JBoss". В этом случае клиент должен доверять 'доверять'.
если клиент не доверяет ни "доверить", ни "мой CA", то вы получите подтверждение ошибки.
Я сделал один .PEM файл всех сертификатов, думающих, что это сработает. Это не так. Может кто-нибудь объяснить что я делаю неправильно или даже если это возможно?
в этом случае нам нужно будет увидеть сертификаты, чтобы увидеть, что происходит. Можете ли вы опубликовать URL-адрес, который обслуживает сертификат и использует цепочку; и опубликовать внутренний сертификат CA ('My 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 приводит к OK, то проблема заключается в браузере и точке доверия.