【Linux】TLS1.2対応目的のリバースプロキシサーバーをApacheで作成

自社のコーポレートサイトで利用しているサーバーが古めのCentOSで稼働しており、SSLのバージョンが古く、TLS1.2へすぐに対応させることが困難だったため対策を後回ししていたら、遂にChromeでもhttpsサイトで警告が・・・。

そこで今回は緊急回避策として、リバースプロキシサーバーを新しく構築し、諸事情でTLS1.2対応ができないWebサーバーでもhttpsサイトで警告がでないようにする手順を紹介します。

当手順における動作環境
システム構成図と構成の概要
TLS 1.2対応のためのリバースプロキシサーバー構築時のポイント
具体的な設定箇所の紹介と解説
最後に

当手順における動作環境

今回の作業では以下の環境で実施しています。
多少バージョンが当環境と異なっていても、作業内容は変わり無いはずです。

Webサーバー
OS　　：CentOS 5.11
Apache：2.2.3
OpenSSL：0.9.8

リバースプロキシサーバー
OS　　：CentOS 7.8
Apache：2.4.6
OpenSSL：1.0.2

システム構成図と構成の概要

当記事を読んでいる時点で、今回の作業の内容は理解されていると思うので、構成をビジュアル化する必要はあまり無さそうですが、一応構成図を用意しました。

既存の構成は一般的なWebサーバーです。
LinuxサーバーでApacheを構築し、ウェブコンテンツを公開しています。
サーバー証明書を使用し、httpsサイトでアクセスできるようにしてあります。
ただ、OpenSSLのバージョンが古いため、TLS1.2に対応していません。
その為、7月からGoogle Chromeで当WebサイトにhttpsのURLでアクセスすると警告が出るようになりました。

だったら、OpenSSLのバージョンを上げればよいと考えるのが普通ですが、既存環境に影響を与えないようにOpenSSLのバージョンを上げるのも簡単ではありません。

その為、今回はWebサーバーの手前に「リバースプロキシサーバー」を構築し、Webサーバーへのhttp及びhttpsの通信についてはすべてリバースプロキシサーバーを中継するようにします。
その構成を構築することで、Webサーバー自体はhttpでのみアクセスされることになり、OpenSSLのバージョンが古くても問題は無くなります。

因みに、上記で「Webサーバーの手前にリバースプロキシサーバーを構築」と記載しましたが、正確には現在のWebサーバーと同じネットワーク環境下に新規サーバーを構築することができない制約があり、別のネットワークにリバースプロキシサーバーを構築しています。
そのネットワーク間はVPNも無いので、お互いはグローバルIP等でインターネット越しに通信します。

あと、今回の問題の本質は、Webサーバー自体の環境が色々と古いことで発生している問題であり、根本の解決方法はWebサーバーを新しい環境に移行することです。
よって、あくまで今回の「リバースプロキシサーバー」での「TLS1.2対応」は一時的な暫定処置になります。

TLS 1.2対応のためのリバースプロキシサーバー構築時のポイント

当項では、TLS 1.2対応を目的としたリバースプロキシサーバーを構築する際に必要となる作業や設定変更内容を箇条書きで列挙します。

リバースプロキシサーバー用のグローバルIPアドレスを取得又は割り当てる。
対象のWebサイト用URLで使用しているドメイン又はサブドメインに対するAレコードはリバースプロキシサーバーのグローバルIPアドレスに変更する。
Webサーバー(CentOS 5.11)上で作成した秘密鍵やCSRを元に作成したSSL証明書や中間証明書は、リバースプロキシサーバー(CentOS 7.8)へそのまま移行が可能。※CSR再作成→SSL証明書再発行は不要。
Webサーバー側でドメインではなくグローバルIPアドレスでのWebアクセスを許容するようにApacheの設定を変更する。
クライアントからリバースプロキシサーバー宛にhttpでアクセスが来たら、httpsにリダイレクトさせる。

具体的な設定箇所の紹介と解説

当項では、TLS1.2対応のためのリバースプロキシサーバー構築における、具体的な設定箇所や内容を紹介していきます。

Webサーバー側 IPアドレス接続許可設定

Webサーバーをインターネットに公開する場合、通常はグローバルIPアドレスを直打ちしたURLでの接続を禁止し、ドメインが使われたURLでの接続のみを許可します。

https化したWebサイトでは、SSL証明書発行時に登録したFQDNと実際にアクセスするURLで使用するFQDNが一致していないと、対象のウェブサイトにへのアクセス時に証明書のエラーが出るからであり、そのエラーを発生させないためにIPアドレス直打ちでのWebサーバーへのアクセスすることをWebサーバー側の設定で禁止します。

ただ、今回はWebサーバーに割り当てていたドメインのAレコードを、リバースプロキシサーバーに割り当てたグローバルIPに変更します。
その為、リバースプロキシサーバーからWebサーバーへの接続については、ドメインではなく、IPアドレスを直打ちしてアクセスさせることになります。
よって、Webサーバー側のIPアドレスを使用したWebサーバーへのアクセスを許容するよう変更が必要になります。

例えばバーチャルホストでWebサーバーを運用しているなら、httpd.confやssl.confなどに設定したバーチャルホスト関連の設定を以下の様に変更します。

