【OCI_22】ロード・バランサでHTTPSパススルーしてWEBサーバの自己署名証明書で終端する
前回の検証で自己署名証明書を作成し、ロード・バランサへ適用してHTTPS通信を検証することができました。
今回は、前回の検証環境を再利用してロード・バランサでHTTPSパススルー設定を行い、WEBサーバの自己署名証明書で終端するよう検証してみます。
必要な作業は、以下２点です。
１．WEBサーバへ自己署名証明書を適用
２．ロード・バランサのHTTPSパススルー設定
目次
WEBサーバへ自己署名証明書を適用
まずはWEBサーバへ自己署名証明書を適用し、クライアント端末からロード・バランサを介さず、直接WEBサーバへアクセスしてhttps通信（https://www.20251227.com）できることを確認します。
WEBサーバは以下２台を利用します。
※前回検証をそのまま再利用していましたが、クライアント端末からファイルをアップロードする際に鍵ファイルが壊れたのかログインできなくなりました。そのためインスタンスを1台だけ再作成しています。
WEBサーバへ適用するサーバ証明書と秘密鍵は、ロード・バランサへ適用したものと同じものを利用します。
WEBサーバへサーバ証明書と秘密鍵を配置
サーバ証明書と秘密鍵をクライアント端末からOCIのWEBサーバへアップロードします。
Teratermのユーザーを必ず「opcユーザー」に切り替えてください。「rootユーザー」で接続すると鍵ファイルが壊れる可能性があります。
サーバ証明書と秘密鍵をTeratermへドラッグアンドドロップすると以下の画面が表示されます。
送信先はブランクとして「OK」をクリックします。
■サーバ証明書
■秘密鍵
サーバ証明書と秘密鍵が /home/opc ディレクトリ配下に保存されました。
アップロードしたサーバ証明書と秘密鍵を指定の場所へ配置
/home/opcディレクトリ配下のファイルを以下の場所へコピーします。
ディレクトリが存在しない場合は作成してください。
サーバ証明書 ： /etc/ssl/certs/lb-server.crt
秘密鍵 ： SSLCertificateKeyFile /etc/ssl/private/lb-server.key
cd /home/opc/
cp -ip lb-server.crt /etc/ssl/certs/
ls -l /etc/ssl/certs/
mkdir /etc/ssl/private
cp -ip lb-server.key /etc/ssl/private/
ls -l /etc/ssl/private/
SSL設定ファイル（/etc/httpd/conf.d/ssl.conf）の編集
SSL設定ファイル（/etc/httpd/conf.d/ssl.conf）を編集します。
存在しない場合は、Apache(httpd) のSSL用設定（mod_ssl）が入っていない／有効になっていない可能性が高いです。
パッケージマネージャでmod_sslがインストールされているか確認します。
dnf list installed | grep mod_ssl
mod_sslがインストールされていないのでインストールします。「Complete!」が表示されればインストール成功です。
dnf -y install mod_ssl
もう一度パッケージマネージャで確認すると、mod_sslがインストールされていることが確認できました。
dnf list installed | grep mod_ssl
/etc/httpd/conf.d/ ディレクトリ配下にssl.confファイルが生成されました。
/etc/httpd/conf.d/ssl.conf の一番下へ以下を追記します。
＜VirtualHost *:443＞ と ＜/VirtualHost＞ はもともとssl.confに記載されていると思います。重複するとエラーになるわけではないですが、検証以外では混乱を避けるため１つにまとめることを推奨します。今回は検証で重複して記載しますが・・・
<VirtualHost *:443>
ServerName www.20251227.com
DocumentRoot "/var/www/html"
SSLEngine on
SSLCertificateFile /etc/ssl/certs/lb-server.crt
SSLCertificateKeyFile /etc/ssl/private/lb-server.key
<Directory "/var/www/html">
Options -Indexes +FollowSymLinks
AllowOverride All
Require all granted
</Directory>
ErrorLog logs/ssl_error_log
TransferLog logs/ssl_access_log
LogLevel warn
</VirtualHost>
Apache（httpd）を再起動します。
systemctl restart httpd
hosts設定と動作確認
クライアントのhostsファイルにWEBサーバのIPアドレスとFQDN名を記載します。
まずはWEBサーバ1号機を記載してPINGが通ることを確認します。
（OCIのセキュリティ・リストでICMPを許可してない場合は、許可してください）
クライアント端末のブラウザから「https://www.20251227.com」へアクセスし、httpsの通信が証明書エラーなく表示されることを確認します。
次にhostsファイルの内容をWEBサーバ2号機へ変更し、PINGとブラウザからのアクセスを確認します。
ロード・バランサでHTTPSパススルーを設定
WEBサーバ1号機、2号機で自己署名証明書の準備ができたのでOCIのロード・バランサをHTTPSパススルーに変更します。
https通信は、ロード・バランサを介しますがHTTPSパススルーしてWEBサーバで終端されることを検証します。
ポイントとしては、以下3点です。
リスナー ： TCP
バックエンド ： HTTPS (TCP/443)
証明書はFLBに設定しない
バックエンド・セットの作成
本来は前回検証したバックエンド・セットのプロトコルを変更すればよかったのですが、インスタンスが1台接続できなくなったため、バックエンド・セットを再作成します。
バックエンド・セットの作成画面で任意の名前を入力します。
ヘルス・チェック画面で以下を入力、選択します。（※値は、デフォルトでロード・バランサを構成した時に表示されている値を入力しています）
プロトコル：TCP
ポート：443
間隔（ミリ秒）：10000
タイムアウト（ミリ秒）：3000
再試行回数：3
次に作成したバックエンド・セット名をクリックします。
「バックエンド」タブを選択し、「バックエンドの追加」をクリックします。
バックエンド・タイプで「コンピュート・インスタンス」を選択します。
インスタンスを追加し、ポートを「443」に変更します。
「セキュリティ・リスト・ルールを自動的に追加します」が選択された状態で「追加」をクリックします。
バックエンドが追加され、ヘルスが「クリティカル」になりましたが5分ほど経過すると「OK」になりました。
リスナーの作成
バックエンド・セットを再作成したのでリスナーも再作成したいと思います。
「リスナー」タブの「リスナーの作成」をクリックします。
リスナーの作成画面で以下を入力、選択し、「リスナーの作成」をクリックします。
名前：任意のリスナー名
プロトコル：TCP
ポート：443
SSLの使用：OFF
バックエンド・セット：再作成したバックエンド・セット
その他はデフォルト設定
作業リクエストが「成功」することを確認し、画面を閉じます。
リスナーが作成できました。
ロード・バランサ画面に戻り、状態が「アクティブ」、全体的なヘルスが「OK」であることを確認します。
これでHTTPSパススルー設定は完了しました。
hosts設定と動作確認
クライアントのhostsファイルにロード・バランサのIPアドレスとFQDN名を記載します。
クライアント端末からロード・バランサのIPアドレスやFQDNへPINGがとおりました。
クライアント端末からブラウザで接続
クライアント端末からブラウザでURL（https://www.20251227.com）へ接続してロード・バランサを介してHTTPSパススルーでWEBサーバがhttpsで表示されました。
うまく表示できましたが、F5キーでページ更新をしても数秒後でないとWEBサーバが切り替わりませんでした。Chatgptに聞くとこれはFLBのHTTPSパススルー（TCP）で仕様どおりの挙動だそうです。負荷分散は「TCPコネクション単位」で行われ、ブラウザでの挙動は、F5キーで更新しても既存のTCP接続を再利用（KeepAlive）します。結果、同じTCP接続なので同じバックエンド（同じWEBサーバ）に固定されます。数秒待つとTCP接続が切れて次の接続で別サーバに振り分けられます。このあたりは、今後の課題として検証していけたらと思います。
以下、他の記事をまとめた一覧です。OCI以外にAWSもまとめています。
