近年、Webサイト運営者が気をつけなければならないセキュリティの1つに「サーバー証明書の不正発行対策」があります。
この記事では、その対策の1つである CAAリソースレコード（Certification Authority Authorization） の役割と、証明書発行後にユーザーがアクセスする際のHTTPS通信の流れまでを丁寧に解説します。
🔰 CAAレコードとは？ – ドメイン所有者が使う「証明書発行の許可証」
✅ 目的：どの認証局（CA）に証明書を発行させるかをドメイン側で制限できる
CAA（Certification Authority Authorization）レコードは、DNSのリソースレコードの1つで、ドメインの所有者が「この認証局（CA）にだけ証明書の発行を許可します」と明示できる仕組みです。
example.com. IN CAA 0 issue "letsencrypt.org"上記の設定では、「Let’s Encrypt 以外の認証局がこのドメインに証明書を発行することは禁止」となります。
🛠 CAAレコードの動作フロー（証明書発行時）
- ドメイン所有者が DNS に CAAレコードを設定。
- 認証局（CA）が証明書の申請を受け取る。
- CAが DNS を検索し、CAAレコードを確認。
・許可されていない場合 → 証明書発行を中止。 - CAAレコードに自分（CA）が許可されていれば、、CAはドメイン所有者確認（ドメイン認証など）をドメイン所有者に行う。
・HTTP-01, DNS-01, Email認証などの方法で、ドメインの管理権限が本当にあるかを確認。 - ドメイン所有者が確認を行えば、認証局はサーバー証明書を発行する。
✅ この段階で CAAレコードがチェックされるのは「証明書発行時のみ」です。
🔐 DNSSECによる保証とは？
DNSの応答を改ざんされないようにするために、DNSSEC（DNS Security Extensions）を有効にすることが推奨されています。
DNSSECを使うことで、CAが受け取ったCAAレコードが本当にドメイン登録者が設定したものであることを検証可能になります。これにより、攻撃者がDNSレスポンスを偽造してCAを騙すリスクを軽減できます。
🌐ユーザーがWebサイトへアクセスする際の流れ（HTTPS通信）
証明書が発行されたあと、実際にユーザーが https://example.co.jp へアクセスした場合、次のような流れになります。
🔁 1. ブラウザがサーバーへ接続（TCP＋TLSハンドシェイク）
- DNSで
example.co.jpのIPアドレスを取得。 - サーバーにアクセスすると、TLS通信が始まり、サーバー証明書が送信される。
🔐 2. ブラウザが証明書の真正性を確認
この時、サーバーから送られてくる証明書には、次のような重要情報が含まれています。
🧾 サーバー証明書の主な内容：
| 項目 | 説明 |
|---|---|
| 公開鍵 | 暗号化通信に使用される公開鍵 |
| 発行者（Issuer） | 証明書を発行したCA（Let’s Encrypt） |
| 有効期限 | 証明書の有効期限（開始日～終了日） |
| CN（Common Name） | ドメインの「正規の名前」。旧来はここに example.co.jpが記載されていた |
| SAN（Subject Alternative Name） | CNと同等または複数の対象ドメイン名（example.co.jp、elb.example.co.jp など）を明示 |
🔎 現在では、CNよりもSANの使用が主流となっており、ブラウザはSANに記載されたドメイン名を確認します。
🧪 ブラウザ側の検証内容：
| チェック内容 | 説明 |
|---|---|
| 有効期限 | 証明書が期限内かどうか |
| ドメイン名一致 | アクセス先とSAN/CNに記載されたドメインが一致しているか |
| 発行元の信頼性 | CAが信頼されたルート証明書チェーンの一部かどうか |
| 改ざんチェック | 署名（CAによる）を検証して整合性を確認 |
✅ 3. 共通鍵の交換 → HTTPS通信開始
- 証明書の公開鍵などを使って、共通鍵を安全に交換
- 以降はこの鍵を使って暗号化されたデータ通信（HTTPS）が行われます。
🔎 認証局（CA）はアクセス時に関与するのか？
原則として、CAは証明書発行時にしか関与しません。
- Webブラウザは、信頼できるCAの証明書をあらかじめ内部に持っています。
- それを使って、発行された証明書の妥当性をローカルで検証します。
※ただし、証明書が「失効」していないかを確認するために、**OCSP（Online Certificate Status Protocol）やCRL（証明書失効リスト）**によって CA に問い合わせることはあります。
🎯 まとめ：CAAとHTTPSの関係
| 項目 | 内容 |
|---|---|
| CAAレコードの目的 | 証明書の発行を特定の認証局（CA）に制限する |
| 発行時の関与 | 認証局はCAAレコードを確認してから証明書を発行 |
| アクセス時の関与 | 原則、CAは関与しない（証明書のローカル検証） |
| DNSSECの役割 | DNS応答の改ざんを防ぎ、CAAレコードの正当性をCAが検証可能にする |
| HTTPS通信との関係 | 発行された証明書をもとに、サーバーが暗号化通信を開始できる |
| 証明書の構成要素 | 公開鍵、SAN、CN、発行元、署名、有効期限など |
📝 おまけ：CAAレコードのおすすめ設定例
複数のCAを許可することもできます。
example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 issue "digicert.com"また、ワイルドカード証明書（*.example.com）専用の設定もあります：
example.com. IN CAA 0 issuewild "letsencrypt.org"DNSのCAAレコードは、見落とされがちですが非常に重要なセキュリティ対策です。
特に、企業や公共機関などで証明書の誤発行を防ぎたい場合は、積極的に導入するべきです。
HTTPS通信は「証明書を発行して終わり」ではなく、「どう発行され、どう検証されるか」を理解することでより安全なWeb運用につながります。
参考記事：DNS を用いたサーバー証明書の発行制御
コメント