昨今の情報漏洩が問題視されている状況下においてセキュアな通信ネットワークの確立は急務であると
同時に必須と言える時代になっている。構内においても無線LAN が第三者によって傍受されるなど、
ネットワークに流れる情報は簡単に読み取られやすくなっている。ましてやインターネットで Web公開
となれば、セキュアでないサイトへの情報の登録は避けられる傾向にある。
このように成りすましなども含めてセキュアな通信なくしては語れない今日となっている。
SSL (Secure Socket Layer) は、よく知られているように Netscape Communications社が開発した
インターネット上で情報を暗号化して安全に送受信することができる通信手段である。SSL は最初に
クライアントとサーバーがお互いに信頼にたる相手であるかを確認するために公開鍵と秘密鍵とを
交換して、信頼できることが確認できると、そこからまた暗号によってお互いの通信を開始する仕組みである。
これらの公開鍵と秘密鍵は証明書発行機関に依頼して有料の保守料金を支払って取得するのが
一般的な Web の手法ではあるが、System i5 では i5/OS 自体が証明書を発行できる機能を有して
いるので発行機関に依頼しなくても System i の機能を使っても SSL を利用することができる。
System i5 では V4R3M0 から SSL をサポートしており IBM 提供の TCP/IP適用業務( HTTP, Ftp, Telnet... )
でも SSL を利用することができるし、SSL API や V5R1M0 からの GSKIT を使えば、
ユーザー自身が SSL対応の TCP/IP適用業務を開発することができるようになっている。
SSL API や GSKIT の使い方は難しいものではないが SSL を利用する点において最も馴染みにくいのが
SSL環境の設定である。SSL の設定は、残念ながらカンタンでわかりやすいものではない。SSL の設定は
IBMサイトでも解説されているが、その多くが手順の羅列になっており、その意味が解説されていないので
ユーザーにとって内容が理解しやすいものとはいえない。
特に、V5R4M0 での IBM HTTPサーバーの設定は、項目が変更され、項目数も大幅に増加しているので
尻込みしてしまった人も少なくないのではないだろうか?
また、SSL の設定自身もHTTPサーバーだけに関しては特別な配慮が必要となってしまう。
そこで、ここでは System i5 の SSL環境の設定方法のエッセンスを中心に実務面より解説したいと思う。
SSL 環境の設定は、概ね次の手順に従って行う。
以下にその詳細を解説する。
i5/OS リリースによっても異なるが IBM HTTP サーバーのインスタンス *ADMIN (アドミニストレータ)の
起動は残念ながら最初から正しく起動されるケースは少ない。このあたりは PTFレベルによって微妙に
異なるので ( 最新 OS であっても )、まず、最新の PTF を適用しておく必要がある。
*ADMIN の起動は、コマンド入力画面から
STRTCPSVR SERVER(*HTTP) HTTPSVR(*ADMIN '-fsccsid 5035')
によって開始して、
WRKACTJOB SBS(QHTTPSVR)
によって次の画面が表示されれば、*ADMIN の起動の成功である。
*ADMIN は PORT番号 2001 で待機しているので ブラウザ ( IEなど)を起動して、
URL には http://192.168.1.1:2001 のように ( i5の IPアドレスが 192.168.1.1である場合)
PORT = 2001 を指定して接続すると、下記の画面が表示される。
「デジタル証明書マネージャー( DCM )」を クリックして次の設定へ進む。
証明書を作成するためには、「証明書ストア」にログインした状態で、証明書の発行等の処理を
行う必要がある。つまり、「証明書ストア」とは証明書を処理するための作業域のことであるが、
IBMの解説では、「証明書ストアの中で ... 」というわかりにくい表現が多用されているが、これは
「証明書ストアにログインしてから ...」という意味である。
デジタル証明書マネージャーの使用がその System i5 で初めてである場合は、初期値として既に
導入済みの「証明書ストア」は全く存在していない。
IBM TCP/IPユーサティリティーやユーザー開発PGM に与える証明書でも多くの場合 「*SYSTEM」という
名前の証明書ストアを使用することになるので証明書ストア *SYSTEM を 最初だけ作成する必要がある。
最初に左ペインの中から、
[ 新規証明書ストアの作成 ] - [ その他の証明書ストア ] - [ いいえ ] -
[ 証明書ストアに証明書を作成しません ]
によって、次のようにして証明書ストアを新規に作成する。
ここで重要であるのは、あなたが設定する証明書のパスワードである。
ただし、パスワードの使用する英文字は大文字で入力しておくこと。
英小文字で入力していても、内部では英大文字に変換されて登録されている。
証明書ストアの作成が終われば、早速、「 証明書ストアの選択 」ボタンを押し、「 *SYSTEM 」を選択して、
パスワードを入力して「続行ボタン」を押して、証明書ストアにログインする。
時として「 証明書パスワードが無効です 」 のエラーが頻繁に起こる場合がある。
これは 証明書ストアのパグであり、前回の処理が完結していない場合に発生する。
しかし、「 パスワードのリセット 」を行うとログインできるようになるのでご心配なく。
さて、証明書ストアにログインできたら、左ペインの「 すべて展開 」のボタンを押してすべての機能の
ツリー構造を表示しておくと全体の処理がわかりやすくなる。
また、これから「 SSL認証局 」という聞きなれない用語を頻繁に目にすることになるが、今回は
System i5 による認証なので、SSL認証局とは System i5 そのものを指しているとの理解でよい。
左ペインの中から「 証明書の作成 」ボタンを押して、
[サーバー証明書またはクライアント証明書] - [ローカル認証局]
を選択して下記のように証明書の登録を行う。
ここで重要となるのは [証明書ラベル] であり、どのような名前をつけたのかをメモしておく必要がある。
次に、
[ アプリケーションの追加 ] - [ サーバー・アプリケーションの追加 ]
を選択して、次の例のようにアプリケーションIDを登録する。
ここで「 アプリケーションID 」とは SSL適用業務プログラムが自分で SSL環境を開始する時に
自分自身を SSL に識別させるために宣言する識別コードのことである。
独力で SSL適用業務を開発する予定のある場合は、そのプログラムの最初に SSL環境の初期設定時に
自分自身を宣言するのが この「アプリケーションID」であることを覚えていて欲しい。
IBM の HTTPサーバー以外の TCP/IP適用業務 ( Ftp, Telnet, ... )には 予め適用業務ID が割り振られて
いるので、IBM の HTTP サーバー以外の既存の TCP/IP適用業務だけを SSL として利用したいだけ
なのであれば、この項での「 アプリケーションID の登録 」の作業は必要ない。
HTTPサーバー以外の SSL の設定であれば、この項は読み飛ばしてもらっても差し支えない。
IBM HTTPサーバーおよびユーザー独自の適用業務に SSL の機能を追加したいのであれば、
この登録が必要となる。
それでは、何故、IBM HTTPサーバーのアプリケーションID が存在しないのであろう。
これは、導入時には IBM HTTPサーバーは動作はするものの 設定が与えられていないからである。
そこで IBM HTTPサーバーで SSL を使用するためには、 [ 図1-1 ] から
[ IBM Web Administration for i5/OS ] - [ HTTPサーバーの作成]
を済ませておいてから [ セキュリティ ] を選択し、次のように SSL を「 使用可能 」に変更し、さらに
IBM HTTPサーバーにアプリケーションID として「 QIBM_HTTP_SERVER_WEBSERVE01 」を指定する。
ここで 「 WEBSERVE01 」とは [ HTTPサーバーの作成 ] でIBM HTTPサーバーに与えた
Webサーバーの名前である。
V5R4M0 からは IBM HTTPサーバー自身の設定項目は膨大な数に上るため、ここであきらめてしまう諸氏も
少なくないのではないだろうか ?
ここでようやく我々は IBM HTTPサーバーに「QIBM_HTTP_SERVER_WEBSERVE01」という名前を
与えたのであるが、まだデジタル証明書マネージャーには、この名前は登録していない。
そこでデジタル証明書マネージャーに戻って、次のように 「QIBM_HTTP_SERVER_WEBSERVE01」という
アプリケーションIDを登録する。
アプリケーション記述には「IBM HTTP サーバー」とでも記入の必要がある。
ユーザーで 開発する SSL適用業務であれば [ 図2-3-1 ] の事前作業はもちろん必要ない。
ユーザー開発の SSL適用業務であれば、そのソースの中で、例えば、
sslinit.applicationID = "QTR_ALASKA_HTTP";
のようにして独自のアプリケーションID を決め打ちで名前を宣言しているからである。
[図2-3-2] の作業はどの場合でも必要となる。
ご参考までに、アプリケーションID の登録は System i5 側で
i5/OS API : QsyRegisterAppForCertUse
を使っても登録することができる。
B で作成したアプリケーションIDに対して A で作成した証明書を割り当てることで、SSLは
アプリケーションに対して証明書を発行することができるようになる。
左ペインより
[ 証明書割り当ての更新 ] - [ サーバー・アプリケーションの証明書割り当てを追加、変更 ]
を選択し、割り当てるアプリケーションのラジオ・ボタンを押してから、「 証明書割り当ての更新 」ボタンを
押し、「 新規証明書の割り当て 」ボタンを押してアプリケーションに証明書を割り当てるのである。
前述までの処理によって SSL環境のセットアップは、一応完了したことになるが、実際、
SSL通信を試みても不明なエラーによって SSL通信が動作しないことがあるかも知れない。
実は、SSL 通信を行う JOB のユーザーは *ALLOBJ
権限を持っている必要があるのである。
例えば、IBM HTTP サーバーは ユーザーQTMHHTTP
または QRMHHTTP
で動作するが、これらは
*USRCLS
のユーザーであり *ALLOBJ権限は持っていない。そこで IBM HTTPサーバーを SSLで
通信して利用しようとすれば、これらのユーザーに *ALLOBJ権限を付与する必要がある。
さらに、HTTPS として SSL で HTTPサーバーと接続するには、PORT = 80 ではなく、PORT = 443 で
SSL としての HTTP サーバーを待機させなくてはならない。
ところが SSL をセットアップして STRTCPSVR *HTTP
を実行しても PORT = 443 で IBM HTTPサーバーが
待機する様子はない。
IBM HTTPサーバーを SSLとして PORT = 443 で待機させるには、別のSSLインスタンス用 HTTPCFG
を
作成して SSL専用のインスタンスを起動させる必要があると思われる。
このように IBM HTTPサーバーへの道のりは遠いものである。筆者も IBM HTTPサーバーの SSL設定の
記事は米国サイトでもいくつかは探し出すことはできたが、IBM マニュアルも含めて、
「 IBM HTTPサーバーを SSLインスタンスで起動させる方法 」については探し当てることは
できなかった。前述の SSL用インスタンスの作成しかないのではないかと予想している。
元々、SSLの調査を開始したのは 弊社製品 EnterpriseServer での HTTPサーバー Alaska で
SSL通信をサポートするためであった。
独力で TCP/IP SSL通信を開発してみようというユーザーのために SSLサーバー/クライアントの
サンプル・ソースを下記で公開しているので、ご参考にしていただきたい。
→ AS400 Tips & Techniques [TCP/IP]
28. TCP/IP SSL通信サーバー
29. TCP/IP SSL通信クライアント