背景・目的

AWS Certificate Manager（ACM）について、触れる機会がありましたので、知識を整理してみます。

まとめ

下記に特徴を整理します。

特徴	説明
ACMとは	Webサイト、アプリケーションを保護するパブリック/プライベート SSL/TLS X.509証明書、キーの作成、保存、更新など複雑な処理する
使用方法	直接発行するか、サードパーティーの証明書をACMにインポートする
X.509証明書のデプロイ	下記の2つのオプションがある・ACM ・AWS Private CA
ACMの特徴	・TLSを安全なWebプレゼンスを必要とする企業向け・AWS、その他の統合サービスを通じてデプロイされる・重要なトラフィック要件を持つセキュアなパブリックウェブサイト・有効期限が切れる証明書をの更新を自動化する
AWS Private CAの特徴	・AWSクラウド内でPKI（パブリックキーインフラストラクチャー）を構築している企業向け・組織内でのプライベート使用を目的としている・Private CA、独自の認証局の改装を作成できる・Private CAでは、インターネットで使用することはできない
ACMと統合されているサービス	・Elastic Load Balancing ・Amazon CloudFront ・Amazon Cognito ・AWS Elastic Beanstalk ・AWS App Runner ・Amazon API Gateway ・AWS Nitro Enclaves ・AWS CloudFormation ・AWS Amplify ・Amazon OpenSearch Service ・AWS Network Firewall

概要

What Is AWS Certificate Manager?を下に整理します。

AWS Certificate Manager (ACM) は、Web サイトやアプリケーションを保護するパブリック/プライベート SSL/TLS X.509 証明書とキーの作成、保存、更新といった複雑な作業を処理します。 AWS 統合 AWS サービスの証明書は、ACM で直接発行するか、サードパーティーの証明書を ACM 管理システムにインポートすることで提供できます。ACM 証明書は、単一のドメイン名、複数の特定のドメイン名、ワイルドカードドメイン、またはこれらの組み合わせを保護できます。ACM ワイルドカード証明書は、無制限の数のサブドメインを保護できます。署名済みの ACM 証明書をエクスポートして、内部 PKI の任意の場所で使用することもできます。 AWS Private CA

Webサイト、アプリケーションを保護するパブリック/プライベート SSL/TLS X.509証明書、キーの作成、保存、更新など複雑な処理する
ACMと統合されているAWSサービスの証明書について、直接発行するか、サードパーティーの証明書をACMにインポートできる
ACM証明書は、下記を保護できる
- 単一ドメイン名
- 複数の特定のドメイン名
- ワイルドカードドメイン
- 上記の組み合わせ

Is ACM the right service for me?

AWS マネージド X.509 証明書をデプロイするお客様には 2 つのオプションが用意されています。ニーズに最適なオプションを選択してください。

AWS Certificate Manager (ACM) — このサービスは TLS を使用した安全な Web プレゼンスを必要とする企業顧客向けです。ACM 証明書は、Elastic Load Balancing、Amazon CloudFront、Amazon API Gateway、AWS およびその他の統合サービスを通じてデプロイされます。この種の代表的なアプリケーションは、重要なトラフィック要件を持つセキュアなパブリックウェブサイトです。ACM は、有効期限が切れる証明書の更新を自動化することで、セキュリティ管理を簡素化します。お客様は、このサービスの対象となります。

AWS Private CA—このサービスは、 AWS クラウド内にパブリックキーインフラストラクチャ (PKI) を構築している企業顧客向けで、組織内でのプライベート使用を目的としています。を使用すると AWS Private CA、独自の認証局 (CA) 階層を作成し、ユーザー、コンピュータ、アプリケーション、サービス、サーバー、その他のデバイスを認証するための証明書を発行できます。プライベート CA によって発行された証明書をインターネットで使用することはできません。詳細については、『AWS Private CA ユーザーガイド』を参照してください。

X.509証明書をデプロイするには、2つのオプションがある
- ACM
- AWS Private CA
  - AWSクラウド内でPKI（パブリックキーインフラストラクチャー）を構築している企業向け
  - 組織内でのプライベート使用を目的としている
  - Private CA、独自の認証局の改装を作成できる
  - Private CAでは、インターネットで使用することはできない

