はじめに
サーバー証明書には DV / OV / EV の3種類がある。
名前が違うのは知っていても、「具体的に何が違うのか」を説明しようとすると意外と言葉に詰まる。
この記事のゴールは、3つの違いを正確に説明できるようになることである。
やり方はシンプルで、実物の証明書を3枚並べる。DV・OV・EV それぞれの実例を openssl で取ってきて、Subject を見比べる。
結論を先に書くとこうなる。
3つの違いは「CA が何を確認したか」の違いであり、
それは Subject フィールドの増え方としてそのまま見える。
👉 暗号の強さは関係ない。これも実データで確認する。
なお本記事の値はすべて 2026-08-02 時点で実際に取得したものである。証明書は更新されるので、読者が同じコマンドを実行すると値は変わる。
まず3枚並べてみる
説明の前に、現物を見てもらったほうが早い。
証明書はこのコマンドで取れる。
echo | openssl s_client -connect github.com:443 -servername github.com 2>/dev/null \
| openssl x509 -noout -subject
3サイトで実行した結果がこれ。
DV — github.com
subject=CN = github.com
OV — www.nttdocomo.co.jp
subject=C = JP, ST = Tokyo, L = Chiyoda-ku, O = "NTT DOCOMO, INC.", CN = www.nttdocomo.co.jp
EV — www.mufg.jp
subject=jurisdictionC = JP, serialNumber = 0100-01-073486, businessCategory = Private Organization, C = JP, ST = Tokyo, L = Chiyoda Ku, O = "Mitsubishi UFJ Financial Group, Inc.", CN = www.mufg.jp
同じ「サーバー証明書」なのに、入っている情報の量がまるで違う。
👉 この3サイトは「3種類の実例としてたまたま観測された」だけである。どの種類を使っているかで優劣がつくものではない。
増えたフィールドが審査内容そのもの
3枚を並べ直すと、下に行くほどフィールドが増えているだけだと分かる。
DV CN
↓ ＋ 組織の情報
OV CN C ST L O
↓ ＋ 法人の情報
EV CN C ST L O jurisdictionC serialNumber businessCategory
| Subject に含まれるもの | |
|---|---|
| DV |
CN のみ |
| OV |
CN + O + C + ST + L
|
| EV | OV のすべて + jurisdictionC + serialNumber + businessCategory
|
ここが記事の核心になる。
増えたフィールドは、CA が追加で確認した事実そのものである。
CA は確認していないことを証明書に書けない。逆に言えば、書いてある項目は確認済みだと保証していることになる。
だから「DV/OV/EV の違いは何か」という問いは、「CA がどこまで確認したか」という問いと同じである。
以降、3種類を順に見ていく。
DV：ドメインの支配権だけ
DV（Domain Validation）が確認するのは1点だけ。
「申請者がそのドメインを支配しているか」
CA/Browser Forum は DV をこう定義している。
2.23.140.1.2.1 No entity identity asserted
No entity identity asserted ——実体の同一性については何も主張しない。
これが github.com の Subject が CN = github.com だけである理由である。ドメイン名しか確認していないのだから、ドメイン名しか書けない。
❌ DV は暗号が弱い、安全でない
✅ DV は組織について何も言っていないだけ
暗号については後の章で見るが、DV でも通信は同じように暗号化される。DV に無いのは「誰が運営しているか」の情報である。
👉 では「ドメインを支配している」をどうやって証明するのか。Web サーバーにファイルを置く、DNS にレコードを書く、といった方式があり、Let's Encrypt などが使う ACME というプロトコルで自動化されている。この部分は別記事に書いた。
OV：組織の実在を確認する
OV（Organization Validation）は、DV の確認に加えて組織が実在することを確認する。
CA/Browser Forum の定義はこう。
2.23.140.1.2.2 Organization identity asserted
DV の No entity identity asserted と正反対で、実体について主張する。
その主張が Subject に現れる。
subject=C = JP, ST = Tokyo, L = Chiyoda-ku, O = "NTT DOCOMO, INC.", CN = www.nttdocomo.co.jp
| フィールド | 実測値 | 意味 |
|---|---|---|
O |
NTT DOCOMO, INC. |
Organization。組織名 |
C |
JP |
Country。国 |
ST |
Tokyo |
State/Province。都道府県 |
L |
Chiyoda-ku |
Locality。市区町村 |
組織名と所在地が入る。つまり CA は「この名前の組織が、この場所に実在する」ことを確認したうえで発行している。
👉 発行元を見ると、CA 側の作りも見えてくる。
DV issuer=C = GB, O = Sectigo Limited, CN = Sectigo Public Server Authentication CA DV E36
OV issuer=C = BE, O = GlobalSign nv-sa, CN = GlobalSign RSA OV SSL CA 2018
EV issuer=C = JP, O = "Cybertrust Japan Co., Ltd.", CN = Cybertrust Japan SureServer EV CA G3
CA 名にそれぞれ DV OV EV と入っている。この3枚では、CA が検証レベルごとに発行用の中間証明書を分けていた。（ただし必ずそうとは限らないので、判定には次章の OID を使う。）
EV：法人そのものを特定する
EV（Extended Validation）になると、さらに3つのフィールドが増える。
subject=jurisdictionC = JP, serialNumber = 0100-01-073486, businessCategory = Private Organization, C = JP, ST = Tokyo, L = Chiyoda Ku, O = "Mitsubishi UFJ Financial Group, Inc.", CN = www.mufg.jp
OV との差分はこの3つ。
| フィールド | 実測値 | 指しているもの |
|---|---|---|
jurisdictionC |
JP |
どの国の法制度で登記されているか |
businessCategory |
Private Organization |
法人の種別 |
serialNumber |
0100-01-073486 |
登記上の識別番号 |
OV が「組織が実在する」だったのに対し、EV はどの法人なのかを特定する方向に進んでいる。所在地ではなく、法制度上の識別子で指している。
シリアル番号が2つある
ここは間違えやすい。同じ証明書の中に「シリアル番号」が2つ出てくる。
証明書のシリアル番号 serial=778A4FF528B6D5D2AB0653CC3326EBF0C7AC4289
subject の serialNumber serialNumber = 0100-01-073486
まったくの別物である。
| 何の番号か | |
|---|---|
証明書の serial
|
その証明書1枚を識別する番号 |
subject の serialNumber
|
証明書の持ち主である法人の識別番号 |
👉 subject の serialNumber は証明書の話ではなく、法人の話である。EV でだけ現れるのはそのため。
ポリシー OID で機械的に判別する
Subject を目で見れば大体分かるが、判別を自動化したいなら証明書ポリシーの OID を見るのが確実である。
CA/Browser Forum が種別ごとに OID を予約している。
| OID | 意味 |
|---|---|
2.23.140.1.1 |
EV |
2.23.140.1.2.1 |
DV（No entity identity asserted） |
2.23.140.1.2.2 |
OV（Organization identity asserted） |
2.23.140.1.2.3 |
IV（Individual identity asserted） |
出典：CA/Browser Forum Object Registry
証明書に入っている OID を全部出すとこうなる。
echo | openssl s_client -connect github.com:443 -servername github.com 2>/dev/null \
| openssl x509 -noout -text \
| awk '/X509v3 Certificate Policies/,/X509v3 (CRL|Basic|Subject Alt)|Signature Algorithm/' \
| grep -oE 'Policy: [0-9.]+'
3サイトの結果がこれ。
github.com Policy: 1.3.6.1.4.1.6449.1.2.2.7
Policy: 2.23.140.1.2.1
www.nttdocomo.co.jp Policy: 1.3.6.1.4.1.4146.1.20
Policy: 2.23.140.1.2.2
www.mufg.jp Policy: 2.23.140.1.1
Policy: 1.2.392.200091.100.721.1
Policy: 1.2.392.200081.1.22.1
OID が複数入っている。 ここが引っかかりやすい。
-
2.23.140.*… CA/Browser Forum 共通のもの - それ以外 … CA が独自に定義したもの（Sectigo・GlobalSign・Cybertrust でそれぞれ違う）
❌ 最初に出てきた OID を見て判定する
✅ 2.23.140.* を探して判定する
CA 独自の OID は CA ごとにバラバラなので判定には使えない。そもそも付いていない場合もある。Let's Encrypt の証明書は共通 OID しか持っていなかった。
letsencrypt.org Policy: 2.23.140.1.2.1
判定はこれで足りる。
echo | openssl s_client -connect github.com:443 -servername github.com 2>/dev/null \
| openssl x509 -noout -text \
| grep -oE '2\.23\.140\.1\.(1|2\.[123])' | head -1
3サイトで実行した結果。
github.com 2.23.140.1.2.1
www.nttdocomo.co.jp 2.23.140.1.2.2
www.mufg.jp 2.23.140.1.1
Subject から受ける印象と一致する。
暗号強度は検証レベルと無関係
「EV は最上位だから暗号も強いのだろう」と思いがちだが、これは成り立たない。
3枚の鍵と署名アルゴリズムを並べる。
| 検証レベル | 公開鍵 | 署名アルゴリズム | |
|---|---|---|---|
| github.com | DV | ECDSA 256bit | ecdsa-with-SHA256 |
| www.nttdocomo.co.jp | OV | RSA 2048bit | sha256WithRSAEncryption |
| www.mufg.jp | EV | RSA 2048bit | sha256WithRSAEncryption |
この3枚では、検証レベルが最も低い DV が最も新しいアルゴリズムを使っていた。
ECDSA は RSA より短い鍵で同等以上の強度が得られる方式で、RSA 2048bit より現代的な選択である。検証レベルが最上位の EV が RSA 2048bit なのだから、検証レベルと暗号強度は連動していない。
❌ EV にすると通信がより強く暗号化される
✅ 検証レベルと暗号強度は別の軸
考えてみれば当然で、DV/OV/EV が決めているのは「CA が発行前に何を確認したか」であって、鍵の種類ではない。鍵は申請する側が用意する。
👉 有効期限もバラバラだった。この3枚では github.com が約89日、www.nttdocomo.co.jp が約232日、www.mufg.jp が約379日。検証レベルとの相関はこの3件からは読み取れない。
ブラウザ表示はどう変わったか
かつて EV 証明書のサイトを開くと、アドレスバーに組織名が表示された。「EV なら緑になる」という説明を見た記憶がある人もいると思う。
現在は表示されない。 Chrome と Firefox が2019年に廃止した。
| ブラウザ | バージョン | 時期 | 変更内容 |
|---|---|---|---|
| Chrome | 77 | 2019-08-09 告知 | アドレスバーの EV バッジを削除し、Page Info（鍵アイコン）へ移動 |
| Firefox | 70 | 2019-10-15 | アドレスバーの EV 表示を削除し、Site Information パネル（鍵アイコン）へ移動 |
理由も公表されている。
Chrome：
the EV UI does not protect users as intended
Mozilla：
the display of the company name and country in the URL bar when the website is using an Extended Validation TLS certificate does not add any additional security parameters
どちらも「アドレスバーに出しても、意図したようにユーザーを守れていない」という趣旨である。
情報が消えたわけではない。鍵アイコンをクリックすれば今も組織名は確認できる。目立つ場所から、探さないと見えない場所へ移ったということである。
❌ EV 証明書を入れるとアドレスバーが緑になる
✅ 2019年以降、Chrome・Firefox のアドレスバーでは DV/OV/EV を区別しない
で、どれを選ぶのか
ここまでで分かったことを整理する。判断材料として並べるが、どれを選ぶべきかは用途と要件によるので、ここでは決めない。
| DV | OV | EV | |
|---|---|---|---|
| CA が確認すること | ドメインの支配権 | ＋ 組織の実在 | ＋ 法人の特定 |
| Subject の情報量 |
CN のみ |
組織名・所在地 | 法人の識別情報 |
| CA/B Forum の OID | 2.23.140.1.2.1 |
2.23.140.1.2.2 |
2.23.140.1.1 |
| 通信の暗号化 | 検証レベルとは無関係 | 同左 | 同左 |
| アドレスバーの表示 | 区別なし | 区別なし | 区別なし（2019年〜） |
判断に効きそうな観点を挙げておく。
- 一般利用者がアドレスバーで見分けることは、現在はできない。 エンドユーザーへの訴求を期待していた場合、期待どおりの効果は得られない可能性が高い
-
一方で、証明書の中身は今でも誰でも読める。 この記事でやったように
opensslで確認できるし、鍵アイコンからも見られる - 要件で指定される場合がある。 取引先や業界のルールで OV 以上を求められることがあり、その場合は選択の余地がない
- 運用の手間が違う。 DV はドメインの支配権だけで確認が完結するので自動化しやすい。組織の確認を伴うものは、その分の手続きが発生する
👉 「EV は無意味になった」とまでは言えない。ブラウザがアドレスバーでの表示をやめたのは事実だが、それは「用途が無くなった」とは別の話である。この記事で確認できたのはブラウザの表示が変わったという事実までで、EV の価値そのものを検証したわけではない。
まとめ
サーバー証明書の DV / OV / EV の違いを、実物を並べて確認した。
DV CN のみ CA はドメインの支配権だけ確認した
OV ＋ 組織名・所在地 CA は組織の実在も確認した
EV ＋ 法人の識別情報 CA は法人を特定できるところまで確認した
要点はこの5つ。
- 増えたフィールドが、CA が追加で確認した事実そのもの
- CA/Browser Forum の定義では DV は
No entity identity asserted（実体について何も主張しない） - 判別は
2.23.140.*の OID で機械的にできる。CA 独自の OID は判定に使えない - 暗号強度は検証レベルと無関係。 実際 DV の github.com が最も新しいアルゴリズムだった
- アドレスバーでの EV 表示は Chrome 77 / Firefox 70（2019年）で廃止された
証明書の種類が気になったら、自分で確認できる。
echo | openssl s_client -connect ドメイン名:443 -servername ドメイン名 2>/dev/null \
| openssl x509 -noout -subject -issuer
👉 本記事の値は 2026-08-02 時点のものである。証明書は更新されるので、同じコマンドを実行しても値は変わる。