OV 証明書（Organization Validation）

概要

OV 証明書（Organization Validation） は、ドメインの管理権限に加えて、申請組織の法的実在性を認証局（CA）が審査したうえで発行する SSL/TLS 証明書です。CA/Browser Forum の Baseline Requirements Section 3.2.2 で組織情報の検証要件が規定されています。

DV 証明書がドメインの管理権限だけを確認するのに対し、OV 証明書では認証局が登記簿や第三者データベースを使って組織の名称、所在地、電話番号を調査します。証明書の Subject フィールドに O=（Organization）として組織名が記載されるため、openssl で証明書を確認すれば発行先の組織を特定できます。

発行枚数ベースでは DV 証明書が全体の約 94% を占め、OV 証明書は約 5.5% にとどまります。一方、Web トラフィック量で見ると OV 証明書は全 SSL/TLS トラフィックの約 27% を担っています。企業サイトやサービスサイトなど、組織の信頼性を示す必要があるサイトで採用される傾向があります。

暗号化強度は DV 証明書、OV 証明書、EV 証明書のいずれも同等です。検証レベルの違いは「誰が通信相手であるか」の保証範囲であり、TLS ハンドシェイクで確立される暗号化通信の安全性には影響しません。

仕組み

OV 証明書は DV にない組織審査プロセスを経て発行され、DV・EV との検証レベルの違いが証明書ポリシー OID で識別できます。

組織審査のプロセス

OV 証明書の発行には、ドメイン検証に加えて組織の実在確認が必要です。認証局は CA/Browser Forum の Baseline Requirements に従い、以下の手順で審査を行います。

認証局はまず、申請組織が法的に存在するかを確認します。法人登記簿（日本では法務局の登記情報）、政府のデータベース、または Dun & Bradstreet などの第三者データベースを使って、組織名、登記番号、所在地を照合します。

組織の存在が確認できたら、認証局は申請者が組織を代表する権限を持つかを検証します。登記情報や公開データベースに記載された電話番号に架電し、組織の担当者と直接やり取りして証明書の申請を確認します。メールアドレスだけでは完結せず、電話による本人確認が求められます。

DV 証明書の発行が数分で完了するのに対し、OV 証明書は組織審査に 1 - 3 営業日かかります。審査の過程で追加書類（登記簿謄本、印鑑証明書など）の提出を求められることもあり、その場合はさらに時間がかかります。

DV・OV・EV の違い

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

項目	DV	OV	EV
ドメイン管理権限の確認	あり	あり	あり
組織の実在確認	なし	あり	あり（厳格）
証明書への組織名記載	なし	あり	あり
発行所要時間	数分	1 - 3 営業日	1 - 4 週間
費用	無料 - 数千円	数万円	十万円以上
証明書ポリシー OID	2.23.140.1.2.1	2.23.140.1.2.2	2.23.140.1.1

EV 証明書は OV よりさらに厳格な審査を行います。CA/Browser Forum の EV Guidelines に基づき、法人の設立管轄、事業所在地、事業実態まで確認します。かつて Chrome と Firefox は EV 証明書のサイトでアドレスバーに組織名を緑色で表示していましたが、2019 年に両ブラウザーともこの表示を廃止しました。現在はどの検証レベルの証明書でもアドレスバーの見た目は同じです。

OV 証明書と ACME プロトコル

DV 証明書は ACME プロトコル（RFC 8555）で発行を完全に自動化できます。OV 証明書は組織審査に人手が介在するため、ACME だけでは発行プロセスを完結できません。ドメイン検証は自動化できても、組織の実在確認や電話による本人確認は手動で行う必要があります。

CA/Browser Forum の Ballot SC-081v3（2025 年 4 月可決）により、SSL/TLS 証明書の有効期間が段階的に短縮されます。

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

有効期間が 47 日になると、年間 8 回以上の証明書更新が必要です。OV 証明書は毎回の更新で組織審査を伴うため、運用負荷が大幅に増加します。Ballot SC-081v3 では SAN 以外の検証データ（組織情報）の再利用期間も 825 日から 398 日に短縮される予定で、OV 証明書の運用コストはさらに上がります。

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

CAA（Certification Authority Authorization）レコードを DNS に設定すると、そのドメインに証明書を発行できる認証局を制限できます。OV 証明書は DV 証明書より取得手続きが重いため、意図しない認証局から発行されると組織審査をやり直す必要があります。CAA レコードで発行元を明示しておくと、このリスクを防げます。

example.com.  IN  CAA  0 issue "digicert.com"
example.com.  IN  CAA  0 issuewild "digicert.com"

設定例

OV 証明書は認証局から直接購入し、CSR の生成からサーバーへの設置までを手動で行います。

OV 証明書の取得手順

