AWS Certificate Manager(ACM)で、完全修飾ドメインとアルゴリズム(RSA 2048等)を指定すると証明書が発行されますが、どういう仕組みなのかすぐに忘れるためメモ書きすることにしました。
ACMとは
ACMとはAWS Certificate Managerの略で、AWSのサービスの1つです
SSL/TLS証明書発行サービスで、簡単にSSL/TLS証明書の発行と更新が行えます。
ACMが発行したSSL/TLS証明書は、ユーザーのプライベートネットワークリソースや、AWSの様々なサービスに導入出来ます。参考
マネージメントコンソールでは次のように設定を行います。
SSL/TLS証明書とは
SSL/TLS証明書とは、ウェブサイトの「実在性の確認」し、ブラウザとウェブサーバ間で「通信データの暗号化」を行うための電子証明書です。参考
https通信を行うサーバーが所有しています。
SSL/TLS証明書は、認証局という場所で発行されます。
証明書の種類
証明書には、三つの種類があり、「ドメイン認証」「企業実在認証」「EV認証」が存在します。
それぞれに信頼性という概念があり、高い順で並べると「EV認証」「企業実在認証」「ドメイン認証」となります。
暗号化強度については全て同等です。
ACMでは「ドメイン認証」が利用されています。
ドメイン検証 (DV): ACM 証明書は、ドメイン検証されます。つまり、ACM 証明書のサブジェクトフィールドはドメイン名のみを識別します。ACM 証明書をリクエストした場合、リクエストで指定したすべてのドメインの所有者または管理者であることを検証する必要があります。E メールまたは DNS を使用して所有権を検証できます
引用: マニュアル
ドメイン認証 証明書とは
ドメイン認証(DV)証明書とは、SSL/TLSで用いられるデジタル証明書のうち、最も簡易な確認手順で発行されるものです。単にSSLサーバ証明書といった場合は通常これを指します。引用
ドメイン認証(DV)証明書を発行する際には、メール認証やDNS認証により、ドメインの使用権のみが確認されます。組織の実在性は確認されません(※)。個人でも発行でき低価格で、申請後すぐに発行可能です。引用
※ 組織の実在性を証明したい場合は、「ドメイン認証」ではなく「企業実在認証」や「EV認証」に対応する証明書の発行が必要です。
SSL/TLSを利用した通信の流れ
SSL/TLS証明書を利用した通信の概要は次のようになります。
この流れがうまくいくと、SSL/TLS証明書の機能であるウェブサイトの「実在性の確認」と「通信データの暗号化」が実現されます。
1. ブラウザがSSL/TLS通信をリクエストする
2. サーバーがSSL/TLS証明書を送付する
3. ブラウザが電子署名の検証により「SSL/TLS証明書に記載されたドメイン」と「通信先のドメイン」が同じであることを確認する
4. ブラウザ/サーバーがSSL通信を行うために共通鍵を交換する
5. ブラウザ/サーバーが共通鍵を使って送受信するデータを暗号化・復号してSSL通信を成立させる
参考サイト:https://ssl.sakura.ad.jp/column/ssl/
電子署名の検証
上記の通信の流れの3で、「ブラウザが電子署名を検証する」という過程があります。
ここでは、インターネット上にある「認証局」を利用して、サーバーから送られてきた証明書が「認証局」によって発行された証明書であるかを検証しています。
ACMで作成するSSL/TLS証明書もまた、「認証局」で発行されています。
認証局はサーバーでもパソコンでもない第三者機関であり、「○○.jpドメインを保有している人にSSL証明書を発行しました」と保証してくれる組織です。
パソコンやスマートフォンなどの端末内には認証局が発行する「ルート証明書」が保存されています※。
※ ルート証明書はOS(WindowsやMac等)のプログラムによって自動更新されます。参考
ルート証明書はパソコン本体に保存されていることで、インターネット上の「悪意のある第三者」の改ざんを困難にするため、このような仕組みとなっています。
3では、サーバーから送られてくる証明書（SSL/TLS証明書）が、ルート証明書に関連付けられた証明書（認証局が発行した証明書）であるかを検証しています。
参考サイト:https://ssl.sakura.ad.jp/column/ssl/
電子署名の検証をもっと詳しく
では、具体的にどうやってSSL/TLS証明書が正当なものかを検証しているのでしょうか。
ここでいう検証とは、SSL/TLS証明書に記載された認証局事業者の署名 を確認しています。
認証局事業者の署名とは、SSL/TLS証明書の内容をハッシュ化した値を認証局の署名として秘密鍵で暗号化したデータです。
クライアント(パソコン等)は、SSL/TLS証明書を受け取ると、クライアントに登録されている認証局のルート証明書(公開鍵)を用いて、この認証局の署名を復号します。
「秘密鍵で暗号化して、公開鍵復号？逆じゃない？」と思われる方もいるかもしれませんが、「電子著名」という文脈では「秘密鍵で暗号化」は正しいです。
秘密鍵で作成された署名は、秘密鍵と対になった公開鍵のみで復元することが可能となっています。公開鍵用いて署名から元の情報（電子文書）へ変換することを「検証（Verify）」と呼びます。 参考
つまり、SSL/TLS証明書の認証局の署名を復号した結果がSSL/TLS証明書のハッシュ値と一致すれば、第三者によって改ざんされたものでない、正しく認証局事業者が発行した SSL/TLS証明書であることが確認できます。
補足ですが、SSL/TLS証明書の内容はCSR(Certificate Signing Request)と認証局の署名の部分とで分かれています。上記で検証を行っているのはCSR部分のハッシュ値となります。参考
これなら電子署名の正当性検証は「認証局の署名に利用した秘密鍵は、認証局しか知らない」という前提であれば成り立ちますね。
参考サイト:
https://www.digicert.co.jp/welcome/pdf/wp_sslandroot-certificate.pdf 5ページ
https://www.jipdec.or.jp/project/research/why-e-signature/public-key-infrastructure.html
