ACM証明書の仕組みと使い分け：パブリック・プライベート・外部CA証明書の実践ガイド

概要

AWS Certificate Manager（ACM）で発行するパブリック証明書は、ブラウザが信頼する公的認証局（Amazon Trust Services）が発行するDV証明書です。本記事では、ACM証明書の信頼の連鎖の仕組み、AWS上での使いどころ、プライベートCA証明書との使い分け、証明書形式の確認方法まで実践的に解説します。

目次

1. ACMパブリック証明書の信頼の仕組み
2. AWS上での証明書の使いどころ
3. OV/EV証明書が必要な場合の対応
4. ACM Private CAの活用シーン
5. Route 53ドメインでの証明書管理
6. ルート証明書の配布方法
7. 証明書の形式確認と検証手順
8. 料金体系
9. 終わりに

1. ACMパブリック証明書の信頼の仕組み

証明書チェーンとブラウザ検証の流れ

ACMパブリック証明書は、Amazon Trust Services（ATS）という公的認証局が発行するDV（ドメイン認証）証明書です。ブラウザが証明書を信頼する仕組みを理解するために、証明書チェーンの検証プロセスを見ていきましょう。

TLS通信が確立される際、サーバー（ALBやCloudFront）は次の情報をブラウザに送信します。

• サーバー証明書（葉証明書、Leaf Certificate）：あなたのドメイン名（FQDN）を証明
• 中間CA証明書：Amazon RSA/ECC M0xなど
• ルートCA証明書への参照：Amazon Root CA 1/2/3/4

ブラウザは以下の手順で検証を行います。

1. サーバー証明書のSubject Alternative Name（SAN）がアクセス先のホスト名と一致するか確認
2. サーバー証明書の署名を中間CA証明書の公開鍵で検証
3. 中間CA証明書の署名をルートCA証明書の公開鍵で検証
4. ルートCA証明書がブラウザの信頼済みルートストアに存在するか確認

この一連の「証明書チェーン」が正しくつながれば、ブラウザのアドレスバーに錠前マークが表示されます。

DV証明書の意味と限界

ACMが発行するDV証明書は「このドメインをコントロールしている主体がサーバーだ」という事実を証明します。つまり、暗号化通信とドメインの正当性は保証されますが、運営組織の実在性までは証明しません。

金融機関や大企業のサイトで求められるOV（組織認証）やEV（拡張認証）証明書とは異なり、DVでは登記情報や所在地の確認は行われません。ただし、一般的なWebサイトやAPIでは、DVで十分なセキュリティレベルを確保できます。

2. AWS上での証明書の使いどころ

フロントでTLS終端するパターン（推奨）

ACMパブリック証明書は、以下のAWSサービスに直接アタッチしてTLS終端できます。

サービス	リージョン要件	特徴
CloudFront	us-east-1（バージニア北部）のACM証明書のみ	HTTP/2/3対応、SNI、オリジンへのTLS設定可能
Application Load Balancer（ALB）	同一リージョンのACM証明書	SNIで複数ドメイン対応、TLSポリシー指定可能
Network Load Balancer（NLB）	同一リージョンのACM証明書	TLSリスナーでTLS終端可能
API Gateway	同一リージョンのACM証明書	カスタムドメイン設定で利用
Elastic Beanstalk	ALB経由で利用	環境設定でACM証明書を指定
App Runner	同一リージョンのACM証明書	カスタムドメイン機能で利用

EC2での直接利用に関する注意点

ACMパブリック証明書は「秘密鍵をエクスポートできない」仕様のため、EC2インスタンス上のNginxやApacheに直接インストールすることはできません。

EC2でWebサーバーを運用する場合は、以下のいずれかの方法を選択します。

• 推奨：ALBやNLBを前段に配置してTLS終端する
• EC2に証明書を配置したい場合：Let's Encrypt、DigiCert、GlobalSignなどの公的CAから証明書を取得してサーバーに配置

