😻
SSL証明書のあれこれ
SSL証明書のあれこれ
業務でSSL証明書の発行及びSSL証明書を使用したHTTPS通信のための申請・設定をいろいろ行ったため備忘を目的として以下にまとめます。
SSL証明書って何？
AWSの記事から抜粋
SSL/TLS 証明書は、システムがアイデンティティを検証し、その後、Secure Sockets Layer/Transport Layer Security (SSL/TLS) プロトコルを使用して別のシステムへの暗号化されたネットワーク接続を確立できるようにするデジタルオブジェクトです。証明書は、公開鍵基盤 (PKI) と呼ばれる暗号化システム内で使用されます。PKI では、双方が認証機関と呼ばれるサードパーティを信頼している場合に、証明書を使用して一方から他方のアイデンティティを確立する方法となります。したがって、SSL/TLS 証明書は、ネットワーク通信を保護し、インターネットを介したウェブサイトと、プライベートネットワーク上のリソースのアイデンティティを確立するためのデジタルアイデンティティカードとして機能します。
簡単にまとめると、インターネット上の通信を暗号化して安全に通信するために使用するもの
SSL証明書を利用した通信の流れ
- クライアントがサーバに接続要求（Client Hello）
- クライアントがTLSのバージョン、対応暗号スイート、ランダム値（Client Random）などを送信し、通信を開始する。
- サーバが応答（Server Hello）
- サーバが使用するTLSバージョンと暗号スイートを選択し、ランダム値（Server Random）とSSL証明書（公開鍵付き）を送信する。
- 証明書の検証（クライアント側）
- クライアントがサーバ証明書の正当性を検証する（認証局の署名、有効期限、ホスト名の一致など）。
- プレマスタシークレットの生成と送信（鍵交換）
- クライアントがプレマスタシークレットを生成し、サーバの公開鍵で暗号化して送信する（またはDHなどで共有）。
- 共通鍵（セッション鍵）の生成
- クライアントとサーバが、Client Random・Server Random・プレマスタシークレットを元に、共通のセッション鍵を生成する。
- 暗号化通信の開始（Finishedメッセージ）
双方が共通鍵で暗号化したFinishedメッセージを送信し、通信の整合性を確認。以降、すべての通信は暗号化される。
共通鍵生成方式は2種類ある
| 項目 | RSA方式（TLS 1.2以前） | ECDHE方式（TLS 1.2以降 / TLS 1.3推奨） |
|---|---|---|
| 🔑 鍵交換の仕組み | クライアントがプレマスタシークレットを生成し、 サーバの公開鍵で暗号化して送信 |
クライアントとサーバが一時的な鍵ペア（DH/ECDH）を使って、共通鍵を協調的に生成 |
| 🔐 セッション鍵の共有方法 | サーバが秘密鍵で復号し、プレマスタから共通鍵を計算 | 双方がDiffie-Hellmanによる鍵共有アルゴリズムで共通鍵を導出 |
| 🕒 鍵の有効期間 | サーバ証明書の公開鍵をずっと使う（固定） | 通信ごとに**新しい鍵ペア（エフェメラル）**を生成（一時的） |
| 🔄 前方秘匿性（PFS） | ❌ なし：秘密鍵が漏れたら過去の通信も復号可能 | ✅ あり：過去通信の鍵は1回限り。漏れても影響なし |
| 🔐 サーバ証明書の鍵用途 | 暗号化（鍵交換）用途として使う | 署名用途のみ（鍵交換には使わない） |
| 🚀 パフォーマンス | 比較的軽い（処理負荷が少なめ） | 若干重い（ただしECDHEは高速） |
| 📜 TLSバージョン | TLS 1.0 / 1.1 / 1.2 で利用可（現在は非推奨） | TLS 1.2 / TLS 1.3（必須） |
| 🛡️ セキュリティ評価 | 古く、セキュリティ的に劣る | より強固、安全設計 |
補足解説
- RSA方式はシンプルで高速ですが、サーバの秘密鍵が漏れた場合に過去の通信内容も復号されるリスクがあります。
- ECDHE（Ephemeral Elliptic Curve Diffie-Hellman）方式は安全性が高く、TLS 1.3では必須となっています。
- 「Ephemeral」は一時的という意味で、通信のたびに使い捨ての鍵を生成します。
今回のアクセス経路
使用したドメイン（例として）：deltag.domain
[ユーザー端末]→[AWSアカウントAのNLB]→[AWSアカウントAのEC2]→[AWSアカウントBのALB]→[AWSアカウントBのEC2]
実施したこと
- csrファイルの作成
- これがないと証明書が作れません。組織情報とかが暗号化されて記録されます。csrの内容確認サイトとかに貼り付けると確認できるらしい。
- passkey,nopasskeyファイルの作成
- 当時はもらった手順書に書いてある通りにパスフレーズありなしのpasskeyファイルを作成したけど、ACMで証明書管理する時パスフレーズありのファイル要らないしなんで作ったんだろう？って後になって思いました。
- サブドメイン使用に必要な社内申請
- 必要な作業が終わるとサブドメインがwhoisでひけるようになりました（入口のNLBには到達する状態）
- 発行した証明書はNLBで所持（入口だからそりゃそうか）
- アカウントAのNLB、EC2にdeltag.domainの通信許可設定を入れる
- アカウントAのEC2はWAF的な役割をしていました。許可したドメイン以外は通さない仕組みにしていたので、今回使用するサブドメインも許可してあげる必要がありました。
- ただ、アカウントAは管理外であったため、実際どのような設定を入れていたかは分かりません。おそらくFQDNがdeltag.domainならアカウントBのALBへ振るような設定を入れていたと思います。
今回知ったこと
- SSL証明書の作り方も知らなかったし、csrファイルが証明書ファイルだと思ってたくらい知識がなかったので一から調べ直しました。
SSL関連ファイルの比較表
| 拡張子 | 形式 | ヘッダー例 | 中身 | 説明 |
|---|---|---|---|---|
.crt |
PEMまたはDER | -----BEGIN CERTIFICATE----- |
公開鍵証明書（X.509） | サーバやクライアントの公開証明書。中間CAやルートCAとともに使う。 |
.cer |
PEMまたはDER |
-----BEGIN CERTIFICATE----- またはなし |
公開鍵証明書（X.509） |
.crtと実質同じ。Windowsでは.cerが主流。 |
.pem |
PEM |
-----BEGIN CERTIFICATE----- など |
証明書・秘密鍵など | Base64形式で、複数の要素を含められる汎用ファイル。 |
.der |
DER（バイナリ） | （ヘッダーなし） | バイナリ証明書 | PEMのバイナリ版。Windowsでよく使われる。 |
.key |
PEMまたはDER | -----BEGIN (RSA )?PRIVATE KEY----- |
秘密鍵 | 証明書と対応する秘密鍵。厳重管理が必要。 |
.nokey |
（慣習的） |
-----BEGIN CERTIFICATE----- など |
秘密鍵を含まない証明書 | 管理のための命名。秘密鍵を除いた証明書ファイル。 |
.csr |
PEM | -----BEGIN CERTIFICATE REQUEST----- |
証明書署名要求（CSR） | 証明書の発行を依頼するためのファイル。公開鍵＋組織情報を含む。 |
私の環境の場合、暗号化された秘密鍵のフッターは-----BEGIN ENCRYPTED PRIVATE KEY-----でした。
- 「クライアントがサーバ証明書の正当性を検証する」について
- 初めはルート証明書をどうやって入手するんだよ！って思ってました。（絶対同じ人いますよね？）調べるとDigicertなどデファクトなルート証明書は基本的にプリインストール済みだそうです。
参考にした記事
寄り道〜公開鍵暗号方式と共通鍵暗号方式〜
- オフィシャルになっている公開鍵で暗号化し、自分もしくは相手しか知らない秘密鍵で復号を行うのが「公開鍵暗号方式」
- 当事者間しか知らない共通鍵を利用して暗号化・復号を行うのが「共通鍵暗号方式」
Discussion