OV 証明書は認証局（DigiCert、GlobalSign、Sectigo など）から直接購入します。Let’s Encrypt は DV 証明書のみを発行しており、OV 証明書には対応していません。

取得の流れは次の通りです。

1. 認証局のサイトで OV 証明書を申請する
2. CSR（Certificate Signing Request）を生成して提出する
3. 認証局がドメイン検証と組織審査を行う
4. 審査完了後、認証局から証明書ファイルが発行される
5. サーバーに証明書を設置する

CSR の生成には openssl を使います。

# 秘密鍵の生成（RSA 2048bit）
openssl genrsa -out server.key 2048

# CSR の生成（組織情報を含める）
openssl req -new -key server.key -out server.csr \
  -subj "/C=JP/ST=Tokyo/L=Shibuya-ku/O=Example Corp./CN=example.com"

CSR の /O= フィールドに指定した組織名が、認証局の審査対象になります。登記上の正式名称と一致させてください。

Nginx への設置

認証局から発行された証明書と中間証明書を結合してサーバーに設置します。

# サーバー証明書と中間証明書を結合
cat server.crt intermediate.crt > fullchain.crt

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate     /etc/ssl/fullchain.crt;
    ssl_certificate_key /etc/ssl/server.key;

    ssl_protocols TLSv1.2 TLSv1.3;
}

中間証明書を含めないと、Firefox や Android で SEC_ERROR_UNKNOWN_ISSUER エラーが発生します。認証局から中間証明書が別ファイルで提供された場合は、必ずサーバー証明書と結合してください。

確認方法

openssl でサーバー証明書が OV 証明書であるかを確認するには、Subject フィールドと証明書ポリシーの OID を確認します。

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

OV 証明書の出力例です。

subject=C = JP, ST = Tokyo, O = Example Corp., CN = example.com

OV 証明書の場合、O=Example Corp. のように組織名が含まれます。DV 証明書では O= フィールドがなく、CN=example.com のようにドメイン名だけが記載されます。

証明書ポリシーの 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.2.2

OID の対応は次の通りです。

• DV: 2.23.140.1.2.1
• OV: 2.23.140.1.2.2
• EV: 2.23.140.1.1

証明書の全体情報を確認するには -text オプションを使います。

# 証明書の全情報（発行者、有効期限、SAN、ポリシーOID など）を表示
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -text

-text オプションの出力には Subject、Issuer、有効期限、SAN、証明書ポリシーなどすべての情報が含まれます。出力が長いため、必要な項目だけを grep で抽出するのが実用的です。

外部の視点からも確認したい場合は、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 接続が成立しています。OV 証明書であっても DV 証明書であっても、正しく設定されていればこのチェックは通過します。false の場合は証明書の期限切れやチェーンの不備など、設定に問題がある可能性があります。

よくある問題

OV 証明書は組織審査と手動更新を伴うため、DV 証明書にはない運用上の課題があります。

CSR の組織名と登記情報の不一致

CSR に記載した組織名（O= フィールド）が法人登記の正式名称と一致しないと、認証局の審査で差し戻されます。英語表記の揺れ（Inc. と Inc の違い、Co., Ltd. と Corporation の違いなど）や、日本語組織名のローマ字表記の不一致が原因になることが多いです。認証局に事前確認するか、登記簿に記載されている英語名をそのまま使ってください。

中間証明書の設定漏れ

OV 証明書を発行する認証局（DigiCert、GlobalSign、Sectigo など）は、中間証明書を別ファイルで提供することがあります。サーバー証明書だけを Nginx に設定すると、Chrome デスクトップでは AIA fetching で中間証明書を補完するため問題なく表示されますが、Firefox や Android では SEC_ERROR_UNKNOWN_ISSUER エラーが発生します。認証局から提供されたすべての証明書ファイルを正しく結合してください。

有効期限の管理

OV 証明書は DV 証明書のように ACME で自動更新できません。有効期限が切れるとサイト全体がアクセス不能になるため、期限切れ前に更新手続きを完了させる必要があります。更新時にも組織審査が行われるため、期限の 30 日以上前に手続きを開始することを推奨します。

外部の監視サービスや Labee Dev Toolbox の SSL Cert API で定期的に data.reachable を確認する運用が有効です。

OV 証明書と DV 証明書の選択

ブラウザーのアドレスバー表示は DV 証明書も OV 証明書も同じです。2019 年に Chrome と Firefox が EV 証明書の組織名表示を廃止して以降、エンドユーザーが証明書の検証レベルを視覚的に区別する手段はなくなりました。組織情報を確認するには証明書の詳細を開く必要があります。

OV 証明書が適しているのは、組織の実在証明がコンプライアンス上求められるケース（金融機関、政府機関、医療機関など）や、取引先から OV 以上の証明書を要求されるケースです。単にサイトを HTTPS 化するだけであれば、DV 証明書で暗号化強度に差はありません。