プライベートCAで発行した証明書であれば秘密鍵をエクスポートできますが、これはインターネット公開サイトでは一般ユーザーのブラウザに警告が表示されるため不適切です。

よくある構成例

パターン1：CloudFront → ALB → EC2

インターネット → CloudFront（TLS終端）→ ALB（TLS終端）→ EC2
                   ↑                      ↑
            us-east-1のACM証明書    ap-northeast-1のACM証明書

CloudFrontとALBの両方にACM証明書をアタッチし、それぞれでTLS終端します。内部（ALB→EC2）もTLSにする場合は、自己署名証明書またはPrivate CA証明書をEC2に配置します。

パターン2：ALB直接公開

インターネット → ALB（TLS終端）→ EC2
                   ↑
            ap-northeast-1のACM証明書

Route 53のAレコード（エイリアス）でALBのDNS名を指定し、ACM証明書でTLSを終端します。SNI（Server Name Indication）を利用すれば、1台のALBで複数ドメインを処理できます。

3. OV/EV証明書が必要な場合の対応

信頼レベルの違い

証明書の種類による信頼レベルの違いを理解しておきましょう。

証明書タイプ	認証内容	ACM対応	用途
DV（ドメイン認証）	ドメイン所持の確認のみ	○（発行可能）	一般的なWebサイト、API
OV（組織認証）	登記、所在、電話などの審査	×（インポートのみ）	企業サイト、取引先要件
EV（拡張認証）	より厳格な組織実在確認	×（インポートのみ）	金融機関、大企業サイト

最近のブラウザではEV証明書を特別表示しない傾向があり、見た目はDVとほぼ同じ錠前になります。ただし、証明書詳細を確認すると組織情報が記載されています。

外部CAで取得してACMにインポートする手順

OV/EV証明書が必要な場合は、以下の手順で外部CAから取得してACMで利用できます。

1. CAの選定と証明書発行

• 発行元の例：DigiCert、GlobalSign、Sectigoなど
• 準備するもの：会社の登記情報、実在証明、所在確認、代表電話の確認、ドメインのコントロール（DNS/Eメール）
• CSR作成：RSA 2048/3072ビット、またはECDSA P-256を推奨

2. ACMへのインポート

受け取った証明書をPEM形式で準備し、ACMマネジメントコンソールまたはCLIからインポートします。

aws acm import-certificate \
  --certificate fileb://certificate.pem \
  --private-key fileb://private-key.pem \
  --certificate-chain fileb://certificate-chain.pem \
  --region ap-northeast-1

3. CloudFront/ALBへのアタッチ

• CloudFront：us-east-1リージョンのACMにインポートした証明書を選択
• ALB/NLB：同一リージョンのACMにインポートした証明書を選択

運用上の注意点

外部CA証明書はACMの自動更新対象外です。以下の運用を徹底しましょう。

• 期限管理：CloudWatch Alarmで有効期限（DaysToExpiry）を監視
• 更新手順のRunbook化：更新フローを文書化して属人化を防ぐ
• CAAレコード設定：発行を許可するCAを制限してセキュリティ強化

4. ACM Private CAの活用シーン

プライベートCAは「錠前にならない」のか

ACM Private CAで発行した証明書は、一般ユーザーのブラウザでは信頼されず警告が表示されます。これは、ブラウザの信頼済みルートストアにあなたのプライベートCAが登録されていないためです。

しかし、社内端末にルート証明書を配布できる環境では、プライベートCAは非常に有用です。

プライベートCAが真価を発揮する用途

用途カテゴリ	具体例
内部Web/API	社内ポータル、管理画面、内部ALB/NLB、EKS Ingress
サービス間mTLS	Envoy/IstioやNginxでの相互認証、マイクロサービス間通信
デバイス証明	IoTデバイス、プリンタ、VDIゲートウェイ
API Gateway	mTLS認証、PrivateLink越しの内部TLS
Active Directory連携	AD Connectorによる自動発行

オフラインルートCA + ACMサブCAの構成

セキュリティを重視する企業では、以下の構成が推奨されます。

