Цепочка сертификатов Apache не отправляется

2

Добрый день!

Я искал Google высоко и низко. Боже мой, я никогда не проходил страницу 2 результатов поиска раньше! Но этот ставит меня в тупик.

У меня есть веб-сайт, который я защищаю сертификатом, подписанным промежуточным сертификатом, подписанным самозаверяющим сертификатом CA. Кажется, что на каждом сайте stackexchange q / a и т. Д. Указано следующее:

  1. Свяжите свой сертификат сервера с промежуточным сертификатом, а затем с сертификатом CA. (т. е. cat apache.pem> chain_file; cat middleary.pem >> chain_file; cat ca.pem >> chain_file)
  2. Укажите этот новый файл в конфигурации ssl apache, используя SSLCertificateFile, поскольку SSLCertificateChainFile устарела.
  3. Проверьте с помощью браузера (или ssllabs.com или sslshopper.com), чтобы увидеть, если сертификат экспортируется.

Однако, когда я проверяю с помощью браузера, я вижу только сертификат сервера и не содержит промежуточных сертификатов или сертификатов CA. То же самое подтверждают и ssllabs и sslshopper.

Не хватает ли опции, которая гарантирует, что вы публикуете всю цепочку, а не только сертификат сервера?

Спасибо

apache-http-server ssl certificate ssl-certificate scuba_mike
источник
Вы не можете увидеть это в вашем браузере. Вы пробовали один из указанных сайтов?
Даниэль Б
Инструкции выглядят хорошо. Убедитесь, что сами сертификаты верны. (Может быть, ваш сертификат выдан другим промежуточным продуктом, чем вы пытаетесь связать?) Попробуйте также ssl-tools.net, чтобы проверить цепочку.
grawity
ДаниэльБ, да. То же самое было подтверждено и благодарностью ssllabs.com, и sslshopper.com, я тоже так думал, но я проверил тему и эмитента.
scuba_mike
Кроме того, я выполнил следующую команду: openssl verify -CAfile ca.pem -untrusted intermediary.pem apache.pem и это возвращение ОК.
scuba_mike
Это не проверяет конфигурацию вашего сервера, однако. Поскольку у вас есть OpenSSL, все довольно просто. Я скоро напишу ответ.
Даниэль Б

Ответы:

4

Если у вас есть OpenSSL, проверить это очень просто:

cat /dev/null | openssl s_client -showcerts -servername example.com -connect example.com:443

Я объясню компоненты:

  • cat /dev/null: openssl s_clientРаботает так же, как telnet. Он устанавливает соединение, и вы можете взаимодействовать с ним. Когда opensslвстречается EOF во входном потоке, соединение закрывается. cat /dev/nullнемедленно приводит к EOF. Кроме того, вы можете использовать CtrlDдля выдачи EOF на терминале.
  • openssl s_client: «Клиентская программа SSL / TLS»
  • -showcerts: Показать бланки сертификатов в формате PEM. В противном случае показывает только сертификат сервера.
  • -servername example.com: Установить имя сервера для SNI . Требуется при выполнении HTTPS на основе имен vhosts.
  • -connect example.com:443: Подключение к example.comпорту 443, стандартному порту HTTPS.

Это приводит к чему-то вроде этого:

$ cat /dev/null | openssl s_client -showcerts -servername inbox.google.com -connect inbox.google.com:443
CONNECTED(00000003)
depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority
verify return:1
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify return:1
depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = mail.google.com
verify return:1
---
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=mail.google.com
   i:/C=US/O=Google Inc/CN=Google Internet Authority G2
-----BEGIN CERTIFICATE-----
snip
-----END CERTIFICATE-----
 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
-----BEGIN CERTIFICATE-----
snip
-----END CERTIFICATE-----
 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
   i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
-----BEGIN CERTIFICATE-----
snip
-----END CERTIFICATE-----
---
Server certificate
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=mail.google.com
issuer=/C=US/O=Google Inc/CN=Google Internet Authority G2
---
No client certificate CA names sent
Peer signing digest: SHA256
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3767 bytes and written 469 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-GCM-SHA256
    Session-ID: 1B47CE2ADB10CE410C8048C3AAEF7CEF1B2B76C6D2DF5EDE78FE015A6DA44207
    Session-ID-ctx:
    Master-Key: E9AE458F6D72D507F422DA2340C7345AC6EDB087278E62A5FDA754897EC6BDF5C336AFBF6B88554E358C675A3545B724
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 100800 (seconds)
    TLS session ticket:
    snip

    Start Time: 1460049698
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
DONE

Я использовал домен Google здесь, потому что он имеет более глубокую цепочку сертификатов, чем example.com. Сертификат здесь имеет «Дополнительные имена субъекта» и, следовательно, также действителен для inbox.google.com.

Неправильно настроенный сервер может пропустить промежуточный сертификат, который здесь называется «Google Internet Authority G2». Сертификат Equifax является избыточным, потому что GeoTrust является установленным центром сертификации, которому напрямую доверяют ваш браузер.

Даниэль Б
источник
Спасибо за заметки. Я не знал о параметре servername. Этого не было на странице руководства. Как бы то ни было, при запуске он выдает «Ошибка gethostbyname connect: errno = 0» Разница между Google и мной заключается в том, что Google использует явный CN (например, mail.google.com), а я использую подстановочный сертификат. Нужно ли иметь явный сертификат сервера?
scuba_mike
Нет. Полученная ошибка указывает на то, что целевой хост ( -connectаргумент) не может быть решен. Это совершенно не связано с TLS, сертификатами и еще чем-то. Вы уверены, что у вас не было опечатки в командной строке?
Даниэль Б
Хм ... раньше у меня не было опечатки, но теперь она работает (s_client). Он показывает 3 сертификата, но они имеют глубину 0 и ту же информацию о сертификате, в данном случае сертификат для сервера. Но в каждой строке есть ошибка. Первая ошибка: verify error:num=20:unable to get local issuer certificate'. Second error: проверьте ошибку: num = 27: сертификат не является доверенным` Третья ошибка: verify error:num=21:unable to verify the first certificate если вы хотите попробовать, не стесняйтесь: aws.mikesoh.com
scuba_mike
Да, я нашел твою ошибку. Это еще один случай RTFM. ;) У вас есть Apache 2.4.7, но новая версия SSLCertificateFileдирективы, которая поддерживает промежуточные (или, в более общем случае: множественные) сертификаты, доступна только начиная с 2.4.8.
Даниэль Б
Frak! Хорошо, теперь Apache не запускается. Это дает мне ошибку X509_check_private_key:key values mismatch. сейчас проверяю в Интернете ...
scuba_mike
0

Спасибо Дэниелу Б. Проблемы были двоякими:

  1. Я использую немного старую версию apache. Я полностью пропустил это.
  2. После того, как я изменил конфигурацию обратно для использования SSLCertificateChainFileвместо этого, у меня все еще были проблемы с использованием openssl s_client.

Оказывается, за номером 2 мне пришлось раскомментировать строку.

Спасибо всем!

scuba_mike
источник