ACMとTLS証明書を理解する

TLS証明書を発行するだけで終わらず、名前・配置先・検証・更新・配備を一連の運用として学びます。

この単元で学ぶこと

TLS証明書と名前の適合を判断する
ACMの検証とリージョン配置を説明する
発行方式ごとの更新と配備責任を区別する

本文解説

1. TLSと証明書 TLSは通信を暗号化し、サーバー証明書は接続先の確認に使われます。クライアントは信頼するCAへ連なる証明書か、期限やホスト名が適切か等を検証します。証明書を持つことは利用者の業務権限を決めることではなく、アプリの認証・認可を別に実装します。

2. 公開とプライベート ACMは証明書の発行・管理・対応サービスへの連携を支援します。一般のブラウザに公開するサイトでは公開CAの信頼が重要です。社内のPrivate CAで発行した証明書を使う場合、端末側へ信頼を構成します。KMSキーのARNを証明書として渡してもCAによる名前の証明にはなりません。

3. 名前の範囲証明書には接続するホスト名を含めます。*.example.comはwww.example.comを対象にできますが、example.com自体とa.b.example.comは含みません。親ドメインも使うならexample.comを別の名前として含める等の設計が必要です。CAが正しくてもホスト名が違えば接続先の確認は成立しません。

4. DNSで管理権限を検証 DNS検証ではACMが指定するCNAMEを管理する公開DNSへ登録します。これはドメインを管理している証拠であり、サイトへの接続先をALBへ向けるDNS設定とは別です。Route 53以外の事業者でも登録できます。名前にドメインが二重に付く等の入力誤りを避けます。

5. 配置するリージョン ACM証明書はリージョンごとに管理します。CloudFrontの閲覧者向け証明書をACMで管理する場合はus-east-1で要求またはインポートします。CloudFrontからオリジンへのTLSは別の区間です。ALB等のオリジン側の証明書は、そのオリジンと連携する構成を確認します。

6. 更新には条件がある ACM発行のDNS検証証明書を対応サービスへ関連付けて使う場合、検証レコードを保持する等の条件を満たして自動更新します。インポートした証明書はACMが自動更新しません。同じ名前の証明書が複数リージョンにあれば各々の更新を管理し、期限・検証状態を監視します。

7. 外部へ持ち出す方式現在のACMにはエクスポート可能な公開証明書があります。証明書・秘密鍵・チェーンをEC2や外部ホストへ配備でき、更新版が用意された後の配備は利用者が管理します。全公開証明書を取り出せないと一律に考えず、種類と設定を確認します。この方式には追加料金もあるため導入時の料金確認が必要です。

8. 運用で確かめる更新された証明書がサーバーへ配置され、実際の接続で新しい証明書が提示されるまで確認します。エクスポートした秘密鍵は公開証明書とは違う秘密情報として保護します。閲覧者側TLS、オリジン側TLS、保存時暗号化の三つを別に検証すると、通信経路の抜けを防げます。

図解

発行から利用継続まで — 発行完了と、更新後も接続先で正しい証明書を提示できることは別の確認です。

重要ポイント

証明書の名前・信頼・期限を確認する。
CloudFrontの閲覧者向けACM証明書はus-east-1。
ACM側の更新と外部への配備は別。

間違えやすい点

ワイルドカードが親ドメインや全階層を覆うと思う。
インポート証明書も自動更新されると思う。

用語解説

CA: 証明書へ署名する認証局。
SAN: 証明書で対象とするDNS名等を指定する拡張。
証明書チェーン: サーバー証明書から信頼する認証局へ至る関係。

参考資料

教材データに登録された参考リンクです。リンク先の内容や更新日は提供元でご確認ください。

確認問題の出題・採点や学習履歴の保存にはログインが必要です。