ACM certificate characteristics

ACM が提供するパブリック証明書には、このページで説明する特徴があります。

認証機関と階層
　ACM を通じてリクエストしたパブリック証明書は、Amazon が管理するパブリック認証機関 (CA) である Amazon Trust Services から取得されます。Amazon ルート CA 1 ～ 4 は、Starfield G2 Root Certificate Authority - G2 という名前の古いルートによってクロス署名されています。Starfield ルートは、それ以降のバージョンの Gingerbread 以降の Androidデバイス、およびバージョン4.1 以降の iOS で信頼されています。Amazon ルートは、バージョン 11 以降の iOS によって信頼されています。Amazon または Starfield ルートを含むブラウザ、アプリケーション、OS は、ACM から取得したパブリック証明書を信頼します。
　ACM がお客様に発行するリーフ証明書またはエンドエンティティ証明書は、複数の中間 CA を介して Amazon Trust Services のルート CA からの認証を受けます。ACM は、要求された証明書のタイプ (RSA または ECDSA) に基づいて中間 CA をランダムに割り当てます。中間 CA はリクエストの生成後にランダムに選択されるため、ACM は中間 CA 情報を提供しません。

ACMを通じてリクエストしたパブリック証明書は、Amazonが管理するパブリック認証機関のAmazon Trust Servicesから取得される
Amazon ルート CA 1 ～ 4
- Starfield G2 Root Certificate Authority - G2 という名前の古いルートによってクロス署名されている
Starfield ルート
- それ以降のバージョンの Gingerbread 以降の Androidデバイス、およびバージョン4.1 以降の iOS で信頼されている
Amazon ルート
- バージョン 11 以降の iOS によって信頼されている
ACMが発行するリーフ証明書またはエンドエンティティ証明書
- 複数の中間CAを介して Amazon Trust ServicesのルートCAから認証を受ける
ACMでは、要求された証明書のタイプ（RSAまたは、ECDSA）に基づいて中間CAをランダムに割り当てる
中間CAでは、リクエストの生成後にランダムに選択されるため、ACMは中間CA情報を提供しない

ブラウザとアプリケーションの信頼
ACM 証明書は、Google Chrome、Microsoft Internet Explorer と Microsoft Edge、そして Mozilla Firefox および Apple Safari を含むすべての主要なブラウザから信頼されています。ACM 証明書を信頼するブラウザでは、ACM 証明書を使用するサイトに SSL/TLS から接続するときにステータスバーにロックアイコンが表示されます。ACM 証明書は Java でも信頼されています。

ACM証明書は、下記に代表される主要なブラウザから信頼されている
- Google Chrome
- Microsoft Internet Explorer
- Microsoft Edge
- Mozilla Firefox
- Apple Safari
ACM証明書を信頼するブラウザでは、ACM証明書を使用するサイトに、SSL/TLSから接続するときにステータスバーにロックアイコンが表示される

中間 CA とルート CA のローテーション
回復力と俊敏性を備えた証明書インフラストラクチャを維持するために、Amazon は事前の通知なしに中間認証機関を廃止することがあります。この種の変更は、お客様には影響しません。詳細については、ブログ記事「Amazon introduces dynamic intermediate certificate authorities」(Amazon が動的中間認証機関を導入) を参照してください。
Amazon がルート CA を廃止した場合、状況に応じて速やかに変更が行われます。このような変更による影響は大きいため、Amazonは、アカウント所有者への電子メール、テクニカルアカウントマネージャーへの働きかけなど、 AWS 利用可能なあらゆるメカニズムを使用してお客様に通知します。 AWS Health Dashboard

Amazonでは事前の通知なしに中間認証機関を廃止することがある。これにより利用者は影響しない
AmazonがルートCAを廃止した場合に、変更による影響が大きいため、利用者へ通知する

