DV 証明書（Domain Validation）

概要

DV 証明書（Domain Validation） は、申請者がドメインの管理権限を持っていることだけを確認して発行される SSL/TLS 証明書です。CA/Browser Forum の Baseline Requirements Section 3.2.2.4 で検証方法が規定されており、組織の実在性や所在地の審査は行いません。

DV 証明書は SSL/TLS 証明書市場の約 80% を占めています（2024 年時点）。Let’s Encrypt が ACME プロトコル（RFC 8555、2019 年）による自動発行を実現したことで、DV 証明書の普及が加速しました。Let’s Encrypt は 2016 年のサービス開始以降、累計数十億枚の DV 証明書を発行しています。

DV 証明書の暗号化強度は OV 証明書や EV 証明書と同等です。証明書の検証レベルが異なるだけで、TLS ハンドシェイクで確立される暗号化通信の安全性に差はありません。ただし DV 証明書には組織名が含まれないため、通信相手が正当な企業であることの証明にはなりません。

仕組み

DV 証明書はドメイン管理権限の確認だけで発行され、ACME プロトコルによって鍵生成から取得まで自動化できます。

検証方法

DV 証明書の発行には、申請者がドメインを管理していることの証明が必要です。CA/Browser Forum の Baseline Requirements では複数の検証方法が認められています。

HTTP-01 検証は、認証局が指定したファイルを http://example.com/.well-known/acme-challenge/ に配置する方法です。認証局がその URL にアクセスし、ファイルの内容を確認することでドメインの管理権限を検証します。ウェブサーバーにアクセスできる環境で最も手軽な方法ですが、ワイルドカード証明書の取得には使えません。

DNS-01 検証は、_acme-challenge.example.com に認証局が指定した値の TXT レコードを設定する方法です。DNS を操作できることがドメイン管理権限の証明になります。ワイルドカード証明書の発行にはこの方法が必須です。

TLS-ALPN-01 検証は、対象ドメインのポート 443 で TLS ハンドシェイク中に ALPN 拡張を使って検証トークンを提示する方法です。HTTP-01 がポート 80 を使うのに対し、TLS-ALPN-01 はポート 443 のみで完結します。CDN 経由の環境でポート 80 が使えない場合に有用です。

メールベースの検証は、ドメインの管理者メールアドレス（admin@example.com、postmaster@example.com など）に確認メールを送る方法です。CA/Browser Forum の Ballot SC-090 でメールベースの検証方法は段階的に廃止される方向で議論が進んでいます。

ACME プロトコルによる自動化

ACME（Automatic Certificate Management Environment）は、RFC 8555 で標準化された証明書発行の自動化プロトコルです。クライアント（certbot や acme.sh など）と認証局の間で、アカウント登録、ドメイン検証、証明書発行、失効のすべてを API 経由で処理します。

ACME の処理フローは次の通りです。

1. クライアントが認証局に対して証明書発行リクエスト（Order）を作成する
2. 認証局がドメインごとに検証チャレンジ（Authorization）を返す
3. クライアントが HTTP-01、DNS-01、または TLS-ALPN-01 のいずれかのチャレンジに応答する
4. 認証局がチャレンジを検証し、成功すれば CSR（Certificate Signing Request）を受け付ける
5. 認証局が証明書を発行し、クライアントがダウンロードする

Let’s Encrypt は ACMEv2 API のみをサポートしています（ACMEv1 は 2021 年 6 月に廃止）。

DV・OV・EV の違い

SSL/TLS 証明書は検証レベルによって 3 種類に分類されます。

項目	DV	OV	EV
ドメイン管理権限の確認	あり	あり	あり
組織の実在確認	なし	あり	あり（厳格）
証明書への組織名記載	なし	あり	あり
発行所要時間	数分	数日	数週間
費用	無料〜数千円	数万円	十万円以上
市場シェア（2024 年）	約 80%	約 15-18%	約 2-5%

ブラウザーのアドレスバー表示に関しては、かつて EV 証明書では組織名が緑色で表示されていましたが、Chrome と Firefox は 2019 年にこの表示を廃止しました。現在はどの検証レベルの証明書でもアドレスバーの見た目は同じです。組織情報を確認するには、証明書の詳細を開く必要があります。

有効期間の短縮

CA/Browser Forum は 2025 年 4 月に Ballot SC-081v3 を可決し、SSL/TLS 証明書の有効期間を段階的に短縮する方針を決定しました。Apple、Google、Mozilla、Microsoft の 4 ブラウザーベンダーと 25 の認証局が賛成票を投じています。

• 2026 年 3 月 15 日以降: 最長 200 日
• 2027 年 3 月 15 日以降: 最長 100 日
• 2029 年 3 月 15 日以降: 最長 47 日

有効期間が 47 日になると、手動での証明書管理は現実的ではなくなります。DV 証明書と ACME プロトコルによる自動更新が事実上の必須要件になります。OV 証明書や EV 証明書も同じ有効期間制限を受けますが、手動の組織審査を含む発行プロセスとの整合性が課題になっています。

設定例

Let’s Encrypt（certbot / acme.sh）による DV 証明書の取得と自動更新の設定を示します。

Let’s Encrypt で DV 証明書を取得

certbot を使って DV 証明書を取得する例です。

# HTTP-01 検証で取得（webroot 方式）
certbot certonly --webroot -w /var/www/html -d example.com -d www.example.com