オフラインルートCA（外部HSM）
        ↓（CSR署名）
ACM Private CA（サブCA、オンライン運用）
        ↓（証明書発行）
エンドエンティティ証明書（サーバー/クライアント）

手順概要

1. ACM Private CAで「サブCA」を作成（未署名状態）
2. CSRを抽出してオフラインルートCAで署名
3. 署名済みCA証明書をACMにインポートしてアクティブ化
4. オフラインルートCA証明書を社内端末に配布

この構成により、ルート鍵を完全オフラインに置けるため、セキュリティリスクを最小化できます。

5. Route 53ドメインでの証明書管理

Route 53ドメインと証明書の関係

Route 53で取得・管理しているドメインでも、公的CA証明書とプライベートCA証明書の両方を発行・利用できます。「ブラウザに信頼されるか」は、発行元が公的CAか、クライアントにルート証明書が配布されているかで決まります。

使い分けの判断フロー

外部公開でブラウザ信頼が必要
  → ACM Public（DV）または外部CA（OV/EV）→ ACMインポート

社内限定・mTLSなど
  → ACM Private CA（端末へのルート配布必須）

Route 53を使うメリット

メリット	説明
DNS検証が迅速	検証CNAMEレコードをワンクリックで自動作成
CAA設定が簡単	発行を許可するCAを制限してセキュリティ強化
DNSSEC対応	DNS改ざん対策とTLSを併用可能

DNS検証を使用する場合、Route 53では以下のようにCNAMEレコードを自動作成できます。

aws acm request-certificate \
  --domain-name example.com \
  --validation-method DNS \
  --region ap-northeast-1

ACMコンソールから「Route 53でレコードを作成」ボタンをクリックするだけで、検証用CNAMEが自動で追加されます。

6. ルート証明書の配布方法

なぜルート証明書の配布が必要か

ACM Private CAを使用する場合、社内端末やアプリケーションの信頼ストアにルートCA証明書を配布しなければ、証明書が信頼されず警告が表示されます。

OS別の配布手順

Windows（エンタープライズ）

Group Policyを使用して一括配布します。

Computer Configuration 
  → Policies 
  → Windows Settings 
  → Security Settings 
  → Public Key Policies 
  → Trusted Root Certification Authorities

単体端末での手動インストール：

certutil -addstore -f Root C:\path\to\root-ca.cer

macOS

MDM（Intune、Jamfなど）で「Trusted Certificate」ペイロードを配布するのが定石です。

手動インストール：

sudo security add-trusted-cert -d -r trustRoot \
  -k /Library/Keychains/System.keychain root-ca.cer

iOS/iPadOS

MDMで「Trusted Certificate」を配布します。手動の場合は、プロファイル経由でインストール後、以下の設定が必要です。

設定 → 一般 → 情報 → 証明書信頼設定
  → 「完全な信頼を有効にする」をON

Linux（Debian/Ubuntu）

sudo cp root-ca.crt /usr/local/share/ca-certificates/
sudo update-ca-certificates

Linux（RHEL/CentOS/Amazon Linux）

sudo cp root-ca.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust

Firefox（独自ストア）

企業運用では、FirefoxにOS証明書ストアを使わせるポリシーを有効化します（Windowsの場合はenterprise_rootsをON）。

手動インストール：

設定 → プライバシーとセキュリティ 
  → 証明書を表示 → 認証局 → インポート

Java（JVM系アプリ）

keytool -importcert -trustcacerts \
  -alias my-root \
  -file root-ca.crt \
  -keystore truststore.jks \
  -storepass changeit

失効設定（CRL/OCSP）の確認

ルート証明書を配布した後は、CRL（証明書失効リスト）やOCSP（Online Certificate Status Protocol）への到達性を確認しましょう。プロキシやファイアウォールでブロックされていると、証明書の失効確認ができません。

ACM Private CAでは、以下の設定でCRLとOCSPを有効化できます。

• CRL：S3バケットに配布
• OCSP：ACMが提供するOCSPレスポンダーを使用

