web-dev-qa-db-ja.com

SSL証明書を更新し、Apache2でリライト条件が機能しなくなった

Apache2v2.4.7でUbuntu14.04サーバーを実行しています。

最近、私たちのサイトでChromeから、証明書を更新する必要があるというエラーが発生しました。今週初めにSSL証明書を更新してから、Apacheを再起動しました。数日レイヤー、クライアント戻ってきて、特定の画像とファイルにレポートサーバーからアクセスできなくなったと述べました。レポートサーバーはHTTPSを使用して画像とファイルにアクセスしていました。

私のconfファイルにはこれがありますが、このサーバーを継承してから変更されていません。

<VirtualHost *:80>
    ServerName abc.example.com
    DocumentRoot /home/deployer/html/_abc/public
    RewriteEngine On

    RewriteCond %{HTTPS} off
    RewriteCond %{REQUEST_URI} !^/files/
    RewriteCond %{REQUEST_URI} !^/images/checksheets/
    RewriteRule (.*) https://%{HTTP_Host}%{REQUEST_URI} [R,L]
</VirtualHost>

<VirtualHost *:443>
    ServerName abc.example.com
    DocumentRoot /home/deployer/html/_abc/public
    SSLEngine on
    SSLProtocol all -SSLv2 -SSLv3
    SSLCipherSuite          ECD....C3-SHA:!DSS
    SSLHonorCipherOrder     on
    SSLCompression          off
    SSLCertificateFile /etc/ssl/ssl_certificate.crt
    SSLCertificateKeyFile /etc/ssl/abc_staging.key
    SSLCertificateChainFile /etc/ssl/IntermediateCA.crt
    # HSTS (mod_headers is required) (15768000 seconds = 6 months)
    Header always set Strict-Transport-Security "max-age=15768000"
    <Directory /home/deployer/html/_abc/public>
        AllowOverride all
        Options FollowSymLinks
        # -MultiViews
        #   Order allow,deny
        Require all granted
    </Directory>

私がサーバーで行った唯一のことは、文字通りssl_certificateとIntermediateCAを更新し、Apacheを再起動することでした。そのため、何が起こったのかわかりません。 SSL証明書が最後に更新されたのは、おそらく約1年前であり、レポートサーバーが画像/ファイルを取得する方法は変更されていません。また、Apacheをかなり頻繁に再起動しますが、これは以前は問題になりませんでした。

気まぐれに、私のクライアントはhttpの代わりにhttpsを使用して新しいレポートを作成しましたが、それは完全に正常に機能しているように見えました。

私の質問は、サーバーが画像/ファイルのhttps接続を突然受け入れなくなるように変更した可能性があるということです。

編集：これらはGETリクエストのみです（POST/DELETEアクションはありません）。

また、HTTPSを使用してhttps://abc.example.com/images/path/to/file.jpgとしてイメージ（またはファイル）に移動すると、完全に正常に機能します。ただし、レポートサーバーが同じリンクを使用すると、空白のページが表示されます。

Apacheアクセスログには、直接ナビゲートするときにヒットとして上記のリンクが表示されますが、レポートサーバーがそれを使用し、レポートに移動すると、Apacheアクセスログには何も表示されません。

apache-2.4ssl-certificaterewritecond
3
risa_risa

私たちはそれを理解しました。 Apacheサーバーはそのままで問題ありませんでしたが、以前は特定のDHパラメータスニペットが証明書ファイルに保存されていたようです。このスニペットが追加されたのは、画像とファイルを要求するレポートサーバーがJava 6で実行されているためです。またJava 6は1024ビットのDHパラメーターしか処理できません。

だから私の新しいssl_certificate.crt、 追加した

-----BEGIN DH PARAMETERS-----
MIGHAoGBAP//////////yQ/aoiFowjTExmKLgNwc0SkCTgiKZ8x0Agu+pjsTmyJR
Sgh5jjQE3e+VGbPNOkMbMCsKbfJfFDdP4TVtbVHCReSFtXZiXn7G9ExC6aY37WsL
/1y29Aa37e44a/taiZ+lrp8kEXxLH+ZJKGZR7OZTgf//////////AgEC
-----END DH PARAMETERS-----

