【証明書入門 第6回】証明書の種類と発行 ― DV/OV/EV・ワイルドカード・CSR・ドメイン認証・47日への短縮

証明書・PKI
2026.10.08
スポンサーリンク
スポンサーリンク

「EV証明書にしたほうが、暗号が強くて安全なんですよね？」
「ワイルドカード証明書を1枚買って、全部のサーバーに入れればお得ですよね？」

証明書を買う・申請する場面で、よく出てくる質問です。前者は誤解、後者は注意が必要です。証明書の種類の違いは暗号の強さではなく、「申請者をどこまで確かめたか」と「秘密鍵をどこまで共有するか」にあります。

第5回では、証明書を信頼する仕組み（PKI）を見ました。第6回では、証明書の種類と、CSRの作成からドメインの確認、発行までの流れを扱います。有効期間が47日まで短くなっていく、今まさに進んでいる変化も押さえましょう。

検証レベル：DV・OV・EV

公開CAのサーバー証明書は、発行前に何を確かめたかで3種類に分かれます。

DVはドメインの管理だけ、OVはドメインの管理と組織の実在、EVはさらに厳格な審査と申請者の権限まで確かめるが、暗号の強さは3つとも同じであることと、アドレスバーの組織名の表示が2019年に廃止されたことを示す図
  • DV（Domain Validation、ドメイン認証）：申請者がそのドメイン名を管理していることだけを確かめる。ACME（第8回）なら数分で自動発行される
  • OV（Organization Validation、組織認証）：組織の実在も登記などで確かめ、証明書の主体（Subject）に組織名が入る
  • EV（Extended Validation）：さらに厳格な基準で審査する

大事なのは、暗号の強さはどれも同じで、違いは申請者をどこまで確かめたかだけだという点です。冒頭の「EVのほうが暗号が強い」は誤解です。

かつてブラウザーはEV証明書のサイトで、アドレスバーに組織名を表示していました。しかし利用者の判断に役立たないとして、2019年にChrome 77とFirefox 70で廃止されました。今は証明書の詳細を開かないと違いが分からず、「EVだから安全」という説明は成り立ちません。選ぶ理由は暗号ではなく、確認の深さが要るかどうかです。

ワイルドカード証明書

冒頭の2つ目、「ワイルドカードを1枚買って全部に入れる」の話です。

*.example.jpはwww・mail・apiなど1ラベルだけに有効でexample.jp自身や2階層下には効かないことと、1枚を多くの機器に入れると同じ秘密鍵が広がり、1台から漏れると全台の鍵と証明書の入れ替えになることを示す図

ワイルドカード証明書は、SANに*.example.jpのような名前を入れた証明書で、1枚でwww.example.jpやmail.example.jpなど同じ階層の名前に使えます。

  • *が表すのはちょうど1つのラベルだけ（RFC 9525）。a.b.example.jpにもexample.jp自身にも効かない。必要ならSANにexample.jpを並べる
  • *は左端のラベル全体にしか書けず、w*.example.jpのような証明書は公開CAでは発行されない

最大の注意点は秘密鍵です。1枚を多くのサーバーやロードバランサーに入れると、同じ秘密鍵を多くの機器にコピーすることになります。1台から漏れれば、配下のすべての名前がなりすましの危険にさらされ、全台の鍵と証明書を入れ替えることになります。

名前をまとめるほど、鍵の置き場所が増える。用途ごとに分ける、機器ごとに自動で発行するなど、範囲を絞って使いましょう。

1枚に何を載せるか

種類SANの例向いている場面注意点
単一の名前www.example.jp名前が1つのサーバー名前が増えるたびに証明書も増える
マルチドメイン（SAN）www.example.jp、example.jp、www.example.com同じサーバーで複数の名前・ドメインを扱う名前を1つ足すと再発行。載せた名前は誰でも読める
ワイルドカード*.example.jp同じ階層に名前が多い、頻繁に増える1階層だけ。秘密鍵の共有範囲が広がる
組み合わせ*.example.jp、example.jpドメイン自身も含めたいワイルドカードの認証は DNS による方法だけ

SANに載せた名前は、証明書を見れば誰でも読めます。さらに公開CAの証明書はCTログ（第5回）に記録されるため、未公開のサービス名を載せると外部に知られます。

関係のないサービスを1枚にまとめると、1つの名前の追加や1台の鍵の漏えいで、全体の入れ替えが必要になります。「同じ機器・同じ管理者・同じ更新時期」でまとめるのが目安です。

公開CA・社内CA・自己署名

