【OCI_21】自己署名証明書を作成し、ロード・バランサへ適用してHTTPS通信を検証する

2025/12/30

この記事を書いている人 - WRITER -

ブログ運営者のtkjzblogです。仕事柄新しいシステムに触れることが多いです。 Windows、Linux（RHEL）がメインです。その他、VMwareやOffice365など仮想環境やクラウド環境も少しですが触れることがあります。いろいろ忘れがちのため、このサイトへ情報を書き溜めていきたいと思います。どうぞ、よろしくお願い致します。

今回は、OCI のロード・バランサ（FLB）に自己署名証明書を適用し、クライアント（ブラウザ）側からアクセスしても証明書エラーが出ない状態を目指します。WEBサーバは、OCIのOracleLinuxを利用しています。

ポイントは2つです
　・LBにはPEM形式の「サーバ証明書＋秘密鍵」を設定
　・クライアントには「その証明書を信頼するための CA 証明書」をインストール

自己署名証明書でも「クライアントがその発行元（CA）を信頼している」状態にすれば、ブラウザの警告は表示されません。
VCNやサブネット、インスタンスの作成の手順などは過去のリンクを案内するにとどめている箇所もありますのでご了承ください。

当検証は、有償アカウントで検証しています。無償アカウントと挙動が異なる場合がありますのでご了承ください。

1 VCN、サブネット（パブリック）、インターネットゲートウェイ、ルート・ルール、セキュリティ・リスト、インスタンスの作成
- 1.1 インターネットゲートウェイを作成
- 1.2 インスタンスの作成と設定
2 ロード・バランサの作成
3 自己署名証明書の作成
4 ロード・バランサへ証明書を適用
5 クライアント側に CA 証明書をインストール
6 まとめ

VCN、サブネット（パブリック）、インターネットゲートウェイ、ルート・ルール、セキュリティ・リスト、インスタンスの作成

【OCI_17】ウィザードを利用せず個別にVCN、ゲートウェイなどコンポーネントを設定してみる

自身でも忘れがちでいつもミスする箇所だけポイントとして記載しています。
検証なのでセキュリティ・リストはゆるい設定にしています。

インターネットゲートウェイを作成

インターネット・ゲートウェイを作成します。（※ルート表への関連付けは、不要 [失敗します]）
ルート表（Default Route Table for 20251028_vcn）のルート・ルールへインターネット・ゲートウェイへのルートを追加します。

ルート表（Default Route Table for dnslabel-on）にインターネットゲートウェイのルート・ルールを追加

インスタンスの作成と設定

インスタンスの作成は、以下を参考にしてください。

【OCI_04】VCN、インスタンスを作成する

次にWEBサーバのApacheインストールやファイアウォール設定は、以下を参考にしてください。

【OCI_09】カスタム・イメージの作成と起動

【RHEL】ファイアウォール設定（firewalld）

設定が完了したらクライアント端末のブラウザからアクセスしてみます。設定に問題なければクライアントからOCI上のWEBサーバへhttpでアクセスしてWEBページを表示することができます。

ロード・バランサの作成

ここからはもう少し詳しく記載していきます。

ロードバランサー用セキュリティ・リストの作成

ロードバランサー用セキュリティ・リスト（LB_Security_List）を作成して、セキュリティ・ルールを追加します。
イングレス・ルールに80、443ポート宛てをすべて許可（クライアント→LB）します。
エグレス・ルールにすべての通信を許可（LB→バックエンドセット）します。

ロードバランサー用ルート表の作成

ロードバランサー用ルート表（LB_route）を作成してインターネット・ゲートウェイへのルート・ルールを追加します。

ロードバランサー用サブネット（パブリック）の作成

特に特別な設定はありません。先ほど作成したロードバランサー用セキュリティ・リストとロードバランサー用ルート表を適用します。

ロード・バランサ用サブネット（subnet-lb）が作成されました。

ロード・バランサの作成

ロード・バランサを作成していきます。要所だけコメントを記載しています。

ロード・バランサ用に作成したサブネットを選択します。
帯域幅の最大帯域幅の選択を「50」に変更します。

バックエンド・サーバの選択で事前に作成したWEBサーバ2台を選択します。ポートは「80」を選択します。

セキュリティ・リストの選択設定はデフォルトのままにします。
ロード・バランサとインスタンスの間で必要となる通信をセキュリティ・リストへ自動で追加してくれます。
エグレス・セキュリティ・リストは、ロード・バランサからインスタンスへ出ていく80番ポートの通信を開けてくれます。
イングレス・セキュリティ・リストは、インスタンスへ入ってくる80番ポートの通信を開けてくれます。

リスナー名を任意名で入力し、リスナーを「HTTP」、「80」で構成します。

検証なのでエラーログ、アクセスログは無効化します。

設定内容を確認し、「送信」をクリックします。

5分ほど待って状態が「アクティブ」、全体的なヘルスが「OK」になればロード・バランサとインスタンスは問題なく通信できています。
いつまで待っても「クリティカル」や「保留中」のままですと設定を間違えている可能性があります。

