EV 証明書（Extended Validation）

概要

EV 証明書（Extended Validation） は、認証局（CA）が法人の実在性・所在地・事業内容を厳格に審査した上で発行する、最も検証レベルの高い SSL/TLS 証明書です。CA/Browser Forum が策定した「EV SSL Certificate Guidelines」で審査基準が規定されており、初版は 2007 年に公開されました。

EV 証明書の暗号化強度は DV 証明書や OV 証明書と同等です。TLS ハンドシェイクで確立される暗号化通信の安全性に差はありません。EV 証明書の価値は「この証明書の所有者は、実在する特定の法人である」ことを第三者（CA）が保証する点にあります。

かつて Chrome と Firefox はアドレスバーに組織名を緑色で表示していましたが、2019 年に Chrome 77 と Firefox 70 でこの表示が廃止されました。現在は証明書の詳細を開いたときのみ組織情報を確認できます。Google のリサーチチームは、アドレスバーの組織名表示がフィッシング対策として有効ではなかったと報告しています。

仕組み

EV 証明書は CA/Browser Forum の厳格な審査基準と、証明書に埋め込まれるポリシー OID・Subject フィールドによって DV/OV 証明書と区別されます。

審査プロセス

EV 証明書の発行には、CA/Browser Forum の EV Guidelines に基づく審査が必要です。DV 証明書のドメイン管理権限確認に加えて、次の項目が審査されます。

1. 法人の実在確認 — 登記簿、商業登記、または政府の公式データベースで法人の存在を確認する
2. 物理的な所在地の確認 — 法人の住所が実在し、事業活動が行われていることを確認する。登記住所と実際の事業所が異なる場合、両方の確認が求められる
3. 電話番号の確認 — 第三者のディレクトリ（電話帳）に掲載された番号で法人に連絡し、申請の真正性を確認する
4. ドメイン管理権限の確認 — DV 証明書と同じく、DNS-01 や HTTP-01 などの検証を行う
5. 申請者の権限確認 — 証明書を申請した担当者が法人を代表する権限を持つことを確認する

審査には通常 1〜2 週間かかります。Let’s Encrypt のような自動発行には対応しておらず、手動の審査が介在します。

証明書ポリシー OID

EV 証明書には、CA/Browser Forum が定義した証明書ポリシー OID 2.23.140.1.1 が含まれます。ブラウザーはこの OID を確認して EV 証明書であると判断します。

X509v3 Certificate Policies:
    Policy: 2.23.140.1.1

DV 証明書は 2.23.140.1.2.1、OV 証明書は 2.23.140.1.2.2 です。

Subject フィールドの違い

EV 証明書の Subject フィールドには組織名、所在地、法人の管轄区域が含まれます。

subject=businessCategory = Private Organization, serialNumber = 12345678,
        jurisdictionC = JP, C = JP, ST = Tokyo, L = Shibuya,
        O = Example Inc., CN = example.com

DV 証明書は CN = example.com のみです。OV 証明書は O = Example Inc. と CN = example.com を含みますが、businessCategory や jurisdictionC は含まれません。

設定例

EV 証明書の取得は CA のウェブポータルから申請します。自動化プロトコル（ACME）には対応していません。

CSR の生成

openssl req -new -newkey rsa:2048 -nodes -keyout example.com.key -out example.com.csr -subj "/C=JP/ST=Tokyo/L=Shibuya/O=Example Inc./CN=example.com"

CSR（Certificate Signing Request）に組織情報を含めます。CA は CSR の内容を審査時に確認しますが、最終的な証明書の Subject フィールドは CA が審査結果に基づいて決定します。

Nginx での設定

EV 証明書の設定方法は DV 証明書や OV 証明書と同じです。

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate     /etc/ssl/example.com/fullchain.pem;
    ssl_certificate_key /etc/ssl/example.com/privkey.key;
    ssl_protocols TLSv1.2 TLSv1.3;
}

fullchain.pem にはサーバー証明書と中間証明書を含めます。EV 証明書でも証明書チェーンの設定は同一です。

確認方法

openssl でサーバー証明書が EV かどうかを確認するには、証明書ポリシーの OID を確認します。

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.1

OID 2.23.140.1.1 が含まれていれば EV 証明書です。Subject の組織情報も確認できます。

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -subject

subject=businessCategory = Private Organization, serialNumber = 12345678,
        jurisdictionC = JP, C = JP, ST = Tokyo, L = Shibuya,
        O = Example Inc., CN = example.com

外部の視点からも確認したい場合は、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 接続が成立しています。EV 証明書であっても DV 証明書であっても、正しく設定されていればこのチェックは通過します。

よくある問題

EV 証明書の運用では、ブラウザーの表示仕様変更や有効期間の短縮、中間証明書の設定漏れが代表的なトラブルの原因です。

アドレスバーに組織名が表示されない

2019 年に Chrome 77 と Firefox 70 がアドレスバーの EV 表示を廃止しました。Safari も macOS Monterey 以降は従来の緑色表示を行いません。EV 証明書の組織情報を確認するには、ブラウザーの証明書ビューアーを開く必要があります。「EV 証明書を導入したのにアドレスバーが変わらない」という問い合わせはこの仕様変更が原因です。

有効期間の短縮と手動審査のコスト

CA/Browser Forum の Ballot SC-081v3 により、2029 年 3 月 15 日以降は証明書の最長有効期間が 47 日になります。EV 証明書は手動審査が必要なため、47 日ごとの再審査は運用負荷が大きくなります。CA 各社がどのように審査プロセスを短縮するかはまだ確定していません。

中間証明書の設定漏れ

EV 証明書でも中間証明書の設定漏れは発生します。CA から受け取った証明書ファイルにサーバー証明書しか含まれておらず、中間証明書を別途ダウンロードする必要があるケースがあります。fullchain.pem 相当のファイルが提供されない場合、CA のリポジトリから中間証明書を取得してサーバー証明書と結合します。

EV 証明書でもフィッシングは防げない

EV 証明書は法人の実在を証明しますが、その法人が善意かどうかは証明しません。実在するペーパーカンパニーが EV 証明書を取得してフィッシングサイトを運営した事例が報告されています。Certificate Transparency ログによる監視と、Google Safe Browsing などのブラウザー保護機能が対策の柱になります。