翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # とは AWS Private CA AWS Private CA では、オンプレミス CA を運用するための投資とメンテナンスのコストをかけずに、ルート CA と下位 CAs を含むプライベート認証機関 (CA) 階層を作成できます。プライベート CA は、次のようなシナリオでエンドエンティティ X.509 証明書を発行できます。 + 暗号化された TLS 通信チャネルの作成 + ユーザー、コンピュータ、API エンドポイント、および IoT デバイスの認証 + 暗号署名コード + 証明書失効ステータスを取得するためのオンライン証明書ステータスプロトコル (OCSP) の実装 AWS Private CA オペレーションには、 から AWS マネジメントコンソール、 AWS Private CA API を使用して、または を使用してアクセスできます AWS CLI。 **Topics** + [のリージョンの可用性 AWS Private Certificate Authority](#PcaRegions) + [と統合されたサービス AWS Private Certificate Authority](#PcaIntegratedServices) + [でサポートされている暗号化アルゴリズム AWS Private Certificate Authority](#supported-algorithms) + [での RFC 5280 コンプライアンス AWS Private Certificate Authority](#RFC-compliance) + [の料金 AWS Private Certificate Authority](#PcaPricing) + [の用語と概念 AWS Private CA](PcaTerms.md) ## のリージョンの可用性 AWS Private Certificate Authority ほとんどの AWS リソースと同様に、プライベート認証機関 (CAs) はリージョンリソースです。複数のリージョンでプライベート CA を使用するには、それらのリージョンで CA を作成する必要があります。リージョン間でプライベート CA をコピーすることはできません。「AWS 全般のリファレンス」の「[AWS リージョンとエンドポイント](https://docs.aws.amazon.com/general/latest/gr/rande.html#pca_region)」、または「[AWS リージョン表](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)」で「 AWS Private CAを利用できるリージョン」を参照してください。 **注記** ACM は現在、そう AWS Private CA でない一部のリージョンで利用できます。 ## と統合されたサービス AWS Private Certificate Authority AWS Certificate Manager を使用してプライベート証明書をリクエストする場合、その証明書を ACM と統合された任意のサービスに関連付けることができます。これは、 AWS Private CA ルートに連鎖された証明書と外部ルートに連鎖された証明書の両方に適用されます。詳細については、「 AWS Certificate Manager ユーザーガイド」の[「統合サービス](https://docs.aws.amazon.com/acm/latest/userguide/acm-services.html)」を参照してください。 プライベート CA を Amazon Elastic Kubernetes Service に統合して、Kubernetes クラスター内で証明書を発行することもできます。詳細については、「[で Kubernetes を保護する AWS Private Certificate Authority](PcaKubernetes.md)」を参照してください。 **注記** Amazon Elastic Kubernetes Service は ACM 統合サービスではありません。 AWS Private CA API または を使用して証明書 AWS CLI を発行したり、ACM からプライベート証明書をエクスポートしたりする場合は、任意の場所に証明書をインストールできます。 ## でサポートされている暗号化アルゴリズム AWS Private Certificate Authority AWS Private CA は、プライベートキーの生成と証明書署名のために次の暗号化アルゴリズムをサポートしています。 **サポートされているアルゴリズム** | プライベートキーアルゴリズム | 署名アルゴリズム | | --- | --- | | ML\$1DSA\$144 ML\$1DSA\$165 ML\$1DSA\$187 RSA\$12048 RSA\$13072 RSA\$14096 EC\$1prime256v1 EC\$1secp384r1 EC\$1secp521r1 SM2 (中国リージョンのみ) | ML\$1DSA\$144ML\$1DSA\$165ML\$1DSA\$187 SHA256WITHRSASHA384WITHRSASHA512WITHRSASHA256WITHECDSA SHA384WITHECDSASHA512WITHECDSASM3WITHSM2 | このリストは、 コンソール、API、またはコマンドライン AWS Private CA を介して によって直接発行された証明書にのみ適用されます。から CA を使用して証明書 AWS Certificate Manager を発行する場合 AWS Private CA、これらのアルゴリズムの一部はサポートされますが、すべてはサポートされません。詳細については、 AWS Certificate Manager ユーザーガイド[の「プライベート証明書のリクエスト](https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-request-private.html)」を参照してください。 **注記** RSA または ECDSA の場合、指定された署名アルゴリズムファミリーは CA のプライベートキーのキーアルゴリズムファミリーと一致する必要があります。 ML-DSA の場合、ハッシュ関数はアルゴリズム自体の一部として定義されます。ML-DSA で別のハッシュ関数を選択するオプションはありません。APIs との下位互換性を維持するために、キーアルゴリズムと署名アルゴリズムに同じ値が使用されます。 ## での RFC 5280 コンプライアンス AWS Private Certificate Authority AWS Private CA は、[RFC 5280 ](https://datatracker.ietf.org/doc/html/rfc5280)で定義されている特定の制約を適用しません。逆も同様で、プライベート CA に適切な追加の制約が強制されます。 **強制** + [日付を過ぎると強制されません](https://datatracker.ietf.org/doc/html/rfc5280#section-4.1.2.5)。[RFC 5280](https://datatracker.ietf.org/doc/html/rfc5280) に準拠して、 AWS Private CA は、交付元 CA 認定の交付日よりも後の `Not After` `Not After` 日付を持つ証明書は発行しません。 + [基本的な制約](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.9)。インポートされた CA 証明書に基本的な制約とパスの長さ AWS Private CA を適用します。 基本的な制約は、証明書によって識別されるリソースが CA であり、証明書を発行できるかどうかを示します。 AWS Private CA にインポートされる CA 認定には、基本的制約の拡張を含める必要があり、拡張に `critical` とマークする必要があります。`critical` フラグに加えて、 を設定`CA=true`する必要があります。 は、次の理由で検証例外で失敗することで基本的な制約 AWS Private CA を適用します。 + 拡張が CA 認定に含まれていない。 + 拡張が `critical` とマークされていない。 パスの長さ ([pathLenConstraint](PcaTerms.md#terms-pathlength)) は、インポートCAs証明書のダウンストリームに存在する可能性のある下位 CA の数を決定します。 は、次の理由で検証例外で失敗することでパスの長さ AWS Private CA を適用します。 + CA 認定をインポートすると、CA 認定またはチェーン内の任意の CA 認定のパスの長さ制約に違反する。 + 証明書を発行すると、パスの長さの制約に違反する。 + [名前制約](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.10)は、証明書パスの後続の証明書のすべてのサブジェクト名を配置する必要がある名前空間を示します。サブジェクト識別名とサブジェクト代替名には制限が適用されます。 **強制されない** + [証明書ポリシー](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.4)。証明書ポリシーは、CA が証明書を発行する条件を規制します。 + [anyPolicy を禁止](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.14)します。CAs。 + [発行者の代替名](https://datatracker.ietf.org/doc/html/rfc5280#section-section-4.2.1.7)。追加の ID を CA 証明書の発行者に関連付けることができます。 + [ポリシーの制約](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.11)。これらの制約により、CA の下位 CA 認定を交付する機能が制限されます。 + [ポリシーマッピング](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.5)。CA 証明書で使用されます。OIDs。各ペアには issuerDomainPolicy と subjectDomainPolicy が含まれます。 + [サブジェクトディレクトリ属性](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.8)。サブジェクトの識別属性を伝えるために使用されます。 + [サブジェクト情報へのアクセス](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.2.2)。拡張機能が表示される証明書のサブジェクトの情報とサービスにアクセスする方法。 + [サブジェクトキー識別子 (SKI)](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.2) と [権限キー識別子 (AKI)](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.1)。RFC では、SKI 拡張を含む CA 認定が必要です。CA によって発行された証明書には、CA 証明書の SKI に一致する AKI 拡張機能が含まれている必要があります。これらの要件 AWS は適用されません。CA 認定に SKI が含まれていない場合、発行されたエンドエンティティまたは下位 CA 認定 AKI は、発行者パブリックキーの SHA-1 ハッシュになります。 + [サブジェクトパブリックキー情報](https://datatracker.ietf.org/doc/html/rfc5280#section-4.1)および[サブジェクト別名 (SAN)](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.6)。証明書を発行する場合、 AWS Private CA は検証を実行せずに、提供された CSR から SubjectPublicKeyInfo および SAN 拡張をコピーします。 ## の料金 AWS Private Certificate Authority アカウントを作成した時点で、各プライベート CA の月額料金が課金されます。また、発行する証明書ごとに課金されます。この料金には、ACM からエクスポートする証明書と、 AWS Private CA API または CLI AWS Private CA から作成した証明書が含まれます。プライベート CA が削除された後は、それに対して課金されません。ただし、プライベート CA を復元すると、削除と復元の間の料金が課金されます。プライベートキーにアクセスできないプライベート証明書については、料金は発生しません。これらには、Elastic Load Balancing、CloudFront、API Gateway などの[統合サービス](https://docs.aws.amazon.com/acm/latest/userguide/acm-services.html)で使用される証明書が含まれます。 最新の AWS Private CA 料金情報については、[AWS Private Certificate Authority 「 ](https://aws.amazon.com/private-ca/pricing/)料金表」を参照してください。[AWS 料金計算ツール](https://calculator.aws/#/createCalculator/certificateManager) でコストを見積もることもできます。 # の用語と概念 AWS Private CA 以下の用語と概念は、作業に役立ちます AWS Private Certificate Authority。 **Topics** + [信頼](#terms-trust) + [TLS サーバー証明書](#terms-tlscert) + [証明書の署名](#terms-signing) + [認証局](#terms-ca) + [ルート CA](#terms-rootca) + [CA 証明書](#terms-ca-cert) + [ルート CA 証明書](#terms-root) + [エンドエンティティ証明書](#terms-endentity) + [自己署名証明書](#terms-selfsignedcert) + [プライベート証明書](#terms-pca-cert) + [証明書のパス](#terms-certpath) + [パスの長さの制約](#terms-pathlength) ## 信頼 ウェブブラウザがウェブサイトのアイデンティティを信頼するために、ウェブサイトの証明書がブラウザによって検証できる必要があります。しかし、ブラウザは CA ルート証明書と呼ばれるほんのわずかな証明書のみを信頼します。認証機関 (CA) と呼ばれる信頼されるサードパーティは、ウェブサイトのアイデンティティを検証し、ウェブサイト運営者に署名されたデジタル証明書を発行します。こうしてブラウザはデジタル署名を確認して、ウェブサイトのアイデンティティを検証します。検証に成功した場合は、ブラウザのアドレスバーにロックアイコンが表示されます。 ## TLS サーバー証明書 HTTPS トランザクションは、サーバーを認証するためにサーバー証明書を要求します。サーバー証明書とは、証明書のパブリックキーを証明書の件名にバインドする X.509 v3 データ構造です。TLS 証明書は、認証機関 (CA) によって署名されています。これには、サーバーの名前、有効期間、パブリックキー、署名アルゴリズムなどが含まれます。 ## 証明書の署名 デジタル署名は、証明書上の暗号化されたハッシュです。署名は、証明書データの整合性を確認するために使用します。プライベート CA は、可変サイズの証明書コンテンツに SHA256 などの暗号化ハッシュ関数を使用して署名を作成します。このハッシュ関数は、効果的に偽造不可能な固定サイズのデータ文字列を生成します。この文字列はハッシュと呼ばれます。次に CA は、プライベートキーを使用してハッシュ値を暗号化し、暗号化したハッシュを証明書に連結します。 ## 認証局 認証機関 (CA) は、デジタル証明書を発行し、必要に応じて、取り消します。最も一般的なタイプの証明書は ISO X.509 規格に基づくものです。X.509 証明書は、証明書のサブジェクトのアイデンティティを確認し、そのアイデンティティをパブリックキーにバインドします。サブジェクトは、ユーザー、アプリケーション、コンピュータ、またはその他のデバイスです。CA は証明書に署名するために、コンテンツをハッシュし、そのハッシュを証明書のパブリックキーに関連するプライベートキーで暗号化します。サブジェクトのアイデンティティを確認する必要があるクライアントアプリケーション (ウェブブラウザなど) は、パブリックキーを使用して証明書の署名を復号します。次に証明書のコンテンツをハッシュし、ハッシュした値と復号した署名を比較して一致するかどうかを確認します。証明書の署名の詳細については、「[証明書の署名](#terms-signing)」を参照してください。 AWS Private CA を使用してプライベート CA を作成し、プライベート CA を使用して証明書を発行できます。プライベート CA は、組織内で使用するプライベート SSL/TLS 証明書のみを発行します。詳細については、「[プライベート証明書](#terms-pca-cert)」を参照してください。プライベート CA を使用するには、事前に証明書が必要です。詳細については、「[CA 証明書](#terms-ca-cert)」を参照してください。 ## ルート CA ルート CA とは暗号構築ブロックで、証明書を発行できる信頼のルートのことです。証明書に署名 (発行) するためのプライベートキーと、ルート CA を識別し、プライベートキーを CA 名にバインドするルート証明書で構成されています。ルート証明書は、環境内の各エンティティの信頼ストアに配布されます。管理者は、信頼する CA のみを含めるように信頼ストアを構築します。管理者は、信頼ストアをオペレーティングシステム、インスタンス、および環境内のエンティティのホストマシンイメージに更新または構築します。リソースが互いに接続しようとシた場合、各エンティティが提示する証明書を確認します。クライアントは、証明書の有効性、および証明書から信頼ストアにインストールされているルート証明書へのチェーンが存在するかどうかを確認します。これらの条件が満たされると、リソース間で「ハンドシェイク」が実行されます。このハンドシェイクは、各エンティティのアイデンティティを暗号的に証明し、それらの間に暗号化された通信チャネル (TLS/SSL) を作成します。 ## CA 証明書 認証機関 (CA) 証明書では、CA のアイデンティティを確認し、これを証明書内のパブリックキーにバインドします。 AWS Private CA を使用して、プライベートルート CA またはプライベート下位 CA を作成できます。各 CA は CA 証明書によってバックアップされます。下位 CA 証明書は、信頼のチェーンの上位の別の CA 証明書によって署名されます。ただし、ルート CA の場合、証明書は自己署名です。また、外部ルート権限 (オンプレミスでホストされているなど) を確立することもできます。その後、ルート権限を使用して、 AWS Private CAによってホストされる下位ルート CA 証明書に署名できます。 次の例は、 AWS Private CA X.509 CA 証明書に含まれる一般的なフィールドを示しています。CA 証明書の場合、`CA:` フィールドの `Basic Constraints` 値は `TRUE` に設定します。 ``` Certificate: Data: Version: 3 (0x2) Serial Number: 4121 (0x1019) Signature Algorithm: sha256WithRSAEncryption Issuer: C=US, ST=Washington, L=Seattle, O=Example Company Root CA, OU=Corp, CN=www.example.com/emailAddress=corp@www.example.com Validity Not Before: Feb 26 20:27:56 2018 GMT Not After : Feb 24 20:27:56 2028 GMT Subject: C=US, ST=WA, L=Seattle, O=Examples Company Subordinate CA, OU=Corporate Office, CN=www.example.com Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:c0: ... a3:4a:51 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Key Identifier: F8:84:EE:37:21:F2:5E:0B:6C:40:C2:9D:C6:FE:7E:49:53:67:34:D9 X509v3 Authority Key Identifier: keyid:0D:CE:76:F2:E3:3B:93:2D:36:05:41:41:16:36:C8:82:BC:CB:F8:A0 X509v3 Basic Constraints: critical CA:TRUE X509v3 Key Usage: critical Digital Signature, CRL Sign Signature Algorithm: sha256WithRSAEncryption 6:bb:94: ... 80:d8 ``` ## ルート CA 証明書 認証機関 (CA) は通常、相互の親子関係を明確に定義した他の複数の CA を含む段階構造内に存在します。子または下位の CA はその親 CA に証明され、証明書チェーンを造り上げます。階層の最上部にある CA はルート CA とされ、その証明書はルート証明書と呼ばれます。この証明書は通常、自己署名されています。 ## エンドエンティティ証明書 エンドエンティティ証明書は、サーバー、インスタンス、コンテナ、デバイスなどのリソースを識別します。CA 証明書とは異なり、エンドエンティティ証明書は証明書の発行に使用できません。エンドエンティティ証明書のその他の一般的な用語は、「クライアント」または「リーフ」証明書です。 ## 自己署名証明書 上位の CA ではなく、発行者によって署名された証明書。CA が維持する安全なルートから発行された証明書とは異なり、自己署名証明書は自身のルートで動作するため、大きな制限があります。自己署名証明書はワイヤー暗号化での提供には使用できるものの、アイデンティティの確認はできず、取り消しもできません。セキュリティの観点からは受け入れられません。しかし、生成が容易で、専門知識やインフラストラクチャを必要とせず、多くのアプリケーションがそれらを受け入れるために、組織により使用されます。自己署名証明書の発行には、何の制御もありません。有効期限の日付を確認する方法が無いため、これを使う組織は、証明書の有効期限切れによって使用不能に陥るリスクが大きくなります。 ## プライベート証明書 AWS Private CA 証明書は、組織内で使用できるプライベート SSL/TLS 証明書ですが、パブリックインターネットでは信頼されません。これらの証明書を使用して、クライアント、サーバー、アプリケーション、サービス、デバイス、ユーザーなどのリソースを識別します。安全な暗号化された通信チャネルを確立する場合、各リソースは次のような証明書と暗号化手法を使用してそのアイデンティティを別のリソースに対して証明します。内部の API エンドポイント、ウェブサーバー、VPN ユーザー、IoT デバイス、およびその他多くのアプリケーションでは、プライベート証明書を使用して、安全なオペレーションに必要な暗号化された通信チャネルを確立します。デフォルトでは、プライベート証明書はパブリックに信頼されません。内部管理者は、プライベート証明書を信頼するように明示的にアプリケーションを設定し、証明書を配布する必要があります。 ``` Certificate: Data: Version: 3 (0x2) Serial Number: e8:cb:d2:be:db:12:23:29:f9:77:06:bc:fe:c9:90:f8 Signature Algorithm: sha256WithRSAEncryption Issuer: C=US, ST=WA, L=Seattle, O=Example Company CA, OU=Corporate, CN=www.example.com Validity Not Before: Feb 26 18:39:57 2018 GMT Not After : Feb 26 19:39:57 2019 GMT Subject: C=US, ST=Washington, L=Seattle, O=Example Company, OU=Sales, CN=www.example.com/emailAddress=sales@example.com Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00...c7 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE X509v3 Authority Key Identifier: keyid:AA:6E:C1:8A:EC:2F:8F:21:BC:BE:80:3D:C5:65:93:79:99:E7:71:65 X509v3 Subject Key Identifier: C6:6B:3C:6F:0A:49:9E:CC:4B:80:B2:8A:AB:81:22:AB:89:A8:DA:19 X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication X509v3 CRL Distribution Points: Full Name: URI:http://NA/crl/12345678-1234-1234-1234-123456789012.crl Signature Algorithm: sha256WithRSAEncryption 58:32:...:53 ``` ## 証明書のパス 証明書に依存するクライアントは、可能であれば中間証明書のチェーンを通して、エンドエンティティ証明書から信頼されたルートへのパスが存在することを検証します。クライアントは、パス上の各証明書が有効である (失効していない) ことを確認します。また、エンドエンティティ証明書の有効期限が切れていない、整合性 (改ざんまたは変更されていない)、証明書の制約が適用されているかどうかも確認します。 ## パスの長さの制約 CA 証明書の基本制約 pathLenConstraint は、その下のチェーンに存在する可能性のある下位 CA 証明書の数を設定します。たとえば、パスの長さの制約が 0 の CA 証明書は、下位 CA を持つことはできません パス長の制約が 1 の CA は、その下に最大 1 つのレベルの下位 CA を持つことができます。[RFC 5280](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.9) では、これを「有効な証明書パスでこの証明書に続く、自己発行でない中間証明書の最大数」と定義しています。パスの長さの値にはエンドエンティティ証明書は含まれていませんが、検証チェーンの「長さ」や「深さ」に関する非公式な表現には含まれている場合があり、混乱を招きます。