クライアントからhttpでロード・バランサのIPアドレスを指定してWEBページが表示されれば成功です。
サーバ証明書はまだ適用してないので「セキュリティ保護なし」となりますが、「サイトに進む」を押してWEBページが表示されれば現時点では問題ありません。

F5キーなどでブラウザのページを更新するとロード・バランサに負荷分散されてWEBサーバの1号機、2号機が切り替わることが確認できます。

自己署名証明書の作成

ここからが今回の本題です。

OCI のロード・バランサ（LB）に自己署名証明書を適用し、クライアント（ブラウザ）側でもエラーが出ない状態を目指します。

ポイントは2つです
・LBにはPEM形式の「サーバ証明書＋秘密鍵」を設定
・クライアントには「その証明書を信頼するための CA 証明書」をインストール

自己署名証明書でも「クライアントがその発行元（CA）を信頼している」状態にすれば、ブラウザの警告は表示されません。
Common Name は、「www.20251227.com」としました。ブラウザで「https://www.20251227.com」と入力する https://以降の文字列です。

opensslモジュールの確認

opensslモジュールがインストールされていることを確認します。
インストールされてない場合は、インストールしてください。

CA（認証局）の作成

私は、証明書がなかなか理解できず、いつもググるので以下は自分自身への見返すようのメモとなります。

CA = Certificate Authority（認証局）
CA の役割は 3 つだけです。
　1. 証明書を発行する
　2. 「この証明書は本物だ」と保証する
　3. 信頼の連鎖（チェーン）の起点になる

自己署名 CA も、実体はただの証明書＋秘密鍵です。今回では以下のとおりです。
自己署名証明書の CA とは、「公開 CA の代わりに、自分たちで用意する“信頼の根っこ”」と理解しておけば大丈夫です。

CA の秘密鍵　：　my-root-ca.key
CA の公開証明書（クライアントに配布して「信頼」させる）　：　my-root-ca.crt

CA用秘密鍵を作成します。

※opensslコマンドが使用できるなら、どのサーバでも問題ありません。

openssl genrsa -out my-root-ca.key 4096

作成した秘密鍵をもとにCA証明書作成（自己署名）を作成します。
ここで作成した「my-root-ca.crt」をクライアントにインストールします。
検証なのでどの値も適当で問題ありません。Common Name もブラウザへ入力できる一般的な文字列でよいと思います。（記号などは無しで・・・）

openssl req -x509 -new -nodes -key my-root-ca.key -sha256 -days 3650 -out my-root-ca.crt

プロンプトに対して以下を入力していきます。検証ですので任意の情報で問題ありませんが、Common Nameだけは間違いないように入力してください。