発行元信頼される範囲主な用途注意点
公開CA（Let’s Encrypt、DigiCert 等）世界中の端末（OS・ブラウザーが最初から信頼）インターネットに公開するサイト公開ドメイン名のみ。内部名・プライベートIPは不可。CTに記録。最長200日（2026年9月）
社内CA（AD CS、AWS Private CA、step-ca 等）ルート証明書を配った端末だけ社内システム、mTLS、802.1X、VPNルート証明書の配布、CAの鍵の保護、CRLの公開が必要（第9回）
自己署名その証明書を個別に信頼させた端末だけ機器の初期設定、検証環境利用者は本物か確かめられない。警告を無視する習慣がつく

公開CAは、.localなどの内部名（連載「DNS入門」第2回）やプライベートIPアドレスには発行しません。社内システムでも、公開ドメインのサブドメイン（corp.example.jpなど）を使っていれば公開CAの証明書を使えますが、名前がCTログで公開される点と、ドメイン認証の方法を考える必要があります。選び方は第11回の演習（問3）で扱います。

自己署名証明書（オレオレ証明書）は何も守れない

自己署名証明書は、自分の秘密鍵で自分の公開鍵に署名した証明書で、俗に「オレオレ証明書」と呼ばれます。

「なりすましは防げないが、盗聴と改ざんは防げる」と説明されることがありますが、これは誤りです。

利用者がいつもの証明書エラーを無視して進むと、攻撃者が偽の自己署名証明書で利用者と暗号化し、本物の証明書でサーバーと暗号化して、10:00作業開始を13:00に書き換えて届けられることと、証明書を検証する端末なら偽の証明書で接続を止めることを示す図

利用者が毎回警告を無視している環境では、攻撃者が通信の途中に入り、自分で作った別の自己署名証明書を差し出しても区別がつきません（中間者攻撃）。このとき暗号化は利用者と攻撃者の間で行われ、攻撃者は中身を読み、書き換えてからサーバーへ送り直せます。

相手を確かめられない暗号化は、盗聴も改ざんも防げないのです（第1回）。暗号化の相手が攻撃者なら、鍵がかかっていても筒抜けです。

自己署名証明書を安全に使えるのは、拇印（フィンガープリント）を別の経路で確かめ、端末に個別に登録した場合に限られます。なお「オレオレ」は、社内に立てた簡易なCAを指すこともあるため、案件では何を指すか確かめましょう。

証明書が発行されるまでの流れ

サーバーで鍵ペアを作り、公開鍵とSANを秘密鍵で署名したCSRを作ってCAに提出し、CAがCSRの署名を検証してドメイン認証・組織の確認を行い、CAの秘密鍵で署名した証明書を返し、サーバーに証明書・中間証明書・秘密鍵を配置する流れと、秘密鍵はCAにも送らないことを示す図
  1. 証明書を使う機器で鍵ペアを作る
  2. 公開鍵と、載せたい名前（SAN）などをまとめ、秘密鍵で署名したCSR（Certificate Signing Request、証明書署名要求）を作る
  3. CSRをCAに提出する
  4. CAはCSRの署名を検証して申請者が秘密鍵を持っていることを確かめ、ドメイン認証や組織の審査を行う
  5. CAが自分の秘密鍵で署名した証明書を、中間証明書と一緒に返す
  6. 証明書・中間証明書・秘密鍵を機器に配置する

秘密鍵はCSRに含まれず、CAにも渡しません。「秘密鍵を送ってください」と言われたら、何かが間違っています。

また、公開CAはCSRの内容をそのまま使うとは限りません。OやLなどの主体の情報は審査結果で置き換え、DVでは載せないのが普通です。届いた証明書のSANと有効期限は、必ず確かめます。

CSRを作る（openssl）

SANは設定ファイルのreq_extensionsで入れます。

$ cat www.cnf
[req]
prompt             = no
distinguished_name = dn
req_extensions     = ext
[dn]
CN = www.example.jp
O  = Example Corp.
C  = JP
[ext]
subjectAltName = DNS:www.example.jp, DNS:example.jp

$ openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out www.key
$ openssl req -new -key www.key -config www.cnf -out www.csr
$ openssl req -in www.csr -noout -text        # （抜粋）
        Subject: CN=www.example.jp, O=Example Corp., C=JP
            Public Key Algorithm: id-ecPublicKey
        Requested Extensions:
            X509v3 Subject Alternative Name:
                DNS:www.example.jp, DNS:example.jp
