Skip to content

MS_Certificate

Jump to bottom
nishi_74322014 edited this page Aug 4, 2026 · 1 revision

証明書

概要

  • 「デジタル署名」の検証は「送信側の公開鍵」を拠り所にしていると言えるが、
    提供される「送信側の公開鍵」の出所が、正規の出所か検証できない（場合がある）という問題がある。
  • このため、この問題を解決するための、「認証局」と呼ばれる
    信頼のおける第三者が発行した「デジタル証明書」を使用して
    「送信側の公開鍵」が信頼できるものであるかを検証する機構がある。
  • 「デジタル証明書」は、このような方式により成り立っているので、
    その信頼性は「認証局」の信頼性に依存する。

※ PKI（公開鍵暗号基盤）

詳細

「デジタル証明書」は

  • 「公開鍵が誰の公開鍵であるか？」を証明しているもので、
  • 署名付きのメッセージと公開鍵を格納してある。
  • 従って、証明書 ＝ 署名付き公開鍵と言っても良い。

ファイル構造

  • X.509 という規格で決まっているため、X.509 証明書とも呼ぶ。
  • X.509 の第1版は、1988年にX.500標準と関連して公開された。
  • X.500 標準と関連するため、DN（識別名）のルールなどは X.500 を踏襲している。
# 内容 必須 備考
1 フォーマットのバージョン情報 必須
2 シリアル番号 必須
3 認証局が署名に利用した暗号アルゴリズムの識別情報 必須
4 認証局の名前（X.500 識別名 (DN)） 必須 証明書記載情報
5 有効期間（開始 - 終了日時） 必須 〃
6 証明対象の名前（X.500 識別名 (DN)） 必須 〃
7 公開鍵の情報（暗号アルゴリズムの識別情報と公開鍵） 必須 〃
8 認証局のユニークID オプション 〃
9 証明対象のユニークID オプション 〃
10 拡張領域 オプション 〃
11 証明書記載情報をハッシュ化して署名したディジタル署名 必須

※ X.500 識別名 (DN) には、「CN=、O=」などが含まれる（LDAPを参照）。

補足: 現在の TLS では、ホスト名の検証に使われるのは CN ではなく 拡張領域の SAN（Subject Alternative Name）。 RFC 2818 で CN によるフォールバックは非推奨とされ、 主要ブラウザは SAN の無い証明書を受け付けない。 自己署名証明書を作る際に SAN を入れ忘れて失敗する、というのは頻出のつまずき。

2つの証明書

種類 内容
認証局の自己（発行）証明書 cer形式。認証局が自身で発行した証明書。通常、事前にクライアントPCの証明書ストアに配布されている
証明書発行要求の送信側の証明書 cer形式 or spc形式。送信側が認証局にCSRによって発行してもらったもの。秘密鍵を同梱して pfx にし、HTTPS にする Web サーバにインストールする

デジタル証明書に含まれる情報

  • 認証局の自己（発行）証明書
    • 「認証局のメッセージ（＋認証局の公開鍵）」
    • 「認証局によるデジタル署名」
  • 証明書発行要求の送信側の証明書
    • 「送信側の秘密鍵」（メッセージの署名に使用する）
    • 「送信側のメッセージ（＋送信側の公開鍵）」
    • 「認証局によるデジタル署名」

移行メモ: 「送信側の秘密鍵」は、証明書そのものには含まれない。 証明書は公開されるものであり、秘密鍵は別に保管する （両方を1ファイルにまとめたのが pfx）。 原文は「送信側が持つ一式」として列挙したものと解される。

デジタル証明書の発行と利用

デジタル証明書の発行

デジタル証明書の発行

  • 送信側が認証局にCSRを依頼して「証明書発行要求の送信側の証明書」を発行してもらう。
  • 「認証局の自己（発行）証明書」は通常、事前にクライアントPCの証明書ストアに配布されている。
  • このため、「認証局の公開鍵」を使用して「証明書発行要求の送信側の証明書」を検証できる。

デジタル証明書の利用

デジタル証明書の利用

  • 送信側
    • 受信側に「証明書発行要求の送信側の証明書」を送付する。
    • 「送信側の秘密鍵」を使用してメッセージに署名を付与する。
    • 「メッセージ＋署名」を受信側に送付する。
  • 受信側
    • 証明書の検証：「認証局の公開鍵」を使用して送信側の証明書を検証する。
    • メッセージの検証：「送信側の公開鍵」を使用して「メッセージ＋署名」を検証する。

秘密鍵付きの証明書の受け渡し

他者に証明書を渡す場合は、秘密鍵は渡されない。
秘密鍵付きの証明書の受け渡しは、pfxファイルのエクスポート・インポートなどで行なう。

ルートの認証局と中間の認証局

「認証局」が「ルートの認証局」と「中間の認証局」に分かれる場合は、次のようになる。

