AWS ACM入門 DV・OV・EV証明書の違いと選び方

Posted at 2026-08-30

はじめに

AWSでWebサイトやAPIをHTTPS化するとき、AWS Certificate Manager（ACM）で証明書を発行できます。

ここで迷いやすいのが、次の違いです。

ACMが発行する証明書はDV・OV・EVのどれか
DVはOVやEVより暗号が弱いのか
顧客からOVやEVを求められたら、AWSではどう構成するか
CloudFrontやALBでは、どのリージョンに証明書を作るか

この記事では、証明書の種類を「暗号の強さ」ではなく、 発行前に誰をどこまで確認するか という観点から整理します。

先に結論

ACMが直接発行するパブリック証明書は DV証明書 です。
AWSは、パブリックなOV証明書・EV証明書を直接発行しません。
OV・EVが明示的に必要なら、外部認証局で取得してACMへインポートします。
DV・OV・EVの違いは、基本的に暗号強度ではなく 申請者の確認範囲 です。
通常のWebサイトやAPIなら、 ACM発行のDV証明書＋DNS認証 が第一候補です。
CloudFront用のACM証明書は、バージニア北部リージョン（us-east-1）に作成します。

最初の判断は、次の表で十分です。

要件	選択肢
一般的なWebサイトやAPIをHTTPS化したい	ACM発行のパブリック証明書（DV）
契約・調達・監査でOVまたはEVが明記されている	外部認証局で取得し、ACMへインポート
社内システム、mTLS、端末認証などに使いたい	AWS Private CAを検討

前提

対象読者: AWSでWebサイトやAPIを初めてHTTPS化する方
確認日: 2026-08-28
対象範囲: ACMが発行するパブリック証明書、外部証明書のインポート、AWS Private CAの違い
扱わない範囲: 認証局の購入手続き、TLS暗号スイートの詳細設計、社内PKIの完全な構築手順
注意: 証明書の有効期間、料金、対応サービス、認証方法は変わる可能性があります。構築時はAWS公式ドキュメントを確認してください。

最初に知っておきたい用語

用語	短い説明
SSL/TLS証明書	接続先のドメインなどを示し、HTTPS通信に使う電子証明書。現在の通信プロトコルは主にTLSですが、慣習的にSSL証明書とも呼ばれます
認証局（CA）	証明書を審査・発行する機関。Certificate Authorityの略です
ACM	AWS Certificate Manager。証明書の発行、保管、AWSサービスへの関連付け、条件を満たす証明書の更新を管理します
DV	Domain Validation。ドメインを管理できることを確認します
OV	Organization Validation。ドメイン管理に加えて、組織の実在性などを確認します
EV	Extended Validation。組織や申請権限などを、より厳格な基準で確認します
PKI	Public Key Infrastructure。証明書と公開鍵暗号を使って、通信相手や端末などを信頼する仕組みです
mTLS	相互TLS。サーバーだけでなく、接続するクライアント側も証明書で認証します

DV・OV・EVは何が違うのか

違いを身分確認にたとえると、次のようになります。

種類	たとえ	認証局が主に確認するもの	AWSが直接発行
DV	この住所の鍵を管理しています	ドメインの管理権限	できる
OV	この住所を使う実在企業です	ドメイン＋組織の実在性	できない
EV	会社情報と申請権限まで厳格に確認済みです	ドメイン＋組織情報＋申請権限など	できない

AWS公式ドキュメントでは、ACMが発行するパブリック証明書を、ドメイン名だけを識別するDV証明書と説明しています。つまり、ACM発行証明書は運営会社の実在性までは証明しません。(AWS公式: ACMパブリック証明書の特徴)

DV証明書

DVでは、申請者が対象ドメインを管理できることを確認します。

ACMのDNS認証では、AWSが指定したCNAMEレコードをDNSへ登録します。AWSがそのレコードを確認できると、ドメインの管理権限があると判断して証明書を発行します。

DVは、一般的なWebサイト、API、SaaS、管理画面などのHTTPS化に向いています。

ただし、証明書を見ても「この会社が運営している」とまでは確認できません。DVが証明するのは、あくまでドメインを管理できることです。

OV証明書