7. 証明書の形式確認と検証手順

ブラウザでの証明書確認

ブラウザのアドレスバーの錠前アイコンをクリックして、証明書情報を確認できます。

確認すべきポイント

• 発行者（Issuer）：Amazon RSA/ECC、Amazon Root CAなどの名前が表示される
• サブジェクト（Subject）：自分のドメイン名が正しく表示される
• Subject Alternative Names（SAN）：アクセスしたホスト名が含まれている
• 有効期限：証明書が有効期間内である
• 証明書チェーン：中間CA → ルートCAと正しく連鎖している

OpenSSLコマンドでの詳細確認

コマンドラインで証明書チェーンを詳細に確認できます。

基本的な接続テスト

openssl s_client -connect example.com:443 -servername example.com

証明書チェーン全体を表示

openssl s_client -connect example.com:443 \
  -servername example.com -showcerts

証明書ファイルの内容確認

# PEM形式の証明書を読みやすく表示
openssl x509 -in certificate.pem -text -noout

# 証明書の発行者と有効期限のみ表示
openssl x509 -in certificate.pem -noout -issuer -dates

# 証明書のSANを確認
openssl x509 -in certificate.pem -noout -ext subjectAltName

証明書と秘密鍵のペア確認

証明書と秘密鍵が正しくペアになっているか確認します。両者のModulusが一致すればペアが正しいことが確認できます。

# 証明書のModulusを表示
openssl x509 -noout -modulus -in certificate.pem | openssl md5

# 秘密鍵のModulusを表示（同じ値になるはず）
openssl rsa -noout -modulus -in private-key.pem | openssl md5

証明書チェーンの検証

外部CAから取得した証明書をACMにインポートする前に、証明書チェーンが正しいか検証しておくと安心です。

# ルートCAと中間CAで証明書を検証
openssl verify -CAfile root-ca.pem \
  -untrusted intermediate-ca.pem \
  certificate.pem

成功するとcertificate.pem: OKと表示されます。

PEM形式とDER形式の変換

ACMはPEM形式を要求しますが、外部CAからDER形式で証明書を受け取った場合は変換が必要です。

DER → PEM変換

openssl x509 -inform DER -in certificate.der \
  -outform PEM -out certificate.pem

PEM → DER変換

openssl x509 -inform PEM -in certificate.pem \
  -outform DER -out certificate.der

証明書の形式が正しいか確認

ACMにインポートする前に、証明書ファイルが正しいPEM形式か確認します。

# 証明書ファイルの形式確認
openssl x509 -in certificate.pem -text -noout

# エラーが出なければPEM形式として正しい

PEM形式の証明書は、以下のような構造になっています。

-----BEGIN CERTIFICATE-----
MIIDXTCCAkWgAwIBAgIJAKJ...（Base64エンコードされたデータ）
-----END CERTIFICATE-----

複数の証明書を含むチェーンファイルの場合、上記のブロックが複数連なっている形式になります。

AWS CLIでのACM証明書確認

ACMに登録されている証明書の情報を確認するコマンドです。

# 証明書一覧の取得
aws acm list-certificates --region ap-northeast-1

# 特定の証明書の詳細情報を取得
aws acm describe-certificate \
  --certificate-arn arn:aws:acm:ap-northeast-1:123456789012:certificate/xxxxx \
  --region ap-northeast-1

ACMに登録された証明書の有効期限や検証状態、使用中のリソースなどを確認できます。

8. 料金体系

ACMパブリック証明書の料金（2025年2月時点）

ACM統合サービス（CloudFront、ALB、NLBなど）で使用する場合、パブリック証明書は無料です。証明書の発行・更新・管理に追加料金はかかりません。

ただし、2025年6月に発表された「エクスポート可能なパブリック証明書」は有料となります。

証明書タイプ	料金
FQDN 1つ	$15（発行時および更新時）
ワイルドカード名 1つ	$149（発行時および更新時）