# DNS-01 検証で取得（ワイルドカード証明書）
certbot certonly --manual --preferred-challenges dns -d "*.example.com" -d example.com

acme.sh を使う場合は次の通りです。

# Cloudflare DNS API を使った自動 DNS-01 検証
export CF_Token="your-cloudflare-api-token"
acme.sh --issue --dns dns_cf -d example.com -d "*.example.com"

自動更新の設定

Let’s Encrypt の証明書は 90 日間 有効で、残り 30 日 を切ると更新可能になります。certbot は cron または systemd timer で自動更新を設定します。

# 更新テスト
certbot renew --dry-run

# cron による自動更新（1日2回チェック）
echo "0 0,12 * * * root certbot renew --quiet --deploy-hook 'systemctl reload nginx'" | sudo tee /etc/cron.d/certbot

証明書ファイルが更新されても、ウェブサーバーが再読み込みされなければ古い証明書を返し続けます。--deploy-hook で nginx のリロードを必ず設定してください。

CAA レコードによる発行元の制限

DV 証明書はドメイン管理権限だけで発行されるため、CAA レコードで発行元の認証局を制限しておくことが推奨されます。

example.com.  IN  CAA  0 issue "letsencrypt.org"
example.com.  IN  CAA  0 issuewild "letsencrypt.org"

確認方法

openssl でサーバー証明書が DV か OV か EV かを確認するには、証明書の Subject フィールドと Policy OID を見ます。

# Subject フィールドを確認（DV 証明書には O= がない）
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -subject

DV 証明書の出力例です。

subject=CN = example.com

DV 証明書の場合、Subject フィールドに O=（Organization）が含まれず、CN=example.com のようにドメイン名だけが記載されます。

# 証明書ポリシーを確認
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -text | grep -A2 "Certificate Policies"

X509v3 Certificate Policies:
    Policy: 2.23.140.1.2.1

OV/EV 証明書では O=Example Inc. のように組織名が含まれます。

証明書ポリシーの OID でも判別できます。

• DV: 2.23.140.1.2.1（CA/Browser Forum が定義した DV 証明書の OID）
• OV: 2.23.140.1.2.2
• EV: 2.23.140.1.1

外部の視点からも確認したい場合は、Labee Dev Toolbox の SSL Cert API を使うと、外部の視点から見た結果を取得できます。

curl "https://labee.dev/api/ssl-cert?hostname=example.com"

{
  "success": true,
  "data": {
    "hostname": "example.com",
    "port": 443,
    "reachable": true,
    "status": 200
  },
  "error": null,
  "meta": { "responseTime": 123 }
}

data.reachable が true であれば、外部の環境から HTTPS 接続が成立しています。DV 証明書であっても OV/EV 証明書であっても、正しく設定されていればこのチェックは通過します。false の場合は証明書の期限切れやチェーンの不備など、設定に問題がある可能性があります。

よくある問題

DV 証明書はドメイン管理権限のみで発行されるため、悪用や自動更新の設定ミスに起因するトラブルが起きやすいです。

DV 証明書でフィッシングサイトが作られる

DV 証明書はドメインの管理権限だけで発行されるため、攻撃者が紛らわしいドメイン（examp1e.com など）を取得し、正規の DV 証明書を取得してフィッシングサイトに使うケースがあります。アドレスバーの鍵マークは通信が暗号化されていることだけを示しており、接続先が正当な組織であることの証明にはなりません。

Google Safe Browsing や Microsoft SmartScreen などのブラウザー保護機能、および Certificate Transparency ログによる監視が、DV 証明書を悪用したフィッシングへの対抗手段になっています。

自動更新の失敗に気づかない

Let’s Encrypt の証明書は 90 日有効です。自動更新の cron ジョブが停止していたり、DNS 設定の変更で DNS-01 検証が通らなくなったりすると、証明書が期限切れになります。certbot は更新失敗時にメール通知を送りますが、Let’s Encrypt アカウントに登録したメールアドレスが無効になっていると通知が届きません。

自動更新の動作確認には certbot renew --dry-run を定期的に実行するか、外部の監視サービスで証明書の有効期限を監視します。

HTTP-01 検証がリバースプロキシで失敗する

リバースプロキシ（nginx、Cloudflare など）の背後にあるサーバーで HTTP-01 検証を使う場合、/.well-known/acme-challenge/ へのリクエストがバックエンドに到達しないことがあります。リバースプロキシの設定で該当パスをバックエンドに転送するか、DNS-01 検証に切り替える必要があります。

# nginx でチャレンジパスを certbot のディレクトリに転送
location /.well-known/acme-challenge/ {
    root /var/www/html;
}

ワイルドカード証明書が HTTP-01 で取得できない

ワイルドカード証明書（*.example.com）の発行には DNS-01 検証が必須です。HTTP-01 や TLS-ALPN-01 では取得できません。DNS プロバイダーの API に対応した certbot プラグイン（certbot-dns-cloudflare、certbot-dns-route53 など）を使うと、DNS-01 検証を自動化できます。

CAA レコードが未設定で意図しない認証局から発行される

CAA レコードが設定されていないドメインには、どの認証局でも証明書を発行できます。CDN プロバイダーやホスティングサービスが独自に証明書を発行する場合もあります。CAA レコードを設定して、証明書を発行できる認証局を明示的に制限することを推奨します。