$ openssl req -in www.csr -noout -verify
Certificate request self-signature verify OK
  • 1行で済ませるならopenssl req -new -key www.key -subj "/CN=www.example.jp" -addext "subjectAltName=DNS:www.example.jp,DNS:example.jp" -out www.csr
  • RSAにするなら-algorithm RSA -pkeyopt rsa_keygen_bits:2048。公開CAが受け付ける鍵はRSA 2048ビット以上とECDSA P-256・P-384・P-521だけ（BR 6.1.5、Ed25519は不可）。配置する機器の対応も確かめる。www.keyはchmod 600で守る
  • 作ったら-textでSANを必ず確かめる。CNだけでは名前の検証に使われず（第4回）、SANの漏れは再発行になる

CSRを作る（Windows：certreq・IIS・MMC）

Windowsでは、certreqと設定ファイル（.inf）で作ります。

PS> Get-Content .\www.inf
[NewRequest]
Subject       = "CN=www.example.jp, O=Example Corp., C=JP"
KeyAlgorithm  = RSA
KeyLength     = 2048
HashAlgorithm = sha256
MachineKeySet = TRUE
Exportable    = FALSE
RequestType   = PKCS10
[Extensions]
2.5.29.17  = "{text}"
_continue_ = "DNS=www.example.jp&"
_continue_ = "DNS=example.jp"

PS> certreq -new .\www.inf .\www.csr      # CSR を作る（秘密鍵はこの機器のストアに残る）
PS> certutil -dump .\www.csr              # 「サブジェクト代替名」に 2 つの DNS 名があるか確認
PS> certreq -accept .\www.cer             # 発行された証明書を、残っている秘密鍵と結び付ける
  • 2.5.29.17はSANのOID。HashAlgorithmを書かないと既定がSHA-1になる場合があるため明示する
  • 秘密鍵はCSRを作った機器の証明書ストアに残る。certreq -acceptは同じ機器で行う
  • GUIなら、MMCの証明書スナップイン（コンピューター アカウント）→「個人」→「すべてのタスク」→「詳細設定操作」→「カスタム要求の作成」。IISマネージャーの「証明書の要求の作成」はSANを指定できないため、SANが要るときはMMCかcertreqを使う
  • 社内のAD CSへは、[RequestAttributes]にCertificateTemplate = WebServerを書いてcertreq -submit（第9回）

鍵をどこで作るか

CSRと秘密鍵は、証明書を使う機器の上で作るのが原則です。秘密鍵が一度も機器の外に出ないため、受け渡しの途中で漏れる心配がありません。HSMやTPMで鍵を作り、取り出せないようにできる機器もあります。

原則は使う機器の上で鍵ペアとCSRを作りCSRだけをCAに送るが、冗長構成やLBでは作業用端末でパスワード付きPFXを作って運ぶ例外があり、パスワードは別経路で、メール・チャットに添付せず、作業後に鍵を削除することを示す図

例外は、機器にCSRを作る機能がない、冗長構成の複数台やロードバランサーに同じ証明書を入れる、といった場合です。このときは別の端末で鍵とCSRを作り、PKCS#12（.pfx）にまとめて運びます。

  1. 作業用の端末を限り、作業後に鍵のファイルを消す
  2. PFXには強いパスワードを付けて、別の経路で伝える
  3. メールやチャットに鍵を添付しない
  4. 誰が鍵を持つかを台帳に書く

逆に、ハードウェアの管理コントローラーなど、機器の上でしかCSRを作れず、鍵を取り込めない製品もあります。作業計画の前にドキュメントで確かめましょう。ACME（第8回）では、更新のたびに機器の上で鍵を作り直すのが普通です。鍵が動く回数だけ、漏れる機会が増えます。

ドメイン認証（DCV）の方法

CAは、申請者がそのドメインを管理していることを、次のいずれかの方法で確かめます。

方法確かめ方特徴状況（BR 2.3.0、2026年9月）
HTTP-01（Webサイトの変更）http://名前/.well-known/acme-challenge/ にトークンを置く簡単。ポート80が外から届く必要利用可。ワイルドカードには使えない
DNS-01（DNSの変更）_acme-challenge.名前 に TXT レコードを置くワイルドカード可。外から届かないサーバーでも可利用可
TLS-ALPN-01ポート443で認証用の証明書を返す（RFC 8737）ポート443だけで完結利用可。ワイルドカードには使えない
DNS-PERSIST-01（固定のTXT）_validation-persist.名前 にCAとアカウントを書いた TXT を置いたままにする更新のたびにDNSを変えなくてよい2025年にBRへ追加。IETFで標準化中
メール（admin@ 等、TXT・CAAに書いた連絡先）送られたメールの値で応答する手作業向き2026年3月から非推奨、2028年3月15日に廃止
電話（TXT・CAAに書いた番号）電話で確認する手作業向き2026年3月から非推奨、2027年3月15日に廃止

