web-dev-qa-db-ja.com

Apache証明書チェーンが送信されていません

良い一日！

私はグーグルの高低を検索しました。良かった、私はこれまで検索結果の2ページを超えたことがありません！しかし、これは私を困惑させます。

自己署名CA証明書で署名された、中間証明書で署名された証明書で保護しているWebサイトがあります。すべてのウェブサイトのstackexchangeq/aなどは、次のことを示しているようです。

  1. サーバー証明書を中間証明書と連結し、次にCA証明書と連結します。 （つまり、cat Apache.pem> chain_file; cat intermediary.pem >> chain_file; cat ca.pem >> chain_file）
  2. SSLCertificateChainFileは非推奨になっているため、SSLCertificateFileを使用してApachessl構成でこの新しいファイルをポイントします。
  3. ブラウザ（またはssllabs.comまたはsslshopper.com）で、証明書がエクスポートされているかどうかを確認してください。

ただし、ブラウザで確認すると、サーバー証明書のみが表示され、中間証明書やCA証明書は含まれていません。同じことがssllabsとsslshopperの両方で確認されています。

サーバーの証明書だけでなく、チェーン全体を公開することを保証するオプションがありませんか？

ありがとう

apache-http-serversslcertificatessl-certificate
2
scuba_mike

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：証明書のblobをPEM形式で表示します。それ以外の場合はサーバー証明書のみを表示します。
  • -servername example.com：サーバー名を [〜＃〜] sni [〜＃〜] に設定します。 HTTPS名ベースのvhostを実行する場合に必要です。
  • -connect example.com:443：標準のHTTPSポートであるポートexample.comで443に接続します。

これにより、次のような結果になります。

$ 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

ここでは、example.comよりも証明書チェーンが深いため、Googleドメインを使用しました。ここでの証明書には「サブジェクト代替名」が含まれているため、inbox.google.comにも有効です。

正しく構成されていないサーバーは、ここでは「Google InternetAuthorityG2」と呼ばれる中間証明書をスキップします。 GeoTrustはブラウザで直接信頼される確立されたCAであるため、Equifax証明書は一種の冗長です。

4
Daniel B

DanielBに感謝します。問題は2つありました。

  1. 少し古いバージョンのApacheを実行しています。私はこれを完全に見逃しました。
  2. 代わりにSSLCertificateChainFileを使用するように構成を変更した後も、openssls_clientの使用で問題が発生しました。

2番であることが判明し、私はその行のコメントを外さなければなりませんでした。

みんな、ありがとう！

0
scuba_mike