から http://httpd.Apache.org/docs/current/ssl/ssl_faq.html#javadh

残念ながら、これにより証明書がA +評価からBにダウングレードされますが、Javaサーバーを6から新しいサーバーにアップグレードすることは許可されていません。

そのスニペットをSSL証明書に追加すると、レポートサーバーはhttpsを介して画像にアクセスできるようになりました。

0
risa_risa

<VirtualHost *:443>でHSTSを有効にします。これは、ドメインに対するすべてのリクエストを内部的にHTTPSに書き換えるようにブラウザに指示します。この後、RewriteCond %{REQUEST_URI} !^/files/は使用されなくなります。これは、すべてがすでに無条件に書き換えられているため、構成を簡素化する可能性があるためです。

<VirtualHost *:80>
    ServerName abc.example.com
    Redirect permanent / https://abc.example.com/
</VirtualHost>

空白ページの問題は、Apacheが原因のサーバー側の問題ではないようです。別のコンピューターからURLにアクセスできるという事実は、それをほぼ証明しています。

まず、「レポートサーバー」のすべてのキャッシュをクリアし、それが役立つかどうかを確認します。この「レポートサーバー」がどのように機能するかについての詳細はありませんが、空白のページは、たとえば、混合コンテンツポリシーが変更されたために、HTTPSページにキャッシュされたHTTPURLイメージを表示しなかった結果である可能性があります。その場合、リダイレクトとHSTSポリシー間の一貫性により、将来そのようなキャッシュが妨げられる可能性があります。

また、コンテンツのすべてのhttp://URLをhttps://に修正します。

1
Esa Jokinen

トラブルシューティングの提案：

  1. 環境を確認してください：

    • Apache2v2.4.7を搭載したUbuntu14.04サーバー。
    • Httpd.confは、HTTP（：80）とHTTPS（：443）の両方を提供するように構成されています。
    • 証明書の構成（上記に投稿）は正しく、ファイルと（SSLCertificateFileなど）はすべて存在し、「破損」していません。

  2. 問題の説明を確認してください：

    • SSL証明書を更新する前の「以前はすべてが機能していた」、「問題」は新しい証明書と関係があります。
    • Https（EXAMPLE https://Apache-server.com/myreport ）を介して「レポートを取得」しようとするすべてのユーザーは失敗します-「白」が表示されるだけです。これは正しいです？
    • 同じユーザーが代わりにhttp（例： http://Apache-server.com/myreport ）を使用すると、同じレポートを正常に取得できます。これも正しいですか？
    • レポートについて「特別な」ことはありますか？たとえば、それはWebアプリケーションですか？

  3. [〜＃〜] all [〜＃〜]httpsが「壊れている」のか、それとも「いくつかのもの」にアクセスできないのか知りたいです。

    テストファイルを作成してください（例：/var/www/html/myreport/hello.html）そしてhttpとhttpsの両方でそれを読むことができるかどうかを確認します。

  4. テストするときは、PCでこれらのツールの1つ（または両方）を使用して、ブラウザーの接続の試みを分析してください（したがって、特定の障害点を特定するのに役立ちます）。

  5. 見つけたものを投稿してください。

PS：

ここにいくつかの追加のヒントがあります。特に、「詳細ログを有効にする」：

https://www.futurehosting.com/blog/troubleshooting-the-most-common-Apache-problems-youll-encounter/

PPS：

問題が解決するまで、httpを無効にしません[〜＃〜]しません[〜＃〜]：

  • 他に何もないとしても、それはレポートを必要とするかもしれない人々のための一時的な回避策です。
  • Httpとhttpsの動作を比較できると、トラブルシューティングに役立ちます。
1
paulsm4