失効時のファイアウォールアクセス
エンドエンティティ証明書が信頼されなくなると、その証明書は失効します。OCSP と CRL は、証明書が取り消されたかどうかを検証するために使用される標準的なメカニズムです。OCSP と CRL は、失効情報の公開に使用される標準的なメカニズムです。お客様のファイアウォールによっては、これらのメカニズムを機能させるために追加のルールが必要になる場合があります。
次の例の URL ワイルドカードパターンを使用して、失効トラフィックを識別できます。アスタリスク (*) ワイルドカードは 1 つ以上の英数字、疑問符 (?) は単一の英数字を表し、ハッシュマーク (#) は数字を表します。

OCSP
http://ocsp.?????.amazontrust.com
http://ocsp.*.amazontrust.com

CRL
http://crl.?????.amazontrust.com/?????.crl
http://crl.*.amazontrust.com/*.crl

エンティティ証明書が信頼されなくなると、証明書は失効する
OCSPとCRLは証明書が取り消されたか検証するために、使用される標準的なメカニズム

ドメイン検証 (DV)
ACM 証明書は、ドメイン検証されます。つまり、ACM 証明書のサブジェクトフィールドはドメイン名のみを識別します。ACM 証明書をリクエストした場合、リクエストで指定したすべてのドメインの所有者または管理者であることを検証する必要があります。E メールまたは DNS を使用して所有権を検証できます。詳細については、E メール検証およびDNS での検証を参照してください。

ACM証明書はドメイン検証される

有効期間
ACM 証明書の有効期間は、現在 13 か月 (395 日) です。

有効期間は、13ヶ月

マネージド更新とデプロイ
ACM は、ACM の更新プロセスと、更新後の証明書のプロビジョニングを管理します。自動更新は、証明書の設定ミス、失効、期限切れによるダウンタイムを防止するために役立ちます。詳細については、「ACM 証明書のマネージド更新」を参照してください。

ACMの更新プロセスと更新後の証明書のプロビジョニングを管理する

複数のドメイン名
各 ACM 証明書には、少なくとも 1 つの完全修飾ドメイン名 (FQDN) が含まれる必要があり、希望する場合には追加の名前を付けくわえることができます。たとえば、www.example.com に ACM 証明書を作成する場合、www.example.net という名前を追加すると、カスタマーはどちらの名前を使用してもサイトにアクセスできます。これは、zone apex またはネイキッドドメインとも呼ばれるホスト名のないドメインにも有効です。つまり、www.example.com に ACM 証明書をリクエストし、example.com という名前を追加できます。詳しくは、パブリック証明書をリクエストするを参照してください。

ACM証明書には、少なくても一つのFQDNが含まれる

ワイルドカード名
ACM は、ドメイン名にアスタリスク () を使うことで、同じドメイン内の複数のサイトを保護できるワイルドカード名を含む ACM 証明書を作成することができます。たとえば、.example.com は、www.example.com と images.example.com を保護します。

ドメイン名にアクスタリスクを使い、同じドメイン内の複数のサイトを保護するワイルドカード名を含むACM証明書を作成できる

キーアルゴリズム
証明書では、アルゴリズムやキーサイズを指定する必要があります。現在、ACM がサポートしているパブリックキーアルゴリズムは、以下の RSA および楕円曲線デジタル署名アルゴリズム (ECDSA) です。ACM は、アスタリスク (*) でマークされたアルゴリズムを使用して新しい証明書の発行をリクエストできます。残りのアルゴリズムは、インポートされた証明書でのみサポートされます。
ECDSA キーはサイズが小さく、RSA キーに匹敵するセキュリティを提供しますが、コンピューティング効率も高くなります。ただし、ECDSA はすべてのネットワーククライアントでサポートされているわけではありません。次の表は、NIST から引用したもので、さまざまなサイズのキーを使用した RSA と ECDSA の代表的なセキュリティ強度を示しています。値はすべてビット単位です。

証明書では、アルゴリズムやキーサイズを指定する
現在、ACMでサポートしているパブリックキーアルゴリズムは、ECDSA
ECDSAキー
- サイズが小さく、RSAキーに匹敵するセキュリティを提供する
- コンピューティング効率も高くなる

Punycode
国際化ドメイン名に関連する次の Punycode 要件を満たす必要があります:

パターン「—」で始まるドメイン名は「xn—」と一致する必要があります。

「xn—」で始まるドメイン名も有効な国際化ドメイン名である必要があります。

国際化ドメイン名に関連するPunycode 要件を満たす必要がある

例外
次の点に注意してください。

ACM は、拡張検証 (EV) 証明書または組織検証 (OV) 証明書を提供していません。

ACM は、SSL/TLS プロトコル以外の証明書を提供していません。

E メールの暗号化に ACM 証明書を使用することはできません。

ACM は現在、ACM 証明書のマネージド証明書更新のオプトアウトを許可していません。また、マネージド更新は ACM にインポートした証明書には使用できません。

末尾が amazonaws.com、cloudfront.net、または elasticbeanstalk.com などの Amazon が所有するドメイン名に証明書をリクエストすることはできません。

ACM 証明書のプライベートキーをダウンロードすることはできません。

Amazon Elastic Compute Cloud (Amazon EC2) のウェブサイトまたはアプリケーションに ACM Certificate を直接インストールすることはできません。ただし、どの統合されたサービスでも証明書を使用できます。詳細については、「と統合されたサービス AWS Certificate Manager」を参照してください。

ACMは、EV証明書とOV証明書を提供していない
ACMは、SSL/TLS以外の証明書を提供してない
Eメールの暗号化に、ACM証明書は使用できない
マネージド証明書更新のオプトアウトは許可してない。インポート証明書に利用できない
ACM証明書のプライベートキーをダウンロードできない
EC2のWebサイト、アプリにACM Certificateを直接インストールできない

Services integrated with AWS Certificate Manager

サービス	説明
Elastic Load Balancing	・SSL/TLS 経由で安全なコンテンツを供給するために、ロードバランサーまたはバックエンド Amazon EC2 インスタンスのどちらかに SSL/TLS 証明書がインストールされていることがロードバランサーより要求される・ロードバランサーに証明書をデプロイする
Amazon CloudFront	・SSL/TLS CloudFront 経由で安全なコンテンツを配信するには、 CloudFront ディストリビューションまたはバックコンテンツソースに SSL/TLS 証明書がインストールされている必要がある・ACM 証明書をディストリビューションにデプロイする
Amazon Cognito	・Amazon CloudFront プロキシを使用するように Cognito ユーザープールを設定する場合、カスタムドメインを保護するために ACM CloudFront 証明書を設定する場合がある
AWS Elastic Beanstalk	・証明書を選択するには、Elastic Beanstalk コンソールでアプリケーションのロードバランサーを設定する必要がある。
AWS App Runner	・カスタムドメイン名を App Runner サービスに関連付けると、App Runner はドメインの有効性を追跡する証明書を内部で作成する
Amazon API Gateway	・カスタムドメイン名を設定すると、API に簡単にアクセスできる。・カスタムドメイン名を設定するには、SSL/TLS 証明書を提供する必要があります。証明書を生成またはインポートするには、ACM を使用できる
AWS Nitro Enclaves	・Amazon EC2 の機能・Enclaves は、分離された、強化された、制約の厳しい仮想マシン・Nitro Enclaves に接続されている EC2 インスタンスは、ACM 証明書をサポートしている
AWS CloudFormation	ACM 証明書はテンプレートリソースとして含まれているので、ACM 証明書をリクエストして、 AWS サービスと併用して安全な接続を実現できる
AWS Amplify	カスタムドメインをアプリケーションに接続すると、Amplify コンソールは ACM 証明書を発行してセキュリティを確保する
Amazon OpenSearch Service	OpenSearch カスタムドメインとエンドポイントを含むサービスクラスターを作成すると、ACM を使用して関連する Application Load Balancer に証明書をプロビジョニングできる。
AWS Network Firewall	Network Firewall ファイアウォールは、TLS 検査のために ACM と統合される。・Network Firewall で TLS 検査を使用する場合は、ファイアウォールを通過する SSL/TLS トラフィックの復号化および再暗号化に ACM 証明書を設定する必要がある。

AWS Certificate Manager の料金

AWS Certificate Manager でプロビジョニングされたパブリック SSL/TLS 証明書は無料です。お支払いいただくのは、アプリケーションを実行するために作成した AWS リソースの料金のみです。
ACM を介して AWS Private Certificate Authority (CA) を管理する場合は、AWS Private CA の料金ページで詳細と例をご覧ください。

パブリック SSL/TLS証明書は無料

Security in AWS Certificate Manager

Data protection in AWS Certificate Manager

Security for certificate private keys

パブリック証明書をリクエストすると、 AWS Certificate Manager (ACM) はパブリック/プライベートkey pair を生成します。インポートされた証明書の場合、キーペアが生成されます。パブリックキーは証明書の一部となります。ACM は証明書とそれに対応する秘密鍵を保存し、 AWS Key Management Service (AWS KMS) を使用して秘密鍵を保護します。このプロセスの動作は次のようになります。

パブリック証明書をリクエストし、ACMはパブリック/プライベートのキーペアを生成する
パブリックキーは証明書の一部である
ACMは証明書とそれに対応する秘密鍵を保存し、AWS KMSを使用して秘密鍵を保護する

AWS リージョンで初めて証明書をリクエストまたはインポートすると、ACM は aws/acm AWS KMS key というエイリアスでマネージャーを作成します。この KMS AWS キーはアカウントとリージョンごとに異なります。 AWS

ACM は、この KMS キーを使用して証明書のプライベートキーを暗号化します。ACM は暗号化されたバージョンのプライベートキーのみを保存します (ACM はプレーンテキスト形式でプライベートキーを保存しません)。ACM は同じ KMS キーを使用して、 AWS 特定のアカウントと特定のリージョンのすべての証明書のプライベートキーを暗号化します。 AWS

証明書を AWS Certificate Managerと統合されたサービスに関連付けると、ACM は証明書と暗号化されたプライベートキーをサービスに送信します。サービスが KMS AWS KMS キーを使用して証明書のプライベートキーを復号化できるようにするグラントも作成されます。許可の詳細については、「AWS Key Management Service デベロッパーガイドの許可の使用」を参照してください。ACM でサポートされているサービスの詳細については、「と統合されたサービス AWS Certificate Manager」を参照してください。

統合サービスは、KMS キーを使用してプライベートキーを復号化します。続いて、サービスは、証明書と復号された (プレーンテキスト) プライベートキーを使用してクライアントと安全な通信チャネル (SSL/TLS セッション) を確立します。

証明書と統合サービスとの関連付けが解除されると、ステップ 3 で作成された許可は廃止されます。つまり、サービスは KMS キーを使用して証明書のプライベートキーを復号化できなくなります。

証明書のリクエスト or インポートすると、ACMは、aws/ acmというエイリアスでKMSが作られる
ACMは、KMSキーを使用して証明書のプライベートキーを暗号化する。ACMは暗号化されたバージョンのプライベート期のみ保存する。ACMは同じKMSキーを使用して、AWSの特定のアカウントとリージョンのすべての証明書のプライベートキーを暗号化する
証明書をACMと統合されたサービスに関連付けると、ACMは証明書と暗号化済みのプライベートキーをサービスに送信する。このとき権限も付与する
統合サービスは、KMSキーをしようしてプライベートキーを複合する。次にサービスは証明書と複合されたプライベートキーを使用してクライアントと安全な通信チャンネルを確立する

（参考）X.509 証明書とは

Webから拾ってきた内容をもとに整理しています。

認証局の厳密な階層構造を規定する
通信先のウェブサイトが本当に主張する存在（企業や組織）であると証明するデジタル証明書を利用する
その証明書の形式がX.509という国際標準規格に則って作成されている
役割は下記の二点。これらをデジタル証明書を使用して確認する
- 通信相手の正しさ（本当に正しい相手か）：認証
- 通信内容が途中で改ざんされていないか：データの完全性
活用事例
- SSL/TLSにおけるX.509認証
  - ウェブサイトでHTTPS通信を行う場合に、SSL/TLSが利用されるが、これらのプロトコルでサーバ証明書（X.509証明書）が利用される
- VPNにおけるX.509認証
  - VPNでは、通信時に暗号化するため利用します
  - クライアント証明書と、サーバ証明書が一組となるX.509証明書が利用される

考察

今回、AWS Certification Managerを整理してみました。利用するにはドメインの登録が必要であるため、次回はRoute53等でドメイン登録してみようと思います。

参考