ルートの認証局の自己（発行）証明書（ルート証明書）
  「ルートCAのメッセージ（＋公開鍵）」＋「ルートCAによる署名」
        ↓ 証明書の発行  ／  ↑ 検証
中間の認証局の自己（発行）証明書
  「中間CAのメッセージ（＋公開鍵）」＋「ルートCAによる署名」
        ↓ 証明書の発行  ／  ↑ 検証
証明書発行要求の送信側の証明書
  「送信側のメッセージ（＋公開鍵）」＋「中間CAによる署名」

検証するとき、「証明書チェーンを辿る」と表現するように、
送信側の証明書からルート証明書へ辿るような動きをする。

  • 中間証明書のインストール
    サーバー側が中間証明書をインストールしていれば、クライアント側に中間証明書が送信されるので、
    クライアント側への中間証明書のインストールは必須ではない（ルート証明書のインストールは必要）。
  • クロスルート証明書のインストール
    新ルート証明書を入れられない場合、旧ルート証明書からチェーンするクロスルート証明書を入れる。

※ 「中間証明書の設定漏れ」は SSL 設定でもっとも多いミスのひとつ。
ブラウザによっては補完してしまい、ある環境では繋がるのに別環境では繋がらないという
切り分けにくい症状になる。

証明書の種類

サーバー証明書

  • 目的：サーバーのユーザが、サーバーの提供者の正当性を検証できるよう、サーバーに埋め込む。
  • 用途：各種 Web サービス（HTTPS、RDP など）
  • SSL/TLS暗号化通信
    SSL/TLS は「ハイブリッド暗号方式」を使用しているが、
    このうちの「公開鍵暗号方式」で使用する鍵にサーバ証明書に対応する秘密鍵・公開鍵を使用している。
  • 証明書のランク：DV（Domain Validation）／OV（Organization Validation）／EV（Extended Validation）
  • 復号機能を持つプロキシの証明書は、リバース・プロキシから転送される先の Web サーバの CN と一致させる。

補足（最新化）: EV 証明書はかつてアドレスバーに組織名が緑で表示されたが、 主要ブラウザは 2019年にこの表示を廃止した。 現在は DV/OV/EV で見た目に差はなく、DV（Let's Encrypt 等）が主流。

クライアント証明書

  • 種類
    • メール証明（メアド単位か、SMTP サーバ単位かなどがある）
    • コンピュータ証明書（802.1X の EAP-TLS 認証で利用されるなど）
    • ユーザ証明書（SSL-VPNの証明書認証で利用されるなど）
  • 目的：ユーザーが別のユーザーの正当性を検証できるよう、ユーザのメッセージに埋め込む。
  • 用途：電子メールメッセージ、Web サービス（HTTPS）
  • 特徴
    • ≒ ソフトウェア証明書（ClickOnce 用の証明書がクライアント証明書として認識される）
    • IC カードなどに格納できるので、格納場所を特定の PC に限定する必要はない。

ソフトウェア証明書

コードサイニング証明書。

  • 目的：プログラム配布先のユーザが、プログラムの開発元の正当性を検証できるよう、
    実行モジュールに埋め込む。
  • 用途：ActiveX、ClickOnce、デバイスドライバ、EXE、DLL

※ コードサイニング証明書は 2023年6月以降、
秘密鍵を HSM / トークンに保管することが必須になった（CA/Browser Forum の要件）。

拡張子から判断（*.cer, *.pfx, etc.）

.cer/.crt形式の電子証明書

  • *.cer と *.crt は基本的に同義。"cer" は certificate の意味。
  • 主に自己（発行）証明書（ルート証明書）のインポートで使用する。
  • 一般的な証明書は、この形式で証明書の所有者情報や公開鍵を含む。
  • *.cer は *.pfx や *.spc に含まれることもある。

pfx形式の電子証明書

  • *.pfx はマイクロソフトが使っている拡張子の取り決めで、*.p12 と同じ PKCS #12 形式。
  • *.cer や *.spc を、暗号化した *.pvk とパッケージしたもの。
  • 秘密鍵が含まれるためエクスポート・インポートにはパスワードが必要。
  • 用途的には、秘密鍵のエクスポート・インポートが必要なケース
    （サーバー証明書 / クライアント証明書 / ソフトウェア証明書）に利用される。

csr形式の電子証明書

  • *.csr は証明書発行要求を格納したファイル。
  • CSR：Certificate Signing Request、PKCS #10 形式。
  • 「-----BEGIN CERTIFICATE REQUEST-----」から始まる。

spc形式の電子証明書

  • *.spc はマイクロソフトが使っている拡張子の取り決めで、*.p7b と同じ PKCS #7 形式。
  • 証明書本体の他に、証明機関の証明書も一つのファイルに一緒に含めたい場合に利用する。

pvk形式の秘密鍵

  • *.pvk はマイクロソフトが使っている拡張子の取り決め。