OVでは、ドメインの管理権限に加えて、申請した組織が実在することなどを認証局が確認します。

確認内容は認証局や規定によって異なりますが、法人名、所在地、登録情報、ドメインとの関係、申請権限などが対象になります。確認済みの組織名は、証明書のSubject情報などに含まれます。

OVを検討するのは、次のような場合です。

顧客との契約でOV証明書が指定されている
調達基準や監査基準で組織認証が必要
証明書から運営組織を確認できることが要件になっている

「BtoBだから必ずOV」という決まりではありません。必要性は、契約やセキュリティ要件で判断します。

EV証明書

EVでは、組織の法的な実在性、所在地、ドメイン管理権限、申請者や契約責任者の権限などを、OVより厳格な基準で確認します。

CA/Browser Forumは、EV証明書へ正式な組織名、ドメイン名、設立地、登録番号などを含めるための要件を示しています。(CA/Browser Forum: EV証明書の内容)

EVは、契約、監査、社内規定などでEVの利用が明示されている場合に選びます。「金融サービスだから必ずEV」のように業種だけで決めず、実際の要件を確認することが大切です。

「DVは暗号が弱い」は誤解

DV・OV・EVは、証明書を発行する前の 本人確認レベル を表します。

実際の通信セキュリティには、別の要素が関係します。

観点	主に決めるもの
誰を確認して証明書を発行したか	DV・OV・EV
通信に使うプロトコル	TLS 1.2、TLS 1.3など
通信に使う暗号方式	Cipher Suite、鍵交換方式、署名アルゴリズムなど
サーバー側の安全性	セキュリティポリシー、設定、パッチ、秘密鍵管理など

そのため、次の理解は正しくありません。

誤った理解

DV = 弱い暗号
OV = 普通の暗号
EV = 強い暗号

正しくは、次のように考えます。

正しい理解

DV = ドメインを管理できることを確認
OV = ドメイン管理に加えて組織の実在性を確認
EV = 組織や申請権限などを、より厳格に確認

DVでも、適切なTLSバージョン、暗号ポリシー、鍵管理を選べば、安全なHTTPS通信を構成できます。

AWSで扱う証明書は3つに分けて考える

1. ACMが発行するパブリック証明書

通常のWebサイトやAPIでは、最初にこの方法を検討します。

主な特徴は次のとおりです。

ACMが発行する証明書はDV
CloudFront、Elastic Load Balancing、API Gatewayなど、ACM統合サービスで利用できる
DNS認証を選び、更新条件を満たせばACMが更新を管理する
統合AWSサービスで使う非エクスポート型のパブリック証明書は、証明書自体の追加料金がない
CloudFront、ALB、API Gatewayなど、証明書を使うAWSリソースの料金は別途発生する

ACMにはエクスポート可能なパブリック証明書やACMEを使う方式もあり、こちらは料金体系と更新方法が異なります。料金を確認するときは、「ACMの証明書はすべて無料」と一括りにせず、証明書の種類を確認してください。(AWS公式: ACM料金)

2. 外部認証局から取得してACMへインポートする証明書

OV・EVが必要な場合は、外部認証局から証明書を取得し、ACMへインポートします。

インポート時は、証明書本体、暗号化されていない秘密鍵、証明書チェーンなどを適切に用意します。秘密鍵は機密情報なので、Gitリポジトリ、チャット、チケットへ貼り付けてはいけません。

ACMは、インポートした証明書を自動更新しません。
有効期限の監視、新しい証明書の取得、再インポートは利用者側の責任です。再インポートを使えば、既存のARNとAWSサービスとの関連付けを維持できます。(AWS公式: 証明書のインポート)

3. AWS Private CAが発行するプライベート証明書

AWS Private CAは、組織内で使うプライベートな認証局をAWS上に構築するサービスです。

主な用途は次のとおりです。

社内システム
サービス間のmTLS
社員端末やサーバーの認証
IoT機器の認証
VPNや内部ネットワークの認証

プライベート証明書は、一般のブラウザやOSから最初から信頼されるとは限りません。利用する端末やシステムへ、組織のルート証明書を安全に配布する設計が必要です。また、AWS Private CAには利用料金があります。(AWS公式: プライベート証明書)

