SSL 証明書の選び方ガイド — DV が標準、OV・EV はほぼ不要な時代
SSL 証明書を選ぶとき「DV・OV・EV のどれにすべきか」と悩む記事を見かけますが、2026 年現在、ほとんどのケースで答えは決まっています。DV 証明書を選んでください。暗号化の強度は DV・OV・EV で差がなく、ブラウザーのアドレスバー表示にも違いはありません。OV・EV が必要になるのは、規制やコンプライアンス要件が明示的に求めている場合だけです。
このガイドでは、証明書の認証レベルとドメインカバー方式の選び方を整理し、外部からの確認方法と無料 DV 証明書の運用ポイントを順番に説明します。
example.com の部分は実際のドメイン名に置き換えてください。
flowchart TD
A["SSL 証明書を選ぶ"] --> B{"規制・契約で\nOV / EV が\n指定されている?"}
B -->|いいえ| C["DV 証明書\n(ACME 対応 CA / マネージド SSL)"]
B -->|はい| D{"どちらが\n指定されている?"}
D -->|OV| E["OV 証明書\n(商用 CA から購入)"]
D -->|EV| F["EV 証明書\n(商用 CA から購入)"]
C --> G["ドメインカバー方式を選ぶ\n(Step 2 へ)"]
E --> G
F --> G
チェックリスト一括コピー用
以下をコピーして手元のメモやIssueに貼り付ければ、そのまま確認リストとして使えます。
## SSL 証明書の選び方チェックリスト
### DV 証明書を選定する
- [ ] ACME 対応 CA(Let's Encrypt など)またはマネージド SSL で DV 証明書を取得する
- `openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -text | grep -A1 "Certificate Policies"`
- [ ] 特定の規制・契約で OV / EV が求められていないことを確認した
### ドメインカバー方式を選定する
- [ ] 必要なドメイン / サブドメインをすべてリストアップした
- [ ] シングルドメイン / ワイルドカード / SAN のどれが最適か判断した
- [ ] 証明書の SAN フィールドにすべての対象ドメインが含まれている
- `openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -ext subjectAltName`
### 外部から証明書を確認する
- [ ] 証明書の有効期限と更新方法を把握した
- [ ] 外部から HTTPS 接続が正常にできることを確認した
### DV 証明書の運用
- [ ] 自動更新の仕組みを構築した(マネージド SSL / ACME クライアント等)
- [ ] 更新失敗時の通知を設定した(自己管理の場合)
### 一括確認(API)
- `curl "https://labee.dev/api/ssl-cert?hostname=example.com"`
Step 1 DV 証明書を選ぶ(ほぼすべてのケースで正解)
SSL 証明書には DV(Domain Validation)・OV(Organization Validation)・EV(Extended Validation)の 3 つの認証レベルがあります。これらの違いは「認証局が申請者をどこまで審査するか」であり、暗号化の強度は同じです。TLS 1.3 で接続すれば、DV でも EV でも同一の暗号スイートが使われます。
結論として、DV 証明書がほぼすべてのケースで正解です。その理由は 3 つあります。
Let’s Encrypt をはじめとする ACME 対応 CA(ZeroSSL、Buypass、Google Trust Services など)が無料の DV 証明書を自動発行しており、SSL 証明書の大多数を DV 証明書が占めています。さらに、AWS ACM、Vercel、Netlify、Fly.io などのマネージドプラットフォームは DV 証明書の発行と更新を自動で処理するため、利用者が ACME クライアントを直接操作する必要すらありません。DNS レコード認証・HTTP ファイル認証・メール認証のいずれかでドメインの管理権限を確認すれば、数秒で発行が完了します。
ブラウザーのアドレスバーで DV と OV・EV の区別はできません。かつて EV 証明書を導入するとアドレスバーが緑色になり組織名が表示されましたが、Chrome 77(2019 年 9 月)と Firefox 70(2019 年 10 月)でこの表示は廃止されました。2026 年現在、どのモダンブラウザーも DV・OV・EV を外見上区別しません。
EV 証明書が「信頼性を担保する」という主張は否定されています。フィッシングサイトが EV 証明書を取得した事例は複数報告されており、ユーザーが EV インジケーターに気づかないことも学術研究で示されています。EV の存在は詐欺防止に寄与しません。
用語解説DV 証明書(Domain Validation)ドメインの管理権限のみを確認して発行される SSL/TLS 証明書。Let's Encrypt で無料取得でき、個人サイトや API に適する。チェック項目
- ACME 対応 CA(Let’s Encrypt など)またはマネージド SSL で DV 証明書を取得する
- 特定の規制・契約で OV / EV が求められていないことを確認した
確認コマンド
証明書の認証レベルは、Certificate Policies フィールドの OID で判定できます。
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -text | grep -A1 "Certificate Policies"
X509v3 Certificate Policies:
Policy: 2.23.140.1.2.1
OID の意味は以下の通りです。
2.23.140.1.2.1— DV 証明書2.23.140.1.2.2— OV 証明書2.23.140.1.1— EV 証明書
これらの OID は CA/Browser Forum の Baseline Requirements と EV Guidelines で定義されています。
labee.dev の API では、対象ホストへの HTTPS 到達性を確認できます。
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": 142 }
}
data.reachable が true であれば、そのホストに HTTPS で正常に接続できています。証明書の詳細(認証レベルや有効期限)は openssl コマンドで確認してください。
Step 2 ドメインカバー方式を選ぶ(シングル / ワイルドカード / SAN)
認証レベルとは別に、1 枚の証明書でどの範囲のドメインをカバーするかを選ぶ必要があります。
シングルドメイン証明書
1 つの FQDN(例: www.example.com)だけをカバーします。最もシンプルです。小規模なサイトで、サブドメインをほとんど使わない場合に適しています。
ワイルドカード証明書
*.example.com の形式で、同一階層のサブドメインをすべてカバーします。www.example.com、api.example.com、app.example.com を 1 枚で保護できます。ただし *.sub.example.com のような 2 階層以上のサブドメインはカバーしません。
ワイルドカード証明書の発行には DNS-01 チャレンジが必要です。HTTP-01 チャレンジでは発行できません。Let’s Encrypt をはじめとする ACME 対応 CA でワイルドカード証明書を取得するには、_acme-challenge.example.com の TXT レコードを DNS に登録する必要があります。AWS ACM や Vercel などのマネージドサービスではこの手順が自動化されています。
SAN 証明書(マルチドメイン証明書)
SAN(Subject Alternative Name)フィールドに複数のドメイン名を記載し、異なるドメインを 1 枚の証明書でカバーします。example.com、example.net、example.jp のように、まったく別のドメインを束ねられる点がワイルドカードとの違いです。
Let’s Encrypt などの ACME 対応 CA では、ACME クライアントの -d オプションで複数ドメインを指定するだけで SAN 証明書を取得できます。Let’s Encrypt の場合、1 枚あたり最大 100ドメイン まで含められます。
チェック項目
- 必要なドメイン / サブドメインをすべてリストアップした
- シングルドメイン / ワイルドカード / SAN のどれが最適か判断した
- 証明書の SAN フィールドにすべての対象ドメインが含まれている
確認コマンド
現在の証明書がカバーしているドメインは、SAN フィールドで確認できます。
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -ext subjectAltName
X509v3 Subject Alternative Name:
DNS:example.com, DNS:www.example.com
ワイルドカード証明書の場合は DNS:*.example.com と表示されます。SAN 証明書の場合は複数の DNS エントリーが列挙されます。
Step 3 OV・EV が必要なケースを確認する(ほぼない)
OV・EV 証明書が技術的に優れているわけではありません。暗号化の強度は DV と同一であり、ブラウザーの表示にも差がありません。それでも OV・EV を選ぶ必要があるのは、外部の要件が明示的に求めている場合だけです。
OV が指定されるケース
OV 証明書は、ドメインの管理権限に加えて、申請組織の実在性(法人登記、所在地、電話番号)を認証局が審査します。審査に 1〜3 営業日かかり、証明書の Subject フィールドに組織名(O フィールド)と所在地(L / ST / C フィールド)が記載されます。費用は年額 $50〜$200 程度です。
一部の政府調達要件や業界団体のガイドラインが OV 以上を指定しているケースがあります。ただし、この指定自体が形骸化しつつあるのが実態です。
用語解説OV 証明書(Organization Validation)ドメイン所有権に加えて組織の実在性を認証局が審査して発行する SSL/TLS 証明書。法人サイトの信頼性確保に利用される。EV が指定されるケース
EV 証明書は、CA/Browser Forum の EV SSL Certificate Guidelines に基づき、法人の実在性・所在地・事業内容・申請権限を厳格に審査します。審査には 1〜2 週間かかります。費用は年額 $100〜$500 程度です。
EV を指定する規制は減少傾向にあります。PCI DSS はかつて EV を推奨する記述がありましたが、現行バージョン(v4.0.1)では証明書の種類に関する要件はありません。金融庁のガイドラインにも EV を義務づける規定はありません。契約書や RFP に「EV 証明書を使用すること」と明記されている場合に限り、EV を選択してください。
用語解説EV 証明書(Extended Validation)認証局が法人の実在性・所在地・事業内容を厳格に審査して発行する最高レベルの SSL/TLS 証明書。金融機関や政府機関で採用される。選定マトリクス
| 用途 | 推奨 | カバー方式 | 費用目安(年額) |
|---|---|---|---|
| 個人ブログ・ポートフォリオ | DV | シングルドメイン | 無料(ACME 対応 CA / マネージド SSL) |
| 企業サイト | DV | シングルドメイン | 無料(ACME 対応 CA / マネージド SSL) |
| 企業サイト(複数サブドメイン) | DV | ワイルドカード | 無料(ACME 対応 CA / マネージド SSL) |
| EC サイト・決済ページ | DV | シングルドメイン or SAN | 無料(ACME 対応 CA / マネージド SSL) |
| SaaS(テナントごとのサブドメイン) | DV | ワイルドカード | 無料(ACME 対応 CA / マネージド SSL) |
| 複数ブランドサイト | DV | SAN | 無料(ACME 対応 CA / マネージド SSL) |
| 開発・ステージング環境 | DV | ワイルドカード | 無料(ACME 対応 CA / マネージド SSL) |
| コンプライアンス要件がある場合のみ | OV / EV | 要件に従う | $50〜$500 |
サブドメインが 3 つ以上ある場合は、個別にシングルドメイン証明書を取得するよりもワイルドカード証明書の方が管理面で有利です。異なるドメイン(example.com と example.net など)を束ねたい場合は SAN 証明書を選びます。
Step 4 外部から証明書を確認する
運用中のサイトに対して、外部から証明書の認証レベルとカバー範囲を確認する方法を説明します。
チェック項目
- 証明書の有効期限と更新方法を把握した
- 外部から HTTPS 接続が正常にできることを確認した
確認コマンド
証明書の全体像を確認するコマンドです。
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName -text | grep -E "(Subject:|Issuer:|Not Before|Not After|DNS:|Policy:)"
Subject: CN = example.com
Issuer: C = US, O = Let's Encrypt, CN = R12
Not Before: Mar 15 00:00:00 2026 GMT
Not After : Jun 13 00:00:00 2026 GMT
Policy: 2.23.140.1.2.1
DNS:example.com, DNS:www.example.com
この出力から以下を読み取れます。
- Subject の CN がドメイン名と一致していること
- Issuer が期待する認証局であること(この例では Let’s Encrypt だが、利用する CA によって異なる)
- Not After の日付が十分に先であること
- Policy OID が DV(
2.23.140.1.2.1)であること - DNS エントリーに必要なドメインがすべて含まれていること
labee.dev の API で HTTPS の到達性も確認しておきます。
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": 142 }
}
data.reachable が false の場合、証明書の期限切れやサーバー設定の問題で HTTPS 接続に失敗しています。openssl コマンドでエラーの詳細を確認してください。
Step 5 無料 DV 証明書の運用ポイント
DV 証明書の取得・更新方法は、利用しているインフラによって大きく異なります。
AWS ACM、Vercel、Netlify、Fly.io などのマネージドプラットフォームを利用している場合、証明書の発行と更新はプラットフォーム側で自動的に処理されます。この場合、以下の運用ポイントのほとんどは該当しません。マネージド SSL を利用できる環境であれば、それが最もシンプルな選択肢です。
自分でサーバーを管理している場合(VPS、オンプレミス、Kubernetes など)は、ACME クライアントを使って Let’s Encrypt をはじめとする ACME 対応 CA から証明書を取得・更新します。ACME クライアントとしては certbot、acme.sh、lego のほか、Caddy や Traefik のように ACME を組み込みでサポートする Web サーバー・リバースプロキシーもあります。
有効期間と自動更新
Let’s Encrypt の証明書の有効期間は 90日 です。商用 CA の証明書(有効期間 1 年)と比べて短いため、自動更新の仕組みが必須です。Let’s Encrypt は約 6日間(160時間)の短期証明書オプションの提供も開始しており、今後は 64日(2027年2月〜)、45日(2028年2月〜)と標準の有効期間も段階的に短縮される予定です。
certbot の場合、certbot renew を cron や systemd timer で定期実行します。更新後に Web サーバーの reload が必要です。Caddy や Traefik を使っている場合は、ACME による証明書管理が組み込まれているため追加の設定は不要です。
# certbot の自動更新テスト
certbot renew --dry-run
レート制限
Let’s Encrypt は同一ドメインに対して 1 週間あたり 50枚 の証明書発行という制限があります。大量のサブドメインを個別に発行する場合はワイルドカード証明書で制限を回避できます。ZeroSSL など他の ACME 対応 CA にはそれぞれ独自のレート制限があります。
ワイルドカード証明書と DNS-01 チャレンジ
ワイルドカード証明書の発行には DNS-01 チャレンジが必須です。DNS プロバイダーの API に対応した ACME クライアントを使うか、手動で _acme-challenge.example.com の TXT レコードを更新します。手動更新は有効期間ごとに繰り返す必要があるため、API 連携による自動化を推奨します。
CAA レコード
CAA レコードで利用中の認証局を許可するには、DNS に 0 issue "letsencrypt.org" のように設定します。複数の CA を利用する場合は、CA ごとに CAA レコードを追加してください。CAA レコードが未設定の場合はすべての CA が証明書を発行できますが、意図しない CA からの発行を防ぐために CAA レコードの設定を推奨します。
チェック項目
- 自動更新の仕組みを構築した(マネージド SSL / ACME クライアント等)
- 更新失敗時の通知を設定した(自己管理の場合)
確認コマンド
自動更新が正しく動作しているかを確認するには、証明書の有効期限を定期的にチェックします。マネージド SSL を利用している場合でも、外部からの到達性確認は有効です。
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -dates
notBefore=Mar 15 00:00:00 2026 GMT
notAfter=Jun 13 00:00:00 2026 GMT
notAfter の日付が 30日以内 に迫っている場合は、自動更新が停止している可能性があります。
よくある設定ミス
「EV 証明書の方が安全」という誤解
DV・OV・EV の違いは認証局の審査範囲であり、暗号化の強度には影響しません。EV 証明書を使ってもフィッシング攻撃は防げません。実際にフィッシングサイトが EV 証明書を取得した事例が報告されています。「決済ページだから EV」という判断は技術的根拠がなく、コストだけが増えます。
ワイルドカード証明書でルートドメインが未カバー
*.example.com のワイルドカード証明書は www.example.com や api.example.com をカバーしますが、example.com(ルートドメイン)はカバーしません。ルートドメインにもアクセスする場合は、SAN フィールドに example.com を明示的に追加する必要があります。certbot などの ACME クライアントでは -d example.com -d "*.example.com" と指定します。
中間証明書の設定漏れ
サーバーに証明書をインストールする際、中間証明書(Intermediate CA 証明書)を含めないと、ブラウザーによっては証明書チェーンの検証に失敗します。モバイルブラウザーや古い Android 端末で問題が発生しやすいです。
用語解説証明書チェーン(Certificate Chain)サーバー証明書からルート認証局までの信頼の連鎖を構成する証明書群。チェーンの不備は SSL エラーの主な原因。 用語解説中間認証局(Intermediate CA)ルート認証局とサーバー証明書の間に位置し、証明書チェーンの一部を構成する認証局。サーバー設定時に中間証明書の設置漏れが頻出する。証明書チェーンの構成を確認するには以下のコマンドを使います。
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null | grep -E "s:|i:"
0 s:CN = example.com
i:C = US, O = Let's Encrypt, CN = R12
1 s:C = US, O = Let's Encrypt, CN = R12
i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
s:(Subject)と i:(Issuer)の連鎖が途切れていないことを確認します。番号 0 がサーバー証明書、番号 1 以降が中間証明書です。
自動更新の停止に気づかない
ACME クライアントによる自動更新は、サーバー移行・ファイアウォール変更・DNS プロバイダー変更などで止まることがあります。更新スクリプトが停止しても通知が来ない設定になっていることが多く、有効期限切れで初めて気づくケースが後を絶ちません。AWS ACM や Vercel などのマネージド SSL を利用している場合はこの問題はほぼ発生しませんが、自己管理の環境では CI/CD パイプラインに SSL チェックを組み込むか、labee.dev の 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": 142 }
}
data.reachable が false に変わった場合は、証明書の期限切れや設定の問題が発生しています。
CSR のドメイン名と実際のドメインが不一致
CSR(Certificate Signing Request)を生成する際に指定した CN(Common Name)や SAN が、実際に使用するドメイン名と異なっていると、ブラウザーが証明書エラーを表示します。ACME 対応 CA やマネージド SSL を使う場合は CSR の手動生成が不要ですが、商用 CA で OV / EV 証明書を取得する場合は CN と SAN を慎重に確認してください。
用語解説CSR(Certificate Signing Request)SSL/TLS 証明書の発行を認証局に申請するための署名付きデータ。証明書取得の最初のステップ。発展的なトピック
SSL 証明書の種類と選定方法を理解したら、証明書の運用やセキュリティ強化に関連するトピックも把握しておくと、運用上の判断に役立ちます。
SSL/TLS 証明書
証明書そのものの構造やフォーマットに関する基礎知識です。X.509 形式、PEM / DER エンコーディング、証明書フィールドの意味などを理解しておくと、トラブルシューティング時に役立ちます。
用語解説SSL/TLS 証明書ウェブサイトの通信を暗号化し、サーバーの身元を証明するデジタル証明書。HTTPS 配信の前提条件。ルート CA
ブラウザーやOSに事前に組み込まれている最上位の認証局です。たとえば Let’s Encrypt のルート CA は ISRG Root X1 で、すべてのモダンブラウザーの信頼ストアに含まれています。
用語解説ルート認証局(Root CA)PKI の信頼の起点となる最上位の認証局。OS やブラウザーのトラストストアに格納されている。Certificate Transparency(証明書の透明性)
認証局が発行したすべての証明書を公開ログに記録する仕組みです。不正に発行された証明書や意図しない認証局からの発行を検知できます。
用語解説証明書透明性(Certificate Transparency)CA が発行した証明書をパブリックログに記録し、不正発行を検知可能にする仕組み。Chrome は CT ログ未登録の証明書を拒否する。証明書の有効期間短縮(CA/Browser Forum)
CA/Browser Forum は証明書の最大有効期間を段階的に短縮する決議(SC-081)を採択しました。2026年3月15日から200日、2027年3月15日から100日、2029年3月15日から47日 に短縮されます。有効期間が短くなるほど自動更新の頻度が上がり、手動管理は事実上不可能になります。証明書の選定時点から、自動更新を前提とした設計が必要です。
用語解説証明書の有効期限切れ(Certificate Expiry)SSL/TLS証明書のNotAfterを過ぎた状態。ブラウザーが警告を表示しHTTPS接続が拒否されます。