web-dev-qa-db-ja.com

421 HTTP / 2およびSAN SSLを使用した誤った要求

UbuntuでApache2.4.20を実行していて、SSLを構成しています。 SAN SSL証明書とwww.example.comとwww2.example.comが同じ証明書を共有しています。

以下を含めると、421 Misdirected Requestエラーが発生します。

Protocols h2 h2c http/1.1
H2Upgrade on
H2Direct
H2WindowSize 128000

削除すると、ウェブサイトは正常に動作します。

同じブラウザでwww.example.comおよびwww2.example.comを開くと、エラーが発生します。最初にwww.example.comにアクセスすると、正しく読み込まれます。そのSAN SSL証明書、たとえばwww2.example.comから2番目のサイトをロードすると、エラーが発生します。最初にどのサイトにアクセスしてもかまいません。 2番目のサイトでは常に421 Misdirected Requestで応答します。

HTTP/2ディレクティブの使用の何が問題になっていますか？ （ちなみに、それらはVirtualHostにあります）

または、HTTP/2とSAN SSLの実装に問題がありますか？

また、重要な場合は、www.example.comとwww2.example.comの両方がAWSでホストされている同じサーバー上にあります。

ありがとう。

編集：

以下の設定も試してみましたが、同じ結果になりました。

Protocols h2 http/1.1
H2Direct
H2WindowSize 128000

SSL構成内

<IfModule mod_ssl.c>

    SSLRandomSeed startup builtin
    SSLRandomSeed startup file:/dev/urandom 512
    SSLRandomSeed connect builtin
    SSLRandomSeed connect file:/dev/urandom 512

    AddType application/x-x509-ca-cert .crt
    AddType application/x-pkcs7-crl .crl

    SSLPassPhraseDialog  exec:/usr/share/Apache2/ask-for-passphrase

    SSLSessionCache     shmcb:${Apache_RUN_DIR}/ssl_scache(512000)
    SSLSessionCacheTimeout  300

    SSLOpenSSLConfCmd DHParameters "/path/dhparams.pem"

    SSLCipherSuite ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS

    SSLHonorCipherOrder on

    SSLCompression Off
    SSLSessionTickets Off

    SSLUseStapling On
    SSLStaplingResponderTimeout 5
    SSLStaplingReturnResponderErrors off
    SSLStaplingCache shmcb:${Apache_RUN_DIR}/ssl_stapling(32768)

    SSLProtocol all -SSLv3

    SSLInsecureRenegotiation Off
    SSLStrictSNIVHostCheck Off

</IfModule>

VirtualHost内

<IfModule mod_ssl.c>
  <VirtualHost *:443>
    ServerAdmin [email protected]
    ServerName www.example.com
    DocumentRoot /path/path

    Protocols h2 http/1.1
    H2Direct on
    H2WindowSize 128000

    SSLEngine on
    SSLCACertificateFile /path/cert.crt
    SSLCertificateFile /path/cert.crt
    SSLCertificateKeyFile /path/key.key

    SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
    Header always set Strict-Transport-Security "max-age=15768000; includeSubDomains; preload"

    <Directory /path/path>
        AllowOverride None
        Require all granted
    </Directory>

 </VirtualHost>
</IfModule>
sslamazon-web-servicesapache-2.4httpsubuntu-14.04
2
jarvis

これは私にとって本当の問題でした。しかし、私は答えを見つけましたここ 。

複数のホストと誤った要求

多くのサイトは、複数の仮想ホストに同じTLS証明書を使用しています。証明書には、「* .example.org」などのワイルドカード名が付いているか、いくつかの代替名が付いています。 HTTP/2を使用するブラウザはそれを認識し、そのようなホストに対してすでに開かれている接続を再利用します。

これはパフォーマンスには優れていますが、代償が伴います。このようなvhostは、構成にさらに注意を払う必要があります。問題は、同じTLS接続上の複数のホストに対して複数の要求があることです。そしてそれは再交渉を不可能にします、HTTP/2標準がそれを禁じているのに直面して。

したがって、同じ証明書を使用する複数の仮想ホストがあり、それらにHTTP/2を使用する場合は、すべての仮想ホストがまったく同じSSL構成を持っていることを確認する必要があります。クライアントの検証には、同じプロトコル、暗号、および設定が必要です。

物事を混在させると、Apache httpdがそれを検出し、特別な応答コード421 MisdirectedRequestをクライアントに返します。

同じ証明書を共有する3つのVirtualHostがあります。どちらも「デフォルト」のSSL設定を使用して構成されています。最後の1つは、多くのブラウザーと互換性があるために最後の1つを必要としなかったため、特別な構成でした。そのため、最新の暗号と最新のSSLプロトコルのみを使用しました。その特定の「特別な」VirtualHostは421を取得していました。

Protocol h2 http/1.1を無効にすると問題は解決しますが、無効にしたくありませんでした。

同じ証明書を共有するすべてのVirtualHostで同じ構成を使用した後、問題が修正されました。

5
jarvis

私は今日この問題に遭遇し、最初は少し戸惑いました。異なる暗号などを使用していなかったため、上記の回答の「混合した場合」のメモが実際に何であるかを理解できませんでした。さて、SSLCertificateFileとSSLCertificateKeyFileの内容が同じであり、ファイルが互いに同一のコピーである場合でも、十分ではないことが判明しました。これらの構成設定は、まったく同じファイルを指している必要があります。これは、実際に問題が発生しているのはブラウザーではなく（当初はそうだと思っていた）、Apacheは構成が同じではないことをすでに検出しており、ブラウザーのそれが実際にページを配信した場合は問題が発生します（おそらく実際に発生する可能性が非常に高いです）。 Apacheは、対応するエラーをログファイルに書き込んでいます（「SNI経由で提供されるホスト名www.example.comおよびHTTP経由で提供されるホスト名www2.example.comには互換性のあるSSL設定がありません」）。このセットアップ互換性テストはかなり単純なようで、証明書が実際に同じであるという事実を気にしません。おそらく、異なるファイル名/パスに気付くだけで、それからボークします。

0
Ranjan