どの証明書を選ぶか

リージョンを間違えない

ACM証明書はリージョン単位のリソースです。証明書を使うAWSサービスに合わせて、申請またはインポートするリージョンを選びます。

利用先	ACM証明書を置くリージョン
CloudFront	バージニア北部 `us-east-1`
Application Load Balancer	ALBと同じリージョン
API GatewayのRegionalカスタムドメイン	APIと同じリージョン
API Gatewayのエッジ最適化カスタムドメイン	バージニア北部 `us-east-1`

CloudFrontでは、オリジンが東京リージョンにあっても、ビューワーとのHTTPS通信に使うACM証明書はus-east-1へ作成します。(AWS公式: CloudFrontの証明書要件)

API GatewayのRegionalカスタムドメインはAPIと同じリージョン、エッジ最適化カスタムドメインはus-east-1の証明書を使います。(AWS公式: Regionalカスタムドメイン) (AWS公式: エッジ最適化カスタムドメイン)

ACMでDV証明書を発行する基本手順

1. 利用先からリージョンを決める

最初にCloudFront、ALB、API Gatewayなど、証明書を関連付けるサービスを決めます。

「サーバーが東京リージョンだから、とりあえず東京に証明書を作る」と判断すると、CloudFrontで選択できないことがあります。

2. 証明書へ含めるドメイン名を決める

たとえば、次の2つを利用するなら、両方を証明書へ含めます。

ドメイン名の例

example.com
*.example.com

*.example.comは、www.example.comやapi.example.comを保護できます。ただし、example.com自体や、dev.api.example.comのように階層が深い名前は保護しません。必要な名前を漏れなく指定してください。(AWS公式: ACMパブリック証明書の特徴)

3. DNS認証を選ぶ

新しく構築するなら、基本的にDNS認証を選びます。

Route 53で対象ドメインを管理している場合は、ACMコンソールから検証用レコードを作成できます。外部DNSを使っている場合は、表示されたCNAME名と値を外部DNSへ登録します。

証明書の発行後も、検証用CNAMEは削除しないでください。CNAMEが名前解決でき、証明書が対象AWSサービスに関連付いているなどの条件を満たすと、ACMのマネージド更新を利用できます。(AWS公式: DNS認証) (AWS公式: マネージド更新)

AWSは、ACMのメール認証を段階的に終了する予定です。
新規証明書リクエストでのメール認証は2027年3月31日、既存のメール認証証明書の更新は2027年9月30日に終了予定です。既存環境も含め、DNS認証への移行計画を確認してください。(AWS Security Blog)

4. AWSサービスへ関連付ける

証明書の状態がISSUEDになったら、CloudFront、ALB、API GatewayなどのHTTPS設定で証明書を選択します。

発行しただけではHTTPS通信には使われません。対象サービスへの関連付けと、DNSの向き先設定まで確認します。

AWS CLIで既存証明書を確認する

次の例では、証明書を作成・変更せず、既存証明書の状態を確認します。

ターミナル

# 確認したい証明書のARNとリージョンを指定する
CERTIFICATE_ARN="arn:aws:acm:us-east-1:123456789012:certificate/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
REGION="us-east-1"

# 証明書の状態、発行元種別、有効期限、利用先、更新可否を確認する
aws acm describe-certificate \
  --certificate-arn "$CERTIFICATE_ARN" \
  --region "$REGION" \
  --query 'Certificate.{DomainName:DomainName,Status:Status,Type:Type,Issuer:Issuer,NotAfter:NotAfter,RenewalEligibility:RenewalEligibility,InUseBy:InUseBy}' \
  --output yaml

主な確認項目は次のとおりです。

項目	見る内容
`Status`	`ISSUED`になっているか
`Type`	`AMAZON_ISSUED`か`IMPORTED`か
`NotAfter`	有効期限はいつか
`RenewalEligibility`	マネージド更新の対象になり得るか
`InUseBy`	どのAWSリソースで使われているか

TypeはACM上の取得方法を表す項目です。AMAZON_ISSUEDはACM発行、IMPORTEDは外部証明書のインポートを意味します。TypeにOVやEVという値が表示されるわけではありません。

DNS認証用のレコードは、次のコマンドで確認できます。