[root@websv-20251227 ~]# openssl req -x509 -new -nodes -key my-root-ca.key -sha256 -days 3650 -out my-root-ca.crt
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:JP
State or Province Name (full name) []:Tokyo
Locality Name (eg, city) [Default City]:Shibuya-ku
Organization Name (eg, company) [Default Company Ltd]:IT Corp.
Organizational Unit Name (eg, section) []:IT Corp.
Common Name (eg, your name or your server's hostname) []:www.20251227.com
Email Address []:admin@20251227.com
[root@websv-20251227 ~]#

ロード・バランサ用サーバ証明書の作成

次にロード・バランサ用に秘密鍵とサーバ証明書を作成します。
　１．秘密鍵作成
　２．秘密鍵をもとにCSRを作成
　３．SANを作成
　４．1～3と先に作成したCAの秘密鍵、CA の公開証明書をもとにサーバ証明書を作成

ロード・バランサ用秘密鍵を作成します。

openssl genrsa -out lb-server.key 2048

CSR（証明書署名要求）を作成します。
検証なのでどの値も適当で問題ありません。Common Name もブラウザへ入力できる一般的な文字列でよいと思います。
パスワードは何も入力せずブランクにしましたが、ロード・バランサへ適用する時は問題ありませんでした。

openssl req -new -key lb-server.key -out lb-server.csr

プロンプトに対して以下を入力していきます。先ほどと同じで検証ですので任意の情報で問題ありませんが、Common Nameだけは間違いないように入力してください。

[root@websv-20251227 ~]# openssl req -new -key lb-server.key -out lb-server.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:JP
State or Province Name (full name) []:Tokyo
Locality Name (eg, city) [Default City]:Shibuya-ku
Organization Name (eg, company) [Default Company Ltd]:IT Corp.
Organizational Unit Name (eg, section) []:IT Corp.
Common Name (eg, your name or your server's hostname) []:www.20251227.com
Email Address []:admin@20251227.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:　ブランク　★今回はパスワードなしでも大丈夫でした
An optional company name []:　ブランク
[root@websv-20251227 ~]#

SAN（Subject Alternative Name）の作成

SAN（Subject Alternative Name）を必ず付けるようにとChatgpt が言っていたので作成しました。
SAN とは「この証明書が有効な“接続先の名前一覧”」でもう少しだけ噛み砕くと「HTTPS 接続時、ブラウザは SAN だけを見てアクセスした URL の名前が、この一覧に含まれているか？」を確認し、含まれていなければ証明書エラーになるそうです。（Chatgpt曰く）
Chrome / Edge では SAN が必須だそうです。（Chatgpt曰く）

新規ファイルを作成して以下を入力します。ファイル名は「san.cnf」としました。
[dn]には、ブラウザでhttps://に続くCNを入力します。
[ alt_names ]には、ブラウザでhttps://に続くCNを入力します。他に「https://20251227.com」のように別名も利用したい場合は、「DNS.2 = 20251227.com」のように記載すればよいようです。

[ req ]
default_bits       = 2048
prompt             = no
default_md         = sha256
distinguished_name = dn
req_extensions     = req_ext

[ dn ]
CN = www.20251227.com

[ req_ext ]
subjectAltName = @alt_names

[ alt_names ]
DNS.1 = www.20251227.com

ロード・バランサ用サーバ証明書の作成

CA で署名してロード・バランサ用サーバ証明書を作成します。

openssl x509 -req -in lb-server.csr \
  -CA my-root-ca.crt \
  -CAkey my-root-ca.key \
  -CAcreateserial \
  -out lb-server.crt \
  -days 825 -sha256 \
  -extensions req_ext \
  -extfile san.cnf

WinSCPでローカルパソコンへダウンロード

WinSCPの設定や操作を誤ると鍵ファイルが壊れる可能性があります。私は別の検証でTeratermを使用してクライアント端末からインスタンスへファイルをアップロードする際、おそらくrootユーザーに対してアップロードしたためかファイルが壊れ、インスタンスへログインできなくなりました。WinSCPの操作も自己責任のうえで作業をお願いします。

OCIのロード・バランサ画面でアップロードする必要があるので事前にクライアントへダウンロードしておきます。
私はWinSCPを利用したのでその手順を以下にまとめておきます。
ファイルによっては、権限不足になっているので事前にchmodコマンドで「644」としてアクセス権限（パーミッション）を変更しておいてください。
変更したら /home/opc ディレクトリ配下にコピーしておきます。

WinSCPでOCIのインスタンスへ接続します。Teratermなどで入力する内容と基本的に同じです。
ただ、秘密鍵を選択する方法が異なりましたのでそこだけ注意です。
ホスト名など入力したら「設定」をクリックします。

左ペインの「認証」を選択し、「秘密鍵」の横の3点ボタンをクリックします。

TeratermなどでSSH接続する際に利用する秘密鍵ファイルを選択します。

変換が必要とメッセージが表示されるので「OK」をクリックします。

クライアント側の任意の場所へダウンロードします。

自動でppkファイルへ変換して保存されるので「OK」をクリックします。

秘密鍵へppkファイルが設定されていることを確認し、OKをクリックします。

「ログイン」をクリックします。

OCIのインスタンスへ接続できたのでファイルをダウンロードします。

ロード・バランサへ証明書を適用

ダウンロードした証明書ファイルなどをロード・バランサへ適用します。
作成したロード・バランサ名をクリック、「証明書と暗号」タブを選択し、「証明書の追加」をクリックします。

証明書の追加画面で以下を入力、選択します。
　証明書名：任意の名前を入力します
　SSL証明書の指定：「SSL証明書ファイルの選択」を選択し、ロード・バランサ用サーバ証明書をアップロードします。今回は「lb-server.crt」となります。
　CA証明書の指定：ONにします

CA証明書の指定：「CAファイルの選択」を選択し、CA証明書をアップロードします。今回は「my-root-ca.crt」となります。

秘密キーの指定：ONにします
「秘密キー・ファイルの選択」を選択し、ロード・バランサ用秘密鍵をアップロードします。今回は「lb-server.key」となります。
「証明書の追加」をクリックします。

作業リクエスト送信済画面でステータスが「受入れ済」となり、「成功」になるまで待ちます。

「ロード・バランサ管理対象証明書」に証明書が登録されました。

リスナーの作成

https通信用のリスナーを作成します。

リスナーの作成画面で以下を入力、選択します。

　名前：任意名
　プロトコル：HTTPS
　ポート：443
　証明書リソース：ロード・バランサ管理対象証明書
　証明書名：作成した証明書

バックエンド・セットで既存のバックエンド・セットを選択し、右下の「リスナーの作成」をクリックします。

作業リクエスト送信済画面でステータスが「受入れ済」となり、「成功」になるまで待ちます。

https通信用のリスナーが作成されました。

hosts設定

名前解決するためにクライアントのhostsファイルへロード・バランサのIPアドレスとFQDN名の対応を記載します。hostsファイルは、DNSサーバより優先して名前解決されます。Windowsのhostsファイルは、次の場所に保存されています。「C:\Windows\System32\drivers\etc」