エクスポート可能な証明書は、EC2インスタンスやオンプレミスサーバーなど、ACM統合サービス以外で使用する場合に選択します。有効期間は395日です。

最新の料金情報は「AWS Certificate Manager の料金 ( https://aws.amazon.com/jp/certificate-manager/pricing/ )」を参照してください。

ACM Private CAの料金（2025年2月時点）

ACM Private CAは、CAの運用コストと発行する証明書ごとに料金がかかります。

CAの運用コスト（月額）

モード	料金	用途
汎用モード（General-purpose）	$400/月	任意の有効期間の証明書を発行可能
短期間証明書モード（Short-lived）	$50/月	最大7日間の証明書のみ発行可能

CAの運用コストは日割り計算されます。削除後は課金されませんが、復元した場合は削除から復元までの期間も課金対象となります。

証明書の発行料金（汎用モード）

月間発行数に応じた従量課金です。

月間発行数	1証明書あたりの料金
最初の1,000件	$0.75
1,001〜10,000件	$0.35
10,001件以上	$0.001

無料トライアル

各リージョンで最初に作成するPrivate CAは、30日間無料で試用できます（証明書発行料は別途課金）。トライアルを終了する場合は、CAを削除してください。

最新の料金情報は「AWS Private CA の料金 ( https://aws.amazon.com/jp/private-ca/pricing/ )」を参照してください。

注意：料金は変動する可能性があります。実際の導入前には公式料金ページで最新情報をご確認ください。

コスト最適化のポイント

• パブリック証明書：ACM統合サービスで使う限り無料。ALBやCloudFrontの前段に配置することでコスト削減
• プライベートCA：短期間証明書モード（$50/月）は、Kubernetes環境やマイクロサービスのmTLSなど、短命証明書で十分な用途に最適
• 発行数の最適化：証明書の発行数が多い場合は階層価格が適用されるため、まとめて発行することでコスト効率が向上

9. 終わりに

本記事では、ACM証明書の信頼の仕組みから、AWS上での使いどころ、プライベートCA活用、証明書形式の確認方法まで解説しました。

まとめ

• ACMパブリック証明書は公的CA（Amazon Trust Services）によるDV証明書で、一般的なWebサイトやAPIに最適
• CloudFront、ALB、NLBなどのACM統合サービスで使用する場合は無料
• EC2に直接インストールする場合は、エクスポート可能な証明書（有料）または外部CA証明書を使用
• OV/EV証明書が必要な場合は、外部CAで取得してACMにインポート
• プライベートCAは社内システムやmTLSで真価を発揮（端末へのルート配布が前提）
• 証明書の形式確認にはopensslコマンドが有効

次のステップ

ACM証明書を活用したセキュアなシステム構築のために、以下のトピックも検討してください。

• TLSポリシーの設定：TLS 1.2/1.3、強力な暗号スイート、OCSP Stapling
• HSTSの有効化：HTTP Strict Transport Securityでセキュリティ強化
• CAA DNS レコード：発行を許可するCAを制限
• Certificate Transparency監視：不正発行の検知

本記事が、皆さんのAWS上でのセキュアなシステム構築に役立てば幸いです。

参考文献・参考サイト

• 「AWS Certificate Manager とは」AWS Documentation, https://docs.aws.amazon.com/ja_jp/acm/latest/userguide/acm-overview.html
• 「AWS Private Certificate Authority とは」AWS Documentation, https://docs.aws.amazon.com/ja_jp/privateca/latest/userguide/PcaWelcome.html
• 「AWS Certificate Manager の料金」AWS Documentation, https://aws.amazon.com/jp/certificate-manager/pricing/
• 「AWS Private CA の料金」AWS Documentation, https://aws.amazon.com/jp/private-ca/pricing/
• 「Amazon Trust Services について」Amazon Trust Services, https://www.amazontrust.com/repository/
• 「証明書の検証」AWS Certificate Manager ドキュメント, https://docs.aws.amazon.com/ja_jp/acm/latest/userguide/dns-validation.html