# ServerNameディレクティブでFQDNを指定していたところをIPアドレスに変更
<VirtualHost *:80>
    # ServerName www.example.com
    ServerName 111.222.333.444

因みに、検証などで、一時的にIPアドレスでのアクセスを受け付けつつ、ドメインでの接続も従来通り受けられるようにしたい場合は以下のようにしても良いです。
※私がリバースプロキシサーバー本番切り替え前のリバースプロキシサーバー動作検証時には以下の設定を入れていました。

<VirtualHost *:80>
    ServerName www.example.com
    ServerAlias 111.222.333.444

Apacheでは、IPアドレスベースでのアクセス制御のやり方は色々あるので、上記の方法以外にもやり方はありますが、要は今回の要件だとIPアドレスでWebサーバーにアクセスできれば何でも良いので、現在の環境で実装しやすいやり方を選択して頂ければよいかと思います。

リバースプロキシサーバー側リバースプロキシ設定

今回の記事の主となるリバースプロキシサーバーの設定方法を紹介します。
リバースプロキシサーバーの設定はApacheのhttpd.confやssl.confなどに記述するバーチャルホスト設定内で指定します。

まずはhttpsでアクセスがリバースプロキシサーバーに来た場合の転送処理をssl.confやhttpd.confなどに記述します。
どのconfファイルに記載すべきかは環境によって異なります。
取り敢えず、ポート443でアクセスが来た場合のバーチャルホストの設定箇所に以下のように記述してください。

# リバースプロキシサーバーのグローバルIP直打ちや不正な名前でのアクセスを拒否
# 必ずアクセス拒否の設定をVirtualHost設定の一番上に書くこと
<VirtualHost *:443>
    ServerName any
    SSLEngine on
    # 以下のSSL証明書や秘密鍵の位置は環境に合わせて書き変えてください。
    SSLCertificateFile /etc/httpd/conf/ssl/ssl.crt/server.crt
    SSLCertificateKeyFile /etc/httpd/conf/ssl/ssl.key/server.key
    <Location />
        Order deny,allow
        Deny from all
    </Location>
</VirtualHost>

# 正式な名前でアクセスされた場合にリバースプロキシで転送
# 初期のssl.confではデフォルトのバーチャルホスト設定の指定が有効になっているので、
# _default_の指定をコメント化し、<VirtualHost *:443>に書き換えます。

#<VirtualHost _default_:443>
<VirtualHost *:443>

    # VirtualHost設定の最下部に以下を追加
    
    ProxyRequests Off
    ServerName www.example.com
    # 転送先URL※必須
    ProxyPass / http://111.222.333.444/
    # Webサーバー側でリダイレクトなどが発生した場合のLocation書き換え用URL
    # パスが変わらなければ記載不要
    ProxyPassReverse / https://www.example.com/
    # 以下のログの場所は必要によって書き変えてください。
    Customlog logs/example.com.log Combinedenv=!no_log
    ErrorLog logs/example.com.error_log
</VirtualHost>

上記設定をバーチャルホストの設定に入れることで、リバースプロキシサーバーとして動作するようになります。
また、上記の設定では、正しいFQDN(例では「www.example.com」)でアクセスしてきた場合のみリバースプロキシでWebサーバーに転送し、IPアドレス直打ちなどそれ以外の場合は403エラーを返します。

また、バーチャルホストのIP直打ち拒否設定は、必ずリバースプロキシ設定の入ったバーチャルホストの設定位置より上段に記載してください。
_default_:443 のバーチャルホスト設定を消しているため、クライアントからアクセスされてきた場合に、ServerNameで指定されたバーチャルホスト設定が存在しない場合は、バーチャルホスト設定の一番上段(一つ目)の設定が使用されます。
今回はそのApacheの仕様を利用してアクセス可否をコントロールしています。

リバースプロキシサーバー側 httpリダイレクト設定

リバースプロキシサーバーに対して、httpのURLでアクセスしてきた場合に、強制的にhttpsのURLにリダイレクトする設定も入れておきます。
当設定もバーチャルホストの処理で実装します。

<VirtualHost *:80>
    ServerName www.example.com
    RewriteEngine on
    RewriteCond %{HTTPS} off
    RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R,L]
    # 以下のログの場所は必要によって書き変えてください。
    Customlog logs/example.com.log Combinedenv=!no_log
    ErrorLog logs/example.com.error_log
</VirtualHost>

この設定をバーチャルホストに入れておくことで、http://www.example.com でアクセスされた場合、強制的にhttps のURLにリダイレクトします。
また、もし正しいFQDNやリバースプロキシサーバーのIPアドレス直打ちでアクセスしてきた場合は、前述のポート443の場合の正規FQDN以外のアクセスを拒否する設定が効いて、クライアントへエラーを返します。

最後に

今回はTLS1.2対応のためのリバースプロキシサーバーの構築方法を紹介しました。
私自身、Linuxはそれほど詳しくはないため、内容に誤りがあるかも知れませんが、私が運用しているサーバ環境では正常に動作しています。

ただ、リバースプロキシサーバーを介したWebサーバーへのアクセスに変更した場合は、Googleアナリティクスへの集計やSEOでも影響がでます。
よって、TLS1.2対応を目的としたリバースプロキシサーバー対応については、前述したように一時的な暫定対応として運用することを推奨します。

今回も読んでいただきましてありがとうございました。
また次回もよろしくお願いいたします。