内容
プライベート接続環境のELBに証明書を設定する場合、証明書の発行方法には様々な方法があります。前回は下記記事にて、AD CSを使用してプライベート証明機関構築後、プライベート証明書を発行する手順を記載しました。
Active Directory証明書サーバで証明書を発行してALBに設定する
今回はACM(AWS Certificate Manager)でプライベートCA作成後、プライベート証明書を発行し、NLBに設定する方法を記載します。
構成
中央側のアカウントでプライベートCAを作成し、AWS RAM(Resource Access Manager)を使用して、作成したプライベートCAを別アカウントに共有します。共有先のアカウントでプライベート証明書を発行後、NLBにTLSリスナーを追加して、ACMで発行した証明書を指定します。設定完了後、クライアント想定のEC2からNLBに接続確認を行います。
前提条件
- VPC内のリソース(NLB、EC2)は構築済みの状態とします
全体の流れ
- ACMでプライベートCAを作成
- ルートCA証明書を作成
- RAMでプライベートCAを共有
- RAMの共有を承認
- プライベート証明書の作成
- NLBに証明書の設定
- 接続確認①(警告表示の確認)
- ルート証明書のインポート
- 接続確認②(正常接続の確認)
ACMでプライベートCAを作成
ACMのコンソールからプライベートCAを作成をクリックします。
サブジェクトの識別子のオプションに組織(O)や共通名(CN)などを入力します。その他の選択肢はデフォルトで進んでいきます。
プライベート認証機関が作成されて保留中のステータスとなります。
ルートCA証明書を作成
作成されたプライベート認証機関を選択後、CA証明書をインストールをクリックします。
デフォルトのまま、確認してインストールをクリックします。
ルートCA証明書がインストールされ、プライベート認証機関のステータスがアクティブに変更されます。
RAMでプライベートCAを共有
アクションからリソース共有を管理を選択するとRAMコンソールに移動することができます。
RAMコンソールからリソース共有を作成をクリックします。
リソース共有名を入力後、リソースタイプでプライベートCAを選択後、先ほど作成したプライベートCAを選択します。
アクセス権はデフォルトのまま進みます。
プリンシパルからAWSアカウントを選択後、共有先のAWSアカウントIDを入力します。
リソースが共有されたことを確認します。
RAMの共有を承認
共有先のアカウントにログイン後、RAMコンソールに移動します。自分と共有 → リソース共有から共有されたリソースを選択します。
リソース共有を承認を選択します。
ACMのコンソールに移動後、プライベート認証機関が共有されていることを確認します。
プライベート証明書の作成
ACMのコンソールから証明書に移動後、リクエストをクリックします。
プライベート証明書をリクエストを選択します。
証明機関で先ほど承認したプライベート承認期間を選択します。
証明書に使用するドメイン名などを入力します。その他はデフォルトのまま進んでいきます。
プライベート証明書が発行されたことを確認します。
NLBに証明書の設定
NLBにリスナーを追加します。プロトコルにTLSを選択します。
TLSリスナーの場合、証明書を選択する必要がありますが、ここでACMからを選択後、先ほど発行したプライベート証明書を選択します。
リスナー作成完了後、下記動作確認のため、NLBのDNS名test-nlb-xxx.elb.ap-northeast-1.amazonaws.comをメモしておきます。
接続確認①(警告表示の確認)
クライアント想定EC2にログイン後、ブラウザからhttps://test-nlb-xxx.elb.ap-northeast-1.amazonaws.comを入力後、下記警告画面が表示されることを確認します。
警告画面を進んでいき、下記IISの画面が表示されることを確認します。
続いて証明書確認のため、証明書発行ドメイン（今回はhttps://test.xxx.localと想定）でアクセス出来る設定を行います。今回は一時的なテストのため、ローカルのhostsファイルに記述を行います。
NLBのDNS名にpingを実行してNLBのIPアドレスを確認します。
ping test-nlb-xxx.elb.ap-northeast-1.amazonaws.com
test-nlb-xxx.elb.ap-northeast-1.amazonaws.com [10.xx.xx.xx]に ping を送信しています 32 バイトのデータ:
要求がタイムアウトしました。
HOSTSファイルを開いて下記記述を追加します。test.xxx.localにアクセスすると10.xx.xx.xxにアクセスしたことになります。
10.xx.xx.xx test.xxx.local
HOSTSファイル記述後、ブラウザからhttps://test.xxx.localにアクセスします。この時点では警告が表示されることを確認します。
ルート証明書のインポート
クライアントから接続時、警告が表示されないように、ルートCAの証明書をクライアント側にインポートします。
ACMのコンソールからCA証明書の取得を行います。
CA証明書が表示されるため、エクスポートを行います。
クライアント端末に移動後、ファイル名を指定して実行からcertlm.mscを入力し、証明書を起動します。下記画面のようにインポートを選択します。
次へをクリックします。
先ほどエクスポートしたファイルを指定します。
デフォルトのまま次へをクリックします。
完了をクリックします。
接続確認②(正常接続の確認)
再度ブラウザからhttps://test.xxx.localにアクセスします。今度は警告が表示されないことを確認します。
まとめ
AD CSでプライベート証明機関を作成する場合と比較して、管理は容易になると思います。ACMでプライベート証明機関を作成する場合のコストは少し高めですが、サーバ管理費や運用コストなどを比較すると、結果的にマネージドサービスを使用した方が効率的かもしれません。