図1 証明書発行作業の流れ
ゼロから始めるインターネットセキュリティ講座２時間目●認証局構築実習 講師：宮川祥子「株式会社アスキーのご厚意により、掲載しております」 |
認証局パッケージの入手とインストール |
２時間目からは、具体的な内容の講義に移ります。まず最初にPKI環境を実現するための認証局（CA）を構築するために、インストールから細かい設定までを見ていきます。つぎに証明書の発行を行ないます。今回の実習で、PKI環境構築の第一歩を踏み出しましょう。
前回はPKIの基本的な枠組みについて説明しました。PKI環境を実現するためには ・認証局（CA） ・証明書リポジトリ ・認証による暗号化通信が可能なアプリケーション が必要となります。今回は、前回紹介したお弁当屋さんモデルを実現するための機構のうち、OpenSSLによる認証局の構築の具体的な手順について解説しましょう。
OpenSSLはオープンソースのCAパッケージです。OpenSSLはSSLeayとよばれる無償のSSLパッケージをベースとして作られ、この原稿執筆中の最新バージョンは0.9.5となっています（ここでは0.9.4を使用します）。なお、動作環境はUNIX系OS全般ですが、今回はSolaris 2.5.1を利用しました。パッケージは“http://www.openssl.org/”からダウンロードできます。
ではこれからインストールを始めましょう。まずは入手したパッケージを、適当なディレクトリに展開します。
% tar -zxf openssl-0.9.4.tar.gz
OpenSSLをインストールするためには、このほかに
・Perl5
・ANSI Cコンパイラ
が必要となり、今回はPerl 5.004_04とgcc 2.8.1を利用します。次に、環境にあわせたいくつかの設定を行ないます。
% cd openssl-0.9.4
% ./config --prefix=/usr/local/openssl --openssldir=/usr/local/openssl/ssl
まず“prefix”では、インストールするディレクトリを指定しています。また何も設定しない場合は“/usr/local/ssl”がデフォルトのインストール先となります。
一方“openssldir”で指定したディレクトリには、CA関連の各種ファイルがインストールされます。何も指定しないとprefixで指定したディレクトリ以下にsslというディレクトリが自動的に作成されてそこにコピーされます。しかしprefixの指定もなければ、先程のデフォルト値と同じく/usr/local/sslがインストール先となります。
次は実際のインストールです。
% make
% su
# make install
で完了します。
opensslのバイナリや各種ユーティリティ、ライブラリは、先程prefixで指定したディレクトリにインストールされます。一方open ssldirで指定したディレクトリには、CAの設定ファイルであるopenssl.cnfと、CAを運用するための各種スクリプトが格納されるmiscディレクトリが作成されます。
openssl.cnfの設定 |
次は証明書を発行するための各種設定を行ないます。設定はopenssldirで指定したディレクトリにあるopenssl.cnfで行ないます。基本的にopenssl.cnfはデフォルトのままでも問題ありませんが、ここではCA／CAポリシー／証明書発行要求の設定について解説しましょう。
openssl.cnfは階層分けされた構造になっています。何に関する設定かは“[]”で囲まれた名前で示され、その下に具体的な設定が記述される形式になっています。まず、リスト1の[CA]セクションでは、デフォルトCAの設定を指定しています。ここではさらに[CA_default]というサブセクションが指定されており、その下の[CA_default]サブセクションに設定を記述しています。複数の設定を使いわけたい場合には、別のサブセクション（例：[CA_alternative]など）を作り、その下に設定を記述しつつ必要に応じて[CA]セクションのdefault_caの値を変えることもできます。[CA_default]サブセクションでは、dirでCAの情報が格納されているディレクトリを指定します。デフォルトは“./demoCA”となっています。[CA_default]サブセクションの最後は、CAのポリシーに関する設定です。ポリシーはpolicyで指定されるサブセクションの内容（ここではpolicy_match）が反映されます。
リスト１●openssl.cnfの設定① [ ca ] default_ca = CA_default # The default ca section [ CA_default ] dir = ./demoCA # Where everything is kept crl_dir = $dir/crl # Where the issued crl are kept database = $dir/index.txt # database index file. new_certs_dir = $dir/newcerts # default place for new certs. certificate = $dir/cacert.pem # The CA certificate serial = $dir/serial # The current serial number crl = $dir/crl.pem # The current CRL private_key = $dir/private/cakey.pem# The private key RANDFILE = $dir/private/.rand # private random number file x509_extensions = usr_cert # The extentions to add to the cert default_days = 365 # how long to certify for default_crl_days= 30 # how long before next CRL default_md = md5 # which md to use. preserve = no # keep passed DN ordering policy = policy_matchリスト2の[policy_match]サブセクションでは、CAが発行する証明書のポリシーが記述されます。それぞれの項目はmatch、supplied、optionalのいずれかの値をとります。matchはCAの対応する値と同一でなければならない項目で、suppliedは必ず必要となる項目（内容は何でもよい）、optionalは有無を問わない項目です。policy_matchでは、countryName／stateOrProvinceName／organizationNameがCAと同一でなければならず（match）、commonNameは必ず記述されていなければなりません（supplied）。またorganizationalUnitNameとemailAddressは有無を問わないのでoptionalとなります。
その下の[policy_anything]サブセクションは、policy_matchよりゆるいポリシーを設定します。もしポリシーとしてこちらのほうが好ましくなれば、リスト1の[CA_ default]のpolicyの項目を“policy=policy_ anything”に変更すればよいことになります。
リスト2●openssl.cnfの設定② [ policy_match ] countryName = match stateOrProvinceName = match organizationName = match organizationalUnitName = optional commonName = supplied emailAddress = optional [ policy_anything ] countryName = optional stateOrProvinceName = optional localityName = optional organizationName = optional organizationalUnitName = optional commonName = supplied emailAddress = optional次の[req]セクションは、CAへの証明書発行要求に関する設定です（リスト3）。dis tiguished_name／attributesは、それぞれ証明書の識別子（Distinguished Name：DN）と、そのほかの属性に関する設定が記述されているサブセクション名を値とします。ここでは[req_distinguished_name]と[req_ attributes]がそれぞれのサブセクション名です。各サブセクションには、それぞれの項目がとるデフォルト値が記述されています。この値を変更することにより、実際に証明書リクエストを作成する際のデフォルト値を変更することができます。
リスト3●openssl.cnfの設定③ [ req ] default_bits = 1024 default_keyfile = privkey.pem distinguished_name = req_distinguished_name attributes = req_attributes x509_extensions = v3_ca # The extentions to add to the self signed cert [ req_distinguished_name ] countryName = Country Name (2 letter code) countryName_default = JP ←この値を変えるとデフォルト値が変わる countryName_min = 2 countryName_max = 2 stateOrProvinceName = State or Province Name (full name) stateOrProvinceName_default = kanagawa ←この値を変えるとデフォルト値が変わる localityName = Locality Name (eg, city) localityName_default = fujisawa ←この値を変えるとデフォルト値が変わる 0.organizationName = Organization Name (eg, company) 0.organizationName_default = Nikoniko Shopping Center ←この値を変えるとデフォルト値が変わる # we can do this but it is not needed normally :-) #1.organizationName = Second Organization Name (eg, company) #1.organizationName_default = World Wide Web Pty Ltd organizationalUnitName = Organizational Unit Name (eg, section) organizationalUnitName_default = customer ←この値を変えるとデフォルト値が変わる commonName = Common Name (eg, YOUR name) commonName_max = 64 emailAddress = Email Address emailAddress_max = 40
立場の使い分け |
ここからはCAを構築して証明書の発行を行ないますが、その際に意識しなければならないことがあります。それは「自分が現在誰の立場でコマンドを叩いているか」です。たとえば、CAを構築する際にはCAが自分自身の公開鍵証明書に署名するのですが、この場合には公開鍵の持ち主と公開鍵証明書に署名するCAは同じエンティティ（認証の対象となる主体）ということになります。したがって、リクエストを作成するときや署名する際にも、同じパスフレーズ（CAのパスフレーズ）を入力します。
CAの構築／証明書リクエスト／証明書の発行という一連の作業を１人で行なう場合には「自分が今CAなのか、公開鍵の持ち主なのか」という立場を常に意識しておく必要があります（表1）。一般的に、CAの鍵ペアの生成／CAの公開鍵証明書の発行／ユーザーへの公開鍵証明書の発行はCA管理者の立場で行ない、ユーザーの鍵ペアの生成はユーザー自身の立場で行なうと考えればよいでしょう。しかし、実際にはユーザーの鍵ペアの生成もCA管理者が代理として行なう場合もあります（図1）。
| 作業内容 | 必要なパスフレーズ | 立場 |
|---|---|---|
| CAの鍵ペアの作成 | CAの秘密鍵パスフレーズ | CA管理者 |
| CAの公開鍵証明書の発行 | CAの秘密鍵パスフレーズ | CA管理者 |
| ユーザーの鍵ペアの作成 | ユーザーの秘密鍵パスフレーズ | ユーザー （CA管理者が代行する場合もある） |
| ユーザーの公開鍵証明書の発行 | CAの秘密鍵パスフレーズ | CA管理者 |
図1 証明書発行作業の流れ
CAの構築 |
OpenSSLでは、CAの構築と運用のためのユーザーインターフェイスとしてCA.shとCA. plが用意されています。どちらもopenssldirで指定したディレクトリ下のmiscディレクトリにインストールされており同じユーザーインターフェイスを提供していますが、ここではCA.shを使うことにします。CA.shのあるディレクトリにパスをとおし、
% CA.sh -newca
を実行します。すると、CAの証明書のファイル名（ここでは新規作成なのでリターンを押します）、秘密鍵のパスフレーズ、証明書の識別子（DN）を聞いてくるので、それぞれを入力すると（リスト4）、カレントディレクトリ下にdemoCAという名前でCAが作られます。このときに入力するパスフレーズはCAの秘密鍵のパスフレーズで、今後証明書リクエストに対して署名を行なう際に必要となります。できあがったCAを見ると、いくつかのファイルとディレクトリが作成されます。cacert.pemはCAの自己署名型の公開鍵証明書で、対応する秘密鍵は、private/ cakey.pemにあります。CAが正しく構築できたら、次にどのような目的で証明書を発行するかによってopenssl.cnfの[usr_cert]セクションにあるnsCertTypeの値を以下のように変更します。
・server：SSLでサーバ認証を行なう際のサーバ側証明書
・client：SSLでクライアント認証をする際のクライアント側証明書
・email：S/MIMEで暗号化メールを送る際の証明書
nsCertTypeとは、Webブラウザが証明書を取り込む際に必要なX.509v3 Extentionと呼ばれる証明書の拡張フィールドの値です。ここではクライアントに証明書を発行するため“client, email”に設定します。
リスト4●CAの構築 % CA.sh -newca CA certificate filename (or enter to create) ←リターンキーを押す Making CA certificate ... Using configuration from /usr/local/openssl/ssl/openssl.cnf Generating a 1024 bit RSA private key .............................................................................+++++ ...........+++++ writing new private key to './demoCA/private/./cakey.pem' Enter PEM pass phrase: ←CAの秘密鍵パスフレーズを設定 Verifying password - Enter PEM pass phrase: ←確認のため再度入力 ----- Country Name (2 letter code) [AU]:JP State or Province Name (full name) [Some-State]:kanagawa Locality Name (eg, city) []:fujisawa Organization Name (eg, company) [Internet Widgits Pty Ltd]:Nikoniko Shopping Center Organizational Unit Name (eg, section) []: Common Name (eg, YOUR name) []:NSC CA Email Address []:ca@nsc.orgなおデフォルトのopenssl.cnfには、CAの設定内にcertsという変数が含まれています。また、CAを構築するとCAディレクトリの中にcerts変数で指定されているcertsというディレクトリができますが、このディレクトリは筆者が調べた限りでは利用されていないようです。実際、最新版のOpenssl 0.9.5で、この変数はなくなっています。
クライアント証明書リクエストの発行 |
次に証明書リクエストを作成します。これは新規に公開鍵／秘密鍵のペアを作成し、その公開鍵証明書に署名するようCAに対してリクエストするというものです。したがってこのリクエストの発行は、公開鍵の持ち主の立場で行ないます。
% CA.sh -newreq
を実行すると、証明書発行のためのリクエストファイルが生成されます。この際に鍵ペアが生成されパスフレーズとDNなど公開鍵証明書に含める情報を聞かれるので、それらを入力します。例として筆者の公開鍵証明書をこのCAから発行することにしましょう。リスト5の下線部分が宮川祥子というエンティティに関する情報になります。“challenge password”などのオプションは省略できます。入力が終わるとnewreq. pemというファイルが作られ、内容は、
% openssl req -in newreq.pem -text
で確認することができます。opensslコマンドは、prefixで指定したディレクトリ下のbinディレクトリにインストールされています。
リスト5●証明書リクエストの作成 % CA.sh -newreq Using configuration from /usr/local/openssl/ssl/openssl.cnf Generating a 1024 bit RSA private key ........+++++ ....+++++ writing new private key to 'newreq.pem' Enter PEM pass phrase: ← パスフレーズ Verifying password - Enter PEM pass phrase: ← パスフレーズ（再入力） ----- Country Name (2 letter code) [AU]:JP State or Province Name (full name) [Some-State]:kanagawa Locality Name (eg, city) []:fujisawa Organization Name (eg, company) [Internet Widgits Pty Ltd]:Nikoniko Shopping Center Organizational Unit Name (eg, section) []:customer Common Name (eg, YOUR name) []:Shoko Miyagawa Email Address []:miyagawa@nsc.org Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []: Request (and private key) is in newreq.pemなお、ブラウザがIE5以前のバージョンの場合、公開鍵の長さが512bit以下に制限されています。CA.sh -newreqで作成する公開鍵は1024bitであるため、このままではブラウザに証明書を組み込むことができません。この場合、CA.shを使わずに
% openssl req -new -newkey rsa：512 -days 365 -keyout newreq.pem -out newreq.pem
を実行すれば、512bitの公開鍵が作成できます。なお、IE5.01以降では1024bitの公開鍵が利用できます。
CAによる署名 |
次にCAの署名を行ないます。このときは再びCA管理者の立場にもどっています。つまり証明書リクエストを受け取ったCAが、この内容をチェックして証明書の発行を行なうという場面です。どのディレクトリで行なうかは、openssl.cnfの[CA_default]サブセクションでdirの値をどのように設定しているかによって変わります。デフォルトの ./demoCAのままであればdemoCAの上位ディレクトリで行ないます。先ほど作成したnewreq.pemをカレントディレクトリに置き、
% CA.sh -sign
を実行するとパスフレーズを聞かれるので、CAの秘密鍵のパスフレーズを入力します。するとリクエストファイルの内容を表示して署名をしていいかを確認してくるので、ここで“y”と答えるとCAは署名を行ない公開鍵証明書を発行します。できあがった宮川祥子の公開鍵証明書はnewcert.pemという名前で作成され、証明書の内容は
% openssl x509 -in newcert.pem -text
で確認することができます。この証明書をNetscapeやIEに組み込んでおけば、WWWサーバに対して宮川祥子からのアクセスであることを証明できるようになります。
クライアント証明書の組み込みとサーバ証明書の発行 |
WWWを使った通信でクライアント認証を行なうためには、ブラウザに証明書を組み込む必要があります。これらのブラウザはクライアント証明書をPKCS#12（Public- Key Cryptography Standards：RSA Laborato riesによる公開鍵暗号関連の規格で、詳細は“http://www.rsasecurity.com/rsalabs/pkcs/”）という形式で読み込むため、pem形式の証明書をPKCS#12形式に変換する必要があります。このとき、証明書がクライアントで正しく検証できるようCAの証明書もPK CS#12ファイルに組み込みます。
% openssl pkcs12 -export -inkey newreq.pem -in newcert.pem -certfile cacert.pem -name "Shoko Miyagawa" -out newcert.pkcs12
ここでnewreq.pemは秘密鍵、newcert. pemは証明書、cacert.pemはCAの証明書、newcert.pkcs12は出力されたPKCS#12形式のファイルになります。パスフレーズを聞かれるので公開鍵の持ち主の立場でパスフレーズの入力を行ない、ついでエクスポートのためのパスワードを設定します（なお、最新版のOpenSSL0.9.5では、CA.shから実行できるようになっています）。
ここで作ったnewreq.pem、newcert.pem、newcert.pkcs12は新しいリクエストを作成すると上書きされてしまうので、別の名前に変更して保存するとよいでしょう。なお、newreq.pemとnewcert.pkcs12には、エンティティの秘密鍵が含まれており、所有者やパーミッションの設定を注意して、第三者に見られないようにする必要もあります。
こうしてできあがったPKCS#12ファイルをクライアントにコピーします。クライアントのブラウザがNetscapeの場合はツールバーのセキュリティアイコンをクリックし、証明書のリストから「本人」を選ぶと、すでに組み込まれている証明書一覧がリスト表示されます。ここに証明書を組み込むために「証明書のインポート」をクリックするとパスワードを設定するためのダイアログボックスが表示されるので、ここでパスワードを設定し（すでに設定してある場合はパスワードを入力するよう促される）、PK CS#12ファイルをインポートします。IEの場合、ツールメニューのインターネットオプションからコンテンツタブを選択し「証明書」をクリックして「インポート」を選択するとウィザードが開始されて証明書がインストールされます。
一方、サーバ証明書を発行する際には、openssl.cnfのnsCertTypeをserverに設定し、クライアント証明書と同様の手順で発行を行ないます。証明書リクエストを発行する際には、WWWサーバ管理者の立場でパスフレーズやDNなどの情報を入力します。今回は「はなまる弁当」という名前のサーバ証明書を発行しました。ここで作ったサーバとCAの証明書は、次回に解説する証明書リポジトリに登録されます。
パスワード、パスワードそしてまたパスワード |
以上でCA構築と証明書発行に関してのひととおりの手続きは完了しました。この手続きの中では何度もパスワードやパスフレーズを設定／入力する場面が出てきます。これらのパスワード、パスフレーズはどれも忘れると証明書の発行や利用に支障をきたすので、注意して設定する必要があります。表2に、パスワード、パスフレーズを設定する場面と利用する場面についてまとめたので参考にしてください。
| パスワード・パスフレーズ | 設定するとき | パスワード・パスフレーズが必要なとき |
|---|---|---|
| CAの秘密鍵のパスフレーズ | CAの構築時 | 証明書発行時 |
| クライアントの秘密鍵のパスフレーズ | 証明書リクエスト生成時 | PKCS#12ファイル生成時 |
| サーバの秘密鍵のパスフレーズ | 証明書リクエスト生成時 | PKCS#12ファイル生成時 |
| PKCS#12ファイルのエクスポートパスフレーズ | PKCS#12ファイル生成時 | ブラウザにPKCS#12ファイルをインポートする時 |
| Netscapeのパスフレーズ | Netscapeに初めて自分の証明書を組みこむ時 | Netscapeに自分の証明書を組みこむ時（２回目以降） |
★
さて次回は、証明書を使ったアプリケーションであるApache-SSLの設定と、証明書リポジトリの構築について解説します。
| この記事は、Ascii Network Pro 2000年6月号に掲載された記事を、株式会社アスキーのご好意によって掲載許可をいただいたものに、若干の加筆訂正を行ったものです。この場を借りて、株式会社アスキーに御礼申し上げます。 |