WHOISに載った連絡先へのメール・電話による方法は、すでに廃止されています。HTTP-01・DNS-01・TLS-ALPN-01はACME（第8回）での名前です。OV・EVでも、ドメインの確認は同じ方法で行います。手作業向きの方法は、どんどん使えなくなっています。選び方は第8回（チャレンジの選び方）で扱います。

ドメイン認証を強くする動き：MPICとDNSSEC

ドメイン認証は、CAが「インターネットから見て、申請者がその名前を管理しているか」を確かめる仕組みです。そのため、攻撃者がBGPの経路の乗っ取りやDNSの偽装でCAから見える通信だけを自分に向けると、他人のドメインの証明書を取られてしまいます。

攻撃者が経路を乗っ取ってCAの本来の拠点からは攻撃者のトークンが見えても、互いに500km以上離れた地域A〜Dの拠点からはトークンが見えず、結果が食い違うので発行しないMPICの仕組みを示す図

これを防ぐのがMPIC（Multi-Perspective Issuance Corroboration、複数拠点からの確認）です。

  • CAは本来の拠点に加え、互いに500km以上離れた複数の拠点からも、同じトークンやCAAレコードが見えるかを確かめ、食い違えば発行しない
  • BRでは2025年3月に導入され、2026年3月から3拠点、6月から4拠点、12月から5拠点へと強化される
  • 2026年3月からは、ドメイン認証とCAAの確認でDNSSECの検証も必須（連載「DNS入門」第9回）

攻撃者がだませるのは、乗っ取った経路から見た結果だけ、というわけです。注意点として、海外からのアクセスを遮断していると、HTTP-01が一部の拠点から失敗することがあります。

有効期間と再利用期間の短縮（SC-081）

最後に、いちばん大きな変化です。

証明書の最長有効期間が2020年9月からの398日から2026年3月に200日、2027年3月に100日、2029年3月に47日へ、ドメイン認証の再利用期間が398日から10日へ短縮され、組織情報の再利用は398日のまま変わらないことを示すタイムライン
発行日証明書の最長有効期間ドメイン認証の再利用期間組織情報の再利用期間
〜2026年3月14日398日398日825日
2026年3月15日〜200日200日398日
2027年3月15日〜100日100日398日
2029年3月15日〜47日10日398日

CA/Browser ForumのBallot SC-081v3（2025年4月11日可決、ブラウザー4社を含め反対0）で決まり、BRの6.3.2節と4.2.1節に書かれています。今（2026年9月）は200日の段階です。

  • 2029年には、証明書の更新が1年に8回近くになる（365÷47）
  • ドメイン認証の再利用期間が10日になると、ほぼ発行のたびに認証が必要になり、手作業の認証は続けられない
  • 組織情報（OV・EVの審査結果）の再利用は398日のままで、組織の審査は年1回程度

「年に1回、手作業で更新する」という運用は、もう続けられません。これが、第8回で扱う自動化が必須になる理由です。

考えてみよう

  1. 自分の担当システムの公開証明書は、DV・OV・EVのどれですか。その種類を選んだ理由を説明できますか。
  2. ワイルドカード証明書を使っている場合、同じ秘密鍵は何台の機器に入っていますか。1台から漏れたら、どこまで入れ替えが必要ですか。
  3. ドメイン認証の再利用期間が10日になると、今の申請の手順（誰がCSRを作り、誰がどの方法で認証するか）は続けられますか。

ヒント：この記事の「検証レベル」、「ワイルドカード」と「1枚に何を載せるか」の秘密鍵の共有範囲、「ドメイン認証の方法」と「有効期間の短縮」が手がかりです。

まとめ

  • DV・OV・EVの違いは確認の深さだけ。暗号の強さは同じ
  • ワイルドカードは1ラベルだけ。秘密鍵の共有範囲が広がる点に注意
  • 自己署名証明書は何も守れない。相手を確かめられない暗号化は、盗聴も改ざんも防げない
  • 秘密鍵は機器から出さない。CAに渡すのは公開鍵を含むCSRだけ。SANは必ず確かめる
  • ドメイン認証はHTTP-01・DNS-01が中心。手作業の方法は廃止へ
  • 有効期間は2029年に47日へ。手作業の更新は続けられない

次回は、証明書が実際の通信でどう使われるか、TLSのハンドシェイクを扱います。

連載「証明書入門」全11回

  1. なぜ証明書が必要か
  2. 暗号の基礎
  3. openssl・PowerShellで試す
  4. X.509証明書の中身
  5. PKIと信頼の仕組み
  6. 証明書の種類と発行（この記事）
  7. TLSの仕組み
  8. ライフサイクルと自動化
  9. 社内PKIとクラウド
  10. 証明書トラブルシュート
  11. 証明書の設計演習

コメント

タイトルとURLをコピーしました