Encoding（*.der と *.pem）

鍵の中身ではなく、エンコーディングを表している。

形式 内容
DER（Distinguished Encoding Rules） ASN.1 を DER シリアライズしたバイナリファイル
PEM（Privacy-Enhanced Mail） 上記を Base64 化し、-----BEGIN ...----- で挟んだテキストファイル
  • CSR の PEM：「-----BEGIN CERTIFICATE REQUEST-----」
  • CER(CRT) の PEM：「-----BEGIN CERTIFICATE-----」
  • KEY の PEM：「-----BEGIN RSA PRIVATE KEY-----」

移行メモ（正誤）: 原文は PEM を「Base64 シリアライズしたバイナリファイル」と していたが、Base64 化した時点でテキストファイルになる（表のとおり訂正）。 また *.pvk を「= PEM形式」としていたが、 PVK は Microsoft 独自のバイナリ形式で、PEM とは別物。 *.key（PEM の秘密鍵）とも異なる。

RSA, DSA, ECDSA

※ 現在の新規発行は RSA 2048bit 以上か ECDSA（P-256） が主流。
DSA は事実上使われない。

証明書生成の方法

  • OpenSSL
  • IIS の機能（MS_IIS.md）… 証明書チェーンがない自己（署名）証明書を生成できる。
  • 証明書サービス (AD CS)… 証明書チェーンがある自己（署名）証明書を生成できる。
  • EXE（ツール）… Windows SDK 同梱
    • Makecert.exe（証明書作成ツール）
    • Pvk2Pfx.exe（*.cer、*.spc、*.pvk を *.pfx にまとめる）
    • Cert2spc.exe（X.509 証明書から SPC を作成。テスト専用）
  • ライブラリ（DLL）
    • X509Certificate / X509Certificate2（.NET の X.509 証明書クラス）
    • BouncyCastle

補足（最新化）: Makecert.exe は非推奨。 現在は PowerShell の New-SelfSignedCertificate を使う （SAN の指定も -DnsName で容易）。

証明書ストア（リポジトリ）

アプリケーションによっては、OS の証明書ストア以外に専用のリポジトリを持っているものもある。

ツール

  • Certmgr.exe（証明書マネージャー ツール、CUI）
  • Certmgr.msc（MMC 証明書スナップイン、GUI）

論理証明書ストア

ストア 内容
個人 管理するユーザー、コンピューター、サービスに発行され、秘密鍵に関連付けられている証明書
信頼されたルート証明機関 暗黙的に信頼された「認証局の自己（発行）証明書」。グループ・ポリシーで組織に配布できる
中間証明機関 下位認証局に発行する証明書。グループ・ポリシーで配布できる
エンタープライズの信頼 証明書信頼リストのコンテナ。他組織の自己署名ルート証明書を信頼する
その他 信頼されたユーザー／ほかの人／信頼された発行元／サード パーティ ルート証明機関／信頼されていない証明書 など

目的別ストア

サーバー認証／クライアント認証／コード署名／セキュリティで保護された電子メール／
暗号化ファイル システム／ファイル回復

Linuxの場合

  • .NET Core 以降で Linux 上でも動作するようになった。
  • 証明書検証で証明書ストアをどう扱っているか？など。
  • .NET の X509Certificate2 ＋通信ライブラリでは、
    既定で証明書の検証処理が証明書ストアに依存している可能性がある。

※ Linux では OS 側のストア（/etc/ssl/certs、update-ca-certificates 等）に
ルート CA を入れる必要がある。コンテナ運用ではイメージに焼き込むのを忘れがち。

自己証明書

自己証明書には、以下の2種類の証明書がある。

自己（発行）証明書

  • 発行者と主体者が同一実体であるような公開鍵証明書。RFC 5280 の 3.2 節などに定義が見える。
  • ルート証明書、キー・ロールオーバー証明書がある。

自己（署名）証明書

「SSL/TLS等の PKI においてクライアント側で検証できない
（認証パスを辿れない）サーバ証明書」全般のことを言い、
正規の認証局から取得していない証明書全般を指す（いわゆるオレオレ証明書）。

  • 証明書チェーンがない自己（署名）証明書
    ルートの認証局の発行する証明書はすべてこれ。
    「信頼されたルート証明機関」のストアにインストールする必要がある。
  • 証明書チェーンがある自己（署名）証明書
    企業内で独自認証局を運用している場合。
    • タイプ1：クライアントは独自認証局（ルートCA、中間CA）の証明書をインポートする
      （手動／AD CS／グループ・ポリシーで展開）。
    • タイプ2：独自認証局が正規の認証局から中間認証局の証明書を取得している場合、
      クライアント側のインポートは不要になりうる。

参考

内部リンク

外部リンク

Tags: IT国際標準, セキュリティ, 暗号化, 証明書

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally