EDB/PKIの目的

EDB/PKI(第2世代)

  • EDB/PKI(第1世代)の寿命が2015年2月(ルート証明書の有効期限)に切れるため,後継となる公開鍵基盤(PKI)を構築する.
  • EDB/PKIを2005年にスタートから図らずもEDB/PKIが継続して存続し,また,現時点においても学内の情報システムのいくつかでは有効に活用されているため,後継となるEDB/PKI(第2世代)を構築・運用を行なう.

EDB/PKIの運営・特徴

○ Private CA (Certificate Authority)での運営
一般にオーサライズされたCAの運用には膨大な資金が必要.
利用範囲を学内(構成員)に限定するならば公的CAと同等のサービスを提供できる.
○ 教職員を対象に認証システムを提供.
学生については情報センターの管轄.
EDBに蓄積された教職員の情報を有効に活用する.
○ 異種認証システムとの連係
EDBの登録情報をベースにLDAP, RADIUS, Kerberosなどの認証システムの登録情報を作成する.
認証だけでなく,LDAP等へのディレクトリ情報,DNS/BIND等の登録情報も提供する.
個人(クライアント)とDNSの情報(サーバ)の認証情報を管理,矛盾のない公開鍵基盤を形成する.

EDB/PKIでの制約事項

○ 証明書の発行
証明書発行の対象は,EDBに対応する情報が登録されていなければならない.
当面,証明書発行の対象は,【個人】,【擬人】,【ホスト】情報とする.
EDBの登録情報(個人,擬人,ホスト)に対して各 1通の証明書を発行する.(複数は発行しない.)
但し,第1世代から第2世代への移行措置として,世代毎に各1通の証明書を発行する.すなわち,2015年2月までは一つの主体に2通の有効な証明書が存在する状態を継続する(第1世代の証明書は2015年2月に失効する.).2通の証明書の識別名(DN)は同一である.
○ 証明書の属性
個人(擬人)の証明書のCN (CommonName)は,「S'個人(擬人)情報のEID'」とし,認証システムに際してはこれがアカウント名となる.
ホストの証明書のCNは,いわゆるFQDN (Fully Qualified Domain Name)とする.FQDNはIPアドレスが直接関係づけられていないALIAS(別称)でも構わない.
○ 免責事項
一般のPKIに対して,EDB/PKIの公開鍵基盤の信頼性(証明書発行対象が正しく証明書を利用しているかの検査機構,秘密鍵の保管形態等の保障,個人やサーバ管理者に対する啓蒙)は劣っている.EDB/PKIの提供する公開鍵基盤を過信する事の無いようにお願いしたい.

PKIの情報の取得

第1世代(〜2015年2月) 第2世代
○ ROOT証明書の取得

EDBのルート証明書は下記のいずれかで取得できる.

(内容は同一.PEM形式の証明書である.)

EDBのルート証明書(第2世代)は下記のいずれかで取得できる.

(内容は同一.PEM形式の証明書である.)

○ ROOT証明書のFingerPrint(SHA1) EF:EB:C9:C2:41:94:A9:0E:C4:24:D0:06:AC:CF:D4:A7:07:68:98:37 C1:57:75:CD:CB:57:3A:13:50:34:48:86:B3:D4:07:92:B3:42:FB:6B
○ ROOT証明書のFingerPrint(MD5) 85:B7:C6:18:1D:70:45:F1:B1:CF:BA:8F:EE:A4:67:8C 90:59:F5:F4:66:1C:13:EE:EC:FA:2E:B6:99:37:97:EA
○ あるホスト(サーバ)証明書を取得

サーバの証明書は接続時にサーバから自動的に送信されるが,それとは別にサーバの証明書を取得する必要がある場合には,

  • http://web.db.tokushima-u.ac.jp/DNS/PKI/HOST/fqdn.of.server/certificate.pem
  • http://web.db.tokushima-u.ac.jp/DNS/PKI/HOST/fqdn.of.server/certificate.crt
  • http://web.db.tokushima-u.ac.jp/PKI/CN/fqdn.of.server.pem
  • http://web.db.tokushima-u.ac.jp/PKI/CN/fqdn.of.server.crt
のいずれかで取得できる.(内容は同一.PEM形式の証明書である.)

○ ある個人(擬人)の証明書を取得

ある個人(擬人)の証明書を取得する場合には,

  • http://web.db.tokushima-u.ac.jp/PKI/EID=eid.of.person/certificate.pem
  • http://web.db.tokushima-u.ac.jp/PKI/EID=eid.of.person/certificate.crt
  • http://web.db.tokushima-u.ac.jp/PKI/CN/Seid.of.person.pem
  • http://web.db.tokushima-u.ac.jp/PKI/CN/Seid.of.person.crt
のいずれかで取得できる.(内容は同一.PEM形式の証明書である.)

○ 証明書失効リスト(CRL)の場所
https://ca.db.tokushima-u.ac.jp/ca/cert.crl
https://ca.db.tokushima-u.ac.jp/ca/cert2nd.crl

X.509属性

属性名 属性
○ countryName (C): JP
○ stateOrProvinceName (ST): Tokushima
○ localityName (L): Tokushima City
○ organizationName (O): The University of Tokushima
○ organizationalUnitName (OU): EDB
○ commonName (CN):
(CNを識別名として利用するので,ユニーク性を維持する必要がある.)
ルートCA(第1世代): root-ca.db.tokushima-u.ac.jp
ルートCA(第2世代): root2nd-ca.db.tokushima-u.ac.jp
CAのWEBサーバ: ca.db.tokushima-u.ac.jp
EDBのWEBサーバ: web.db.tokushima-u.ac.jp
ホストの証明書であれば「CN=ホストのFQDN」とする.
個人(擬人)の証明書であれば「CN=S'個人(擬人)情報のEID'」とする.

試験用RADIUSサーバ

EDBサーバにおける個人認証のポリシー

HTTPS
ブラウザの提示した個人証明書がSSLで認証される.
個人証明書の示すユーザに対応する個人情報において,登録されている個人証明書と一致する.
ユーザ自身が[環境設定]において,SSLによる自動ログインを選択する.

個人証明書の作成

個人証明書を作成するにはEDBにログイン後, で,個人証明書発行の頁に進み,その頁の記述にしたがって手続きを行ってください. 手続きには, の2種類があります. 作成されたPKCS#12ファイルのOSへのインポート方法については,次項を参照してください.

PKCS#12ファイルのインポート方法

○ MacOS X 10.7, 8, 9ぐらい

[Step 1]
一般の証明書をOSが正しく処理するためには,それらの証明書を作成したROOT-CAの証明書(自己証明書; ROOT証明書)をOSが信頼(trust)する必要があります.
まず,ROOT証明書をシステムに登録します.
(第1世代のルート証明書)
  1. ルート証明書ファイル(第1世代: "root.crt")をダウンロードし,ファイルをダブルクリックすると,「キーチェインアクセス」が起動する.
  2. インポート場所として「システム」を選択してOKをクリック.
  3. パスワードを尋ねてくるので,システムのパスワードを入力.
  4. 「信頼する」を選択.
(第2世代のルート証明書)
  1. ルート証明書ファイル(第2世代: "root2nd.crt")をダウンロードし,ファイルをダブルクリックすると,「キーチェインアクセス」が起動する.
  2. インポート場所として「システム」を選択してOKをクリック.
  3. パスワードを尋ねてくるので,システムのパスワードを入力.
  4. 「信頼する」を選択.
[Step 2]
次に個人の秘密鍵,公開鍵,証明書を自分のアカウントに登録します.
  1. 個人の秘密鍵,公開鍵,証明書が入っているPKCS#12("cert.p12")をダブルクリックすると,「キーチェインアクセス」が起動する.
  2. インポート場所として「ログイン」 (もしくは自分のアカウント)を選択してOKをクリック.
  3. パスワードを尋ねてくるので,PKCS#12("cert.p12")ファイルを作成するときの暗号化に用いたパスワードを入力.
[Step 3]
以上で作業は終了です.システム中では,「S'個人(擬人)情報のEID'」(例: S12345)という名称で,鍵の名称が表示されます.
絵ときの説明を好まれる方は,下記のPDFを参考にしてください.
証明書インストール
(例示されている画像は古くなっていますが,基本的な仕組みは変わっていません.)
証明書を用いてWebサイト認証を行うには,「キーチェインアクセス」に更に認証識別の登録をする必要があります.
詳しくはFAQ「Safariで証明書ログインができません」を御覧下さい.

○ Windows XP

下記のFAQの記載を参考にしてください.
  • FAQは Windows XP での説明となっています.Windows 7では,FAQのページの最後のコメントを参考にしてください.
    (Windowsの「自動的に証明書ストアを選択する」に任せると「中間証明機関」にインストールしようとします.
    「自動的に証明書ストアを選択する」を利用せずに,マニュアルで「信頼されたルート証明機関」を指定してインストールしてください.)
  • EDB/PKI(第2世代)のルート証明書は root2nd-ca.db.tokushima-u.ac.jp と表示されます.

WWWサーバの設定方法(第1世代,第2世代混合

○ Apache Ver.2.2 (on FreeBSD 10.x)

[Step 0] 証明書,秘密鍵,証明書失効リストの準備

EDBのインタフェースを用いて,サーバ証明書,証明書失効リストを作成する.
○ サーバ証明書,サーバ秘密鍵:
  • サーバ証明書は,証明書を作成したいホスト情報の閲覧画面において[データ]→[X.509証明書(第2世代)発行]を選んでください.
  • 個人証明書の発行と同じ手順で,サーバ証明書の発行手続きを行うことができます.
  • PKCS#12形式のファイルからサーバ証明書,サーバ鍵を取り出すには,
    % openssl pkcs12 -in cert.p12 -clcerts -nodes
    を実行(秘密鍵を暗号化するには-nodesを省いてください.)して,出力された内容
    Bag Attributes
    ...
    -----BEGIN CERTIFICATE-----
    MII...
    ...
    ...
    ...
    -----END CERTIFICATE-----
    Bag Attributes
    ...
    -----BEGIN RSA PRIVATE KEY-----
    MII...
    ...
    ...
    ...
    -----END RSA PRIVATE KEY-----
    緑色の部分をサーバ証明書ファイル(server.crt), 赤色の部分をサーバ秘密鍵ファイル(server.key)に保存してください.
○ ルート証明書:
  • ルート証明書(第1世代)はここ(root.crt)をクリックして取得してください.
  • ルート証明書(第2世代)はここ(root2nd.crt)をクリックして取得してください.
○ 証明書失効リスト:
  • 証明書失効リスト(第1世代)はhttps://ca.db.tokushima-u.ac.jp/ca/cert.crlをクリックして取得してください.
  • 証明書失効リスト(第2世代)はhttps://ca.db.tokushima-u.ac.jp/ca/cert2nd.crlをクリックして取得してください.
    • 証明書失効リストは定期的に更新する必要があります.
    • EDB/PKIでは毎日証明書失効リストを更新していますので,定期的に更新するようにしてください(毎日更新することが好ましい).
    • 証明書失効リストの有効期間は30日に設定されていますので,30日以内にファイルを更新することが必要です.
    • もし30日以内に更新されなかった場合,多くのWWWサーバの実装ではブラウザからの接続を全く受け付けなくなってしまいます.

[Step 1] ファイルの配置

ダウンロードしたファイルをApacheの設定ディレクトリ($APACHE_CONF_DIR (ex. /usr/local/etc/apache22))の以下の位置に配置する.
用途 ディレクトリ ファイル 内容 説明
サーバ認証 server/ server/server.crt サーバの証明書 クライアント(ブラウザ)がサーバを検証するために,サーバがクライアントに提示する証明書です.
server/server.key サーバの秘密鍵 クライアント(ブラウザ)がサーバを検証検証する際に,サーバ側で利用する秘密鍵です. サーバ証明書と対になっているものを配置します. (暗号化されていないファイルを利用する場合には,一般ユーザから読み出し禁止にしておくことを推奨します.)
server/root.crt
server/root2nd.crt
ROOT証明書 クライアント(ブラウザ)がサーバを検証検証する際に,サーバがクライアントに提示するROOT証明書です. このROOT証明書はサーバ証明書に対して署名を行なったものです. 第1世代ではroot.crt, 第2世代ではroot2nd.crtが署名を行なっていますので,どちらか一方を利用することとなります. (第1世代の寿命が尽きた場合には root.crt は配置する必要はありません.)
クライアント認証 ssl.crt/ ssl.crt/root.crt
ssl.crt/root2nd.crt
ROOT証明書 サーバがクライアント(ブラウザ)を検証する際に用いるROOT証明書です. 第1世代のクライアントには root.crt, 第2世代のクライアントには root2nd.crt が利用されます. (第1世代の寿命が尽きた場合には root.crt は配置する必要はありません.)

このディレクトリに配置するROOT証明書は,そのハッシュ値でシンボリックリンクしておく必要があります. シンボリックリンクの作成方法は下記の通り.(最後の .0 を忘れないように)

# ln -s root.crt `openssl x509 -in root.crt -noout -hash`.0
# ln -s root2nd.crt `openssl x509 -in root2nd.crt -noout -hash`.0

ハッシュ値を用いてシンボリックリンクを作成するため,運悪くハッシュ値が衝突してしまう可能性があります. その場合には .0 の部分を .1, .2 のように他の数字を用いてください.

ssl.crl/ ssl.crl/cert.crl
ssl.crl/cert2nd.crl
証明書失効リスト(CRL) サーバがクライアント(ブラウザ)を検証する際に参照する証明書失効リスト(CRL)です. 第1世代のクライアントには cert.crl, 第2世代のクライアントには cert2nd.crl が利用されます. (第1世代の寿命が尽きた場合には cert.crl は配置する必要はありません.)

このディレクトリに配置する証明書失効リストは,そのハッシュ値でシンボリックリンクしておく必要があります. シンボリックリンクの作成方法は下記の通り.(最後の .r0 を忘れないように)

# ln -s cert.crl `openssl crl -in cert.crl -noout -hash`.r0
# ln -s cert2nd.crl `openssl crl -in cert2nd.crl -noout -hash`.r0

ハッシュ値を用いてシンボリックリンクを作成するため,運悪くハッシュ値が衝突してしまう可能性があります. その場合には .r0 の部分を .r1, .r2 のように他の数字を用いてください.

証明書失効リストは定期的に更新する必要があります.(毎日を推奨) ファイル取得コマンド(fetch, curlなど)を用いて下記のようなスクリプトを作成し,cron などで毎日実行してください. (ハッシュ値によるシンボリックリンクを作成しなおす必要はありません.)

#!/bin/sh
cd $APACHE_CONF_DIR
fetch -o cert.crl https://ca.db.tokushima-u.ac.jp/ca/cert.crl
fetch -o cert2nd.crl https://ca.db.tokushima-u.ac.jp/ca/cert2nd.crl
exit 0

[Step 2] Apache設定ファイルの編集 (SSL部分)(その1)

Apache の extra/httpd-ssl.conf を以下のように設定する.
$APACHE_CONF_DIR はサーバの設定ディレクトリの位置に置き換えてください.)
タグ 第1世代のサーバ証明書 第2世代のサーバ証明書 説明
SSLCertificateFile $APACHE_CONF_DIR/server/server.crt (サーバの証明書ファイル)
SSLCertificateKeyFile $APACHE_CONF_DIR/server/server.key (サーバの秘密鍵ファイル)
SSLCertificateChainFile $APACHE_CONF_DIR/server/root.crt $APACHE_CONF_DIR/server/root2nd.crt (ROOT証明書ファイル)
SSLCACertificatePath $APACHE_CONF_DIR/ssl.crt (ROOT証明書を容れるディレクトリ)
SSLCARevocationPath $APACHE_CONF_DIR/ssl.crl (証明書失効リストを容れるディレクトリ)
SSLCARevocationCheck chain ※ … Apache 2.4.x で証明書失効の検査を実行するために必要.(デフォルトでは検査しない)

[Step 3] Apache設定ファイルの編集 (SSL部分)(その2)

SSL認証の必要の可否に応じて,extra/httpd-ssl.conf を以下のように設定する.
タグ 第1世代のサーバ証明書 第2世代のサーバ証明書 説明
SSLVerifyClient require または optional
require …
クライアントに証明書提示を必ず要求する.
クライアントが証明書をもたない場合には接続不能.
optional …
可能ならばクライアントが提示した証明書による認証を行う.
クライアントが証明書をもたない場合でも接続可能.ただし,ユーザ認証は別の方法で行なう必要がある.
SSLOptions +StdEnvVars CGIやPHPで下記の環境変数を参照する場合の設定.SSLの接続可能性でアクセス権のみをチェックし,ユーザを特定した処理を行なわない場合には必要なし.

(補足)

SSL認証に成功すれば接続したユーザの証明書情報が下記のように環境変数に設定される.
変数名 説明
SSL_CLIENT_M_VERSION3証明書のバージョン
SSL_CLIENT_M_SERIAL0E証明書のシリアル
SSL_CLIENT_A_KEYrsaEncryption証明書の暗号化方式
SSL_CLIENT_A_SIGsha1WithRSAEncryption証明書の署名アルゴリズム
SSL_CLIENT_V_STARTJan 10 09:30:31 2005 GMT証明書の有効期間(開始)
SSL_CLIENT_V_ENDJan 8 09:30:31 2015 GMT証明書の有効期間(終了)
SSL_CLIENT_I_DN/C=JP/ST=Tokushima/L=Tokushima City/O=The University of Tokushima/OU=EDB/CN=root2nd-ca.db.tokushima-u.ac.jp/emailAddress=edb-admin@db.tokushima-u.ac.jp証明書の発行者(Issuer)の情報
SSL_CLIENT_I_DN_CJP
SSL_CLIENT_I_DN_STTokushima
SSL_CLIENT_I_DN_LTokushima City
SSL_CLIENT_I_DN_OThe University of Tokushima
SSL_CLIENT_I_DN_OUEDB
SSL_CLIENT_I_DN_CNroot2nd-ca.db.tokushima-u.ac.jp
SSL_CLIENT_I_DN_Emailedb-admin@db.tokushima-u.ac.jp
SSL_CLIENT_S_DN/C=JP/ST=Tokushima/L=Tokushima City/O=The University of Tokushima/OU=EDB/CN=ユーザのCN名/emailAddress=ユーザのメールアドレス証明書の主体(Subject)の情報
SSL_CLIENT_S_DN_CJP
SSL_CLIENT_S_DN_STTokushima
SSL_CLIENT_S_DN_LTokushima City
SSL_CLIENT_S_DN_OThe University of Tokushima
SSL_CLIENT_S_DN_OUEDB
SSL_CLIENT_S_DN_CNユーザのCN名
SSL_CLIENT_S_DN_Emailユーザのメールアドレス
SSL_CLIENT_VERIFYSUCCESS証明書の検証結果
CGIなどでこれらの情報を参照するとときには,
  • SSL_CLIENT_VERIFY=SUCCESS
となっていることを必ず確認後,
  • SSL_CLIENT_S_DN_CN
の値で,ユーザを識別すればよい.(CNがユニークであることは,EDB/PKIの範囲内で保証されている)

○ Basic認証と混在させる方法

X.509個人証明書を持っている人はSSL認証で,それ以外の人は通常のBasic認証をしたい場合で,ユーザを制限したい場合,すなわち,

  • 特定の証明書を持ったユーザにのみアクセスを許す.
  • 証明書を持っていないユーザもログインできるようにしたい.
という場合には,以下のように設定することで実現できます.

  1. extra/httpd-ssl.conf において,
    • SSLVerifyClient optional
    を設定する.この設定で,アクセスして来たユーザが証明書を持っている場合にのみ証明書の提示を求めることになる.
  2. 認証の対象となるディレクトリに ".htaccess" を作成して,
    AuthType	Basic
    SSLOptions	FakeBasicAuth
    AuthName	"Secure-Directory"
    AuthUserFile	"/usr/local/etc/apache2/password"
    require		valid-user
    と設定する.(もちろん,サーバ全体の設定で".htaccess"が有効になっている必要がある.)
    AuthName の名前は自由である.また,AuthUserFileで指定するファイルの場所も自由である.
  3. AuthUserFileで指定したファイルを作成する. このファイルの中身は,
    ユーザ名:パスワード
    がユーザ一人一人について書かれているのでそれをユーザ分だけ用意します. ただし,SSL認証(すなわちX.509個人証明書を提示し,検証)されたユーザに関しては,
    /C=JP/ST=Tokushima/L=Tokushima City/O=The University of Tokushima/OU=EDB/CN=ユーザのCN名/emailAddress=ユーザのメールアドレス:パスワード
    を一人一人のDN名にあわせて作成します.ただし,パスワードのところは,
    % htpasswd -nbm 12345 password
    と実行して出力される文字列の `:' より後ろを記述してください.(これは,文字列 `password' を暗号化した文字列.Apacheのバージョンにより異なることがあるらしい)
    SSL認証を利用しないユーザに関しては従来と同じように
    ユーザ名:パスワード
    をhtpasswdコマンドを利用して作成します.
  4. 以上で設定は終りです.Apacheを再起動してテストを行ってください.

○ EDBからパスワードファイル(Apache)を生成する方法

EDBの【組織】情報に登録されている[構成員]の情報から,特定の組織に属している(かつ,指定された肩書を持っている)個人のリストを抽出し,Apacheサーバのパスワードファイル等に記載すべきリストを生成する方法を説明します.

◇ http://web.db.tokushima-u.ac.jp/PKI/PERSON-LIST/O=list-of-organizations
指定した組織に現時点で構成員として登録されている個人のリストを抽出する.
個人の抽出は,【組織】情報の階層構造を探索し,下位の組織についても再帰的に行われる.
現時点の意味するところは,【組織】.[構成員]に登録されていても,期間限定属性により現在の構成員と見做されない場合にはリストに含まれないことを意味する.
[例]
○ 工学部(EID=11019)に属する個人リストを抽出する.
http://web.db.tokushima-u.ac.jp/PKI/PERSON-LIST/O=11019
○ 工学部(EID=11019)と工学研究科(EID=11022)に属する個人リストを抽出する.
http://web.db.tokushima-u.ac.jp/PKI/PERSON-LIST/O=11019,11022
◇ http://web.db.tokushima-u.ac.jp/PKI/PERSON-LIST/O=list-of-organizations/T=list-of-titles
指定した組織に現時点で構成員として登録されている個人で特定の肩書を持っている個人のリストを抽出する.
肩書においても,期間限定属性がチェックされる.
[例]
○ 工学部(EID=11019)に属する教授(EID=10045)のリストを抽出する.
http://web.db.tokushima-u.ac.jp/PKI/PERSON-LIST/O=11019/T=10045
○ 工学部(EID=11019)に属する教授(EID=10045),助教授(EID=10047),講師(EID=10048),助手(EID=10049)のリストを抽出する.
http://web.db.tokushima-u.ac.jp/PKI/PERSON-LIST/O=11019/T=10045,10047,10048,10049
○ 工学部(EID=11019)と工学研究科(EID=11022)に属する教授のリストを抽出する.
http://web.db.tokushima-u.ac.jp/PKI/PERSON-LIST/O=11019,11022/T=10045

http://web.db.tokushima-u.ac.jp/PKI/PERSON-LIST/により抽出されたリストの各行は,

EIDEDBにおける情報識別子.いくつかのシステムではアカウント名として用いられることがある.
LifeName英語(ローマ字)表記の氏名.
CNX.509属性におけるCommonName.多くのシステムでアカウント名として用いられる.
DNX.509属性における識別名.ApacheのSSLOptionss FakeBasicAuthでユーザの識別名として用いられる.
stateX.509個人証明書の状態.
  • none … X.509個人証明書が未発行である.
  • VALID … X.509個人証明書が発行されている.
  • Revoked … X.509個人証明書が失効している.
で構成され,各フィールドはTAB文字(U+0009)で区切られている. また,「;」で始まる行は注釈行である.

例えば,

#!/bin/sh
tmpfile=/tmp/make-passwd.$$
bpass='$apr1$abcdefgh$**********************' …BasicAuth用の無効なパスワード
cpass=`htpasswd -nbm 12345 password | awk -F: '{print $2}'` …FakeBasicAuthで用いるパスワード

fetch -q -o $tmpfile http://web.db.tokushima-u.ac.jp/PKI/PERSON-LIST/$1
grep '^; END-OF-RESPONSE' $tmpfile	> /dev/null
if [ X"$?" = X"0" ]; then
	grep -v '^;' $tmpfile | awk -F'\t' '{
		print $1 ":" "'$bpass'" ":" $2 ":"; …BasicAuth用のパスワード行 
		print $4 ":" "'$cpass'" ":" $2 ":"; …FakeBasicAuth用のパスワード行 
	}'
else
	echo 'ERROR'
fi

rm -f $tmpfile
exit 0
のようなShellScript (./make-passwd.sh)を作成すれば,
% ./make-passwd.sh O=11019,11022
で,Apache用のパスワードファイルを作成することができる.