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

Question

Добрый день!

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

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

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

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

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

Спасибо

Answer 1

Если у вас есть 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. Кроме того, вы можете использовать Ctrl D для выдачи 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 является установленным центром сертификации, которому напрямую доверяют ваш браузер.

Answer 2

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

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

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

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