2015年6⽉12⽇
⻄村健（国⽴情報学研究所）

2

3

 従来のフロー（サーバ証明書の発⾏フロー）

サーバはFQDNが識別⼦(ID)→ DNSが各機関共通の信頼できる情報源(authoritativesource)となりうる→フローがある程度共通になり説明が楽

IDを利⽤するシステムが単⼀(ブラウザ)、仕様が標準化されている(TLS) 対して「⼈」のIDおよび管理⽅法は各機関ばらばらであり、フローの共通化が困難

⼈事データベースで管理している？中⾝はどんなもの？
 IDは教職員番号？メールアドレス？ePPN？
（IDとして何を選ぶべきかは証明書を利⽤するシステムに依存し、そのシステムも多様） なお、本説明ではサーバ証明書の発⾏⽅法については熟知しているものとしています（すみません）

4

③TSV投入oror

利用管理者 アクセスPIN
配付者

支援システム 利用管理者

登録担当者
②発行申請

⑤証明書(PKCS#12)
配付 or
web enroll④アクセスPINの通知①依頼利用者
5利用管理者 利⽤管理者

常勤の教職員
 登録担当者に対して発⾏申請する⼈


 利⽤者

学⽣等、利⽤管理者になれない⼈も含む
 証明書の発⾏を受ける⼈（証明書の主体者）


利⽤管理者が、利⽤者の代わりに（利⽤者の確認を⾏ったうえで）発⾏申請をするイメージ6 クライアント証明書を発⾏する対象を明確にしてく

ださい

例えば、
「⼈事・学務データベースに登録されている⼈」とか「職員証が発⾏されている⼈」とか

 利⽤申請で登録いただいた機関（利⽤機関）に所属する⼈のみに制限してください

所属しない⼈を利⽤者としてクライアント証明書を発⾏することはできません 利⽤機関は「⼤学」と「⼤学法⼈」を区別して扱いますのでご注意ください

7 クライアント証明書発⾏・更新・失効の機関内フロー（申請⼿順・審査⼿順）を定めてください すでにあるサーバ証明書のフローに準じる形にするのも⼀案です

従来フローの「サーバ」を「利⽤者」と読み替えて、フローとして問題ないか確認してください 誰を利⽤管理者と認めるか、についても各機関の判断に委ねられます（後述）8

サーバ証明書でいう利⽤管理者の範囲と⼀致しなくてもかまいません

各機関の事情・⽤途に合わせて証明書記載事項（DN等）を決定してください
 例:
C=JP
L=Academe
O=機関名
OU=部局名CN=教職員番号/学籍番号

S/MIMEを使⽤する or しない

S/MIMEを使⽤する場合、⽤途(eKU)の追加と別名(subjectAltName)にメールアドレスが設定されますSHA-2 or SHA-1



全ての記載事項が信頼できる情報源から取得できる／で確認できることを確認してください9

CNにIDを⼊れておくことで、証明書を利⽤するシステムでIDを取得することが容易になります(*)


CNの候補:
教職員番号/学籍番号, ePPN, メールアドレス, ⽒名ローマ字, …


再掲となりますが、IDとして何を選ぶべきかは証明書を利⽤するシステ
ムに依存します⽒名のように重複がある場合はDN全体で⼀意となるように適宜修正してください

ただし、S/MIMEに利⽤する場合は⽒名を⼊れることをお勧めします

メールソフトが署名証明書のこの部分を表⽰するため(*) - もちろんCNに格納する以外にも、OUに⼊れる、S/MIME使⽤の場合subjectAltNameからメールアドレスを取得する、IDと証明書の紐付けをDBで管理する、などの⽅法が考えられます10証明書⽤途や機関の事情、利⽤者のスキル等によって3つの形態から選択してください
1. 「ブラウザ発⾏」
証明書インストール(web enroll)を利⽤者に任せる
ブラウザ内で秘密鍵が⽣成されるため機密性が⾼い利⽤者にスキルがあってIE/Firefoxを強制できる場合



「P12個別」2.

証明書(PKCS#12)インストールを利⽤者に任せる
IE/Firefox以外も対象とする場合



「P12⼀括」3.

発⾏フローが発⾏側で完結しており、利⽤者には⾒えない証明書配付まで機関がコントロールしたい場合


11

職員証/学⽣証に格納して配付 など

証明書自動発行
支援システム

登録担当者

証明書プロファイルID□ SHA1
4：Client証明書
6：Client+S/MIME証明書□ SHA2
5：Client証明書
7：Client+S/MIME証明書

利用管理者

利用者

①新規申請ファイルの送付②審査、新規申請ファイルのアップロード③クライアント証明書取得URLの通知（ワンタイムURL）
・クライアント証明書の場合
DN情報チェック
O = 機関名
・S/MIME証明書の場合
DN情報チェック
O = 機関名
利用者メールアドレスと証明書記載メールアドレス間のチェック④アクセスPIN取得URLの通知⑤アクセスPIN取得URLにアクセス（ワンタイムURL）⑥アクセスPINファイルの取得⑦アクセスPINの通知⑧クライアント証明書取得URLにアクセス（ワンタイムURL）

アクセスPIN
入力あり⑩ダウンロード完了通知メール

12⑨クライアント証明書の取得⑩ダウンロード完了通知メール

SHA1 Client証明書
SHA2 Client証明書
ベースDN：
O = 機関名
L = Academe
C = JP

証明書自動発行
支援システム

登録担当者

証明書プロファイルID□ SHA1
4：Client証明書
6：Client+S/MIME証明書□ SHA2
5：Client証明書
7：Client+S/MIME証明書

利用管理者

利用者

①新規申請ファイルの送付②審査、新規申請ファイルのアップロード③クライアント証明書取得URLの通知
・クライアント証明書の場合
DN情報チェック
O = 機関名
・S/MIME証明書の場合
DN情報チェック
O = 機関名
利用者メールアドレスと証明書記載メールアドレス間のチェック

SHA1 Client証明書
SHA2 Client証明書
ベースDN：
O = 機関名
L = Academe
C = JP④アクセスPIN取得URLの通知⑤アクセスPIN取得URLにアクセス（ワンタイムURL）⑥アクセスPINファイルの取得⑦アクセスPINの通知⑧クライアント証明書取得URLにアクセス

アクセスPIN
入力あり⑪ダウンロード完了通知メール

13⑨クライアント証明書の取得⑪ダウンロード完了通知メール⑩P12ファイルをインストール

証明書自動発行
支援システム

登録担当者

証明書プロファイルID□ SHA1
4：Client証明書
6：Client+S/MIME証明書□ SHA2
5：Client証明書
7：Client+S/MIME証明書

利用管理者

利用者

①新規申請ファイルの作成、送付②審査、新規申請ファイルのアップロード③クライアント証明書
一括ダウンロードURL通知④アクセスPIN取得URLの通知
アクセスPIN
配付者⑤アクセスPIN取得URLの引渡
・クライアント証明書の場合
DN情報チェック
O = 機関名⑥アクセスPIN取得URLにアクセス（ワンタイムURL）・S/MIME証明書の場合
DN情報チェック
O = 機関名
利用者メールアドレスと証明書記載メールアドレス間のチェック⑧クライアント証明書取得URLにアクセス（ワンタイムURL）⑩ダウンロード完了通知メール

SHA1 Client証明書
SHA2 Client証明書
ベースDN：
O = 機関名
L = Academe
C = JP⑦アクセスPINファイルの取得⑨クライアント証明書の取得（ZIP形式）⑭P12ファイルをインストール⑩ダウンロード完了通知メール⑪クライアント証明書（ZIP形式）解凍⑫アクセスPINの引渡⑬クライアント証明書の配付

14 clientPin.zipもしくはclientAllPin.zipというファイル名でダウンロードされる 中にclientPin.txtもしくはclientAllPin.txtというファイルがある
TSV形式
 申請TSVの⼀部項⽬が併記され、突合できる
 内容の例:
15

利用者氏名

利用者mail

アクセスPIN

主体者DN

西村 健

takeshi@...

cVkKsC…

CN=…,…

 clientAll.zipというファイル名でダウンロードされる 中にclient.txtというインデックスファイルがある

TSV形式
 申請TSVの⼀部項⽬が併記され、突合できる
 内容の例:
シリアル番号

利用者氏名

利用者mail

主体者DN

6902…

西村 健

takeshi@...

CN=…,…

※シリアル番号は10進数表記

 他に“<シリアル番号>.p12”というファイル名でPKCS#12ファイルが⼊っている16登録担当者が引き受けるパターン

1.

利⽤管理者＝登録担当者
 ⼩規模向け


利⽤管理者=利⽤者とするパターン

2.

利⽤管理者の資格を持つ任意の⼈からの申請を受け付ける
 登録担当者は⽐較的楽

部局に委譲するパターン

3.

TSV形式各部局に利⽤管理者を1⼈ずつ割り当てる
 情報管理が分散している場合かつ⼤規模向け


利⽤管理者は固定の1⼈とするパターン

4.

ICカード発⾏者等の特定の者のみを利⽤管理者とする
 P12⼀括発⾏と組み合わせて利⽤
17 利⽤者が迷わないように、機関ごとにフローに特化した証明書取得マニュアルを整備することをお勧めします

本サービスが公開しているものは⼀般的・網羅的すぎる 公開しているマニュアルのWord版（依頼があれば提供）を適宜修正してもよいです その際、利⽤者に秘密鍵を厳重に管理するよう周知してください。また秘密鍵が危殆化した場合は速やかに報告するよう周知してください。

18

 ⼈事データベースから情報を取る形でなければクライアント証明書を発⾏してはいけないということではありません まずは⾝の回りの⼈に発⾏して、⾃分たちで使ってみるということも⼤事です その際、「何を情報源にしたか」「どんな確認を⾏ったか」記録を残すようにしてください19 現状の調査票はクライアント証明書の発⾏体制を記述するには不⼗分

主にサーバ証明書を念頭に置いたもの クライアント証明書発⾏に関する調査事項をとりまとめ、各機関に提出を依頼する予定です ご協⼒をよろしくお願いします20