Archive for 3月, 2008

週末の散歩



藤井さんも、用賀の砧公園に行かれたようですが、

私は奥様と一緒にたまプラーザを散歩してきました。



たまプラーザの桜も満開でいつもより人も

多かったように思います。



日曜日は、雨が降ってしまったので、自宅で

HERO (vol. 8まで)のDVDを静かに見ていました。















そういえば、先週末はX JAPANの3日間ライブもあったようですね!!

今日の朝、TVでライブの模様を見たのですが、X JAPANは今も健在ですね!!



私も、高校時代はかなりX JAPANにはまっていて(私はYOSHIKIファン)

当時、家でXの曲をガンガンに聴いていると、いつも姉や両親にうるさーい!!と

怒鳴られていたものでした。(^_^;)



実は、今でも集中して仕事をしたい時は、X JAPANの曲を聴きながらやると

アドレナリンが大量に放出されて仕事がとても捗ったりもします。(^_^;)



X JAPANの復活は私自身も心待ちにしていたので、とれも嬉しい復活劇でした。

ただ、コンサートには行きたいけど、もう年齢的に行けないかな。(^_^;)

次のCDが出たら必ず買います!!(これからはX JAPANの隠れファンになるぞ!!)


2008年3月31日 at 12:00 午前

GlassFishとMySQL

Translate to English by
Google Translator




今日は、アクアリウムで嬉しい発表がありました!!



ご存知の通り、SunとMySQLは今年はじめに統合を発表し、

すでに統合も完了しているのですが、その成果が早くも現れてきました。



なんと、アプリケーションサーバとMySQL Community Serverの統合バージョンが

ついにリリースされました。







SJS AppServer 9.1ur1+MySQLのダウンロード先



上記は現状で英語版のみの提供ですが、こうしてMySQLとの統合結果が早くも

現実になった事は嬉しい限りです。



そういえば、他のブロガーの皆様も発表しているようですが、MySQLの

イベントが開催される予定です。



米国 Sun Microsystems, Inc. と MySQL の合弁完了にともない、日本で

両社がひとつとなって、ビジネスを開始するに当たり、初めての外部向け

セミナーを、下記の要領にて開催いたします。



「春のMySQL祭り2008 – Jumping to the Sun !」



開催概要:

日時:2008年04月09日 13:30開場

会場:ウエスティンホテル東京

〒153-8580 東京都目黒区三田1-4-1(恵比寿ガーデンプレイス内)



費用:無料(事前登録制)

主催:MySQL株式会社、サン・マイクロシステムズ株式会社



お申し込み・詳細はこちらをご覧下さい。



http://jp.sun.com/mysql





是非、御興味あるかたは無料セミナーなのでどしどし御参加下さい!!





PS.

今日は、御仕事で新宿に行ってまいりました。

新宿の都庁前にも桜が咲いていたのですが、もうすっかり満開でした!!

明日は、雨らしいので週末に向けて散らない事を祈る限りです。










2008年3月27日 at 8:40 午前

桜な季節

English translation by Google Translator


ずいぶんと温かくなって来ましたね。



Solaris エバンジェリストの大曽根さんのブログにも
ありますが、用賀にある砧公園の桜も

随分と咲いてきているようですね。

近々、僕も行って撮ってこよ!!



所で最近、下記の本を買いました!!







この本は自分が持っているリコーのデジカメ(GR DIGITAL II)について、かなりあつく

プロのカメラマンの方が語っているのですが、前にも書きましたように私はカメラの

知識はまだまだありません。

ですので、プロのカメラマンにそこまで言わせるカメラを自分が持っていて使いこなせて

いないのはかなり恐縮してしまいます。(^_^;)

すいません、色んな本読んでもっとカメラ道を勉強します!!



なんだか良さそうなカメラだなとでたばかりの頃に、衝動買いをしたわけですが、

まだまだ使いこなせてなく、今は日々、岡崎大先生に聞きながら勉強を
している状況です。



今日はそんなデジカメで起きた出来事と、それに対するメーカさんの対応について報告致します。



先日から、とある理由で少し調子が悪くなっていた私のデジカメ、岡崎大先生からも

寺田さん、それ早く修理した方が良いですよ!!とアドバイスをもらっていました。

自分も何とかしなければと思っていたのですが、ついに修理に出す事にしました。



リコーさんは、銀座に即日修理ができる店舗を構えているのですが、

私はそちらに直接持っていき修理してもらいました。

持って行く前は、保証期間内でも修理代が取られるのではないかと思っていたのですが、

結局無料で修理して頂く事ができました。また受付の担当者の方にもとても丁寧に対応していただきました。



リコーの保守対応はブログ等でみる限り良さそうだと思っていたのですが、実際にこのような丁寧な対応を

迅速にしてもらうと、とても良い印象を受けます。



一方、昨年のJavaOne期間中に壊れたデジカメについては、メーカ名は出しませんが、

日本に戻ってきて修理に出したのですが、そこは決してよい対応ではありませんでした。

さらには、修理しましたと言って製品が帰ってきたのですが、すぐにまた壊れてしまいました。

(<-物理故障ではなくファームウェアのバグでハング)

多分、もう二度とあのメーカの製品は購入しないですね。



同じ物が壊れるという事象に対して、対応する人によって180度変わる印象。

とても大切な事だと顧客の視点から改めて感じたのと同時に、メーカにいる人間として

見習うべき所があるなぁと感じた出来事でした。



私も過去に、Solaris等のOSに関連したサポートの業務を行っていたのですが、

その頃の私は、余裕もなく日々の仕事に追われているだけでした。

ですので、決して良い対応ができていたとは思いません。むしろ逆だったかな?(^_^;)

とても反省しています。



そう思うと、サポートをする人って自分がいっぱいいっぱいになっては駄目なのかな?

心にゆとりがなければならないのかななんて思います。



みなさん、ちまたでは3Kとも言われるIT業界にいて、今心にゆとりを持って仕事をされていますか?

ゆとりがなくなっているのであれば、ちょっと休憩して桜でも見にいきましょっか?

   #強引に桜ネタにもどした?(^_^;)



日本の会社は期末時期で大変とは思いますが、桜でも見て気をなごませてくださいね!!



下の写真は以前行った河津の桜です。






2008年3月26日 at 5:55 午前 1件のコメント

アプリケーションサーバの有償トレーニング開催

Translate to English by Google Translator



今回は他部門のトレーニングの御紹介です。

Sun では教育部門によるアプリケーションサーバの有償のトレーニングも開催しています。




Sun Java System Application Server SE/EE 8.1 2005Q2: Administration and Deployment

(JP-IAS-4444)




私は上記のコースを受講した事はありませんが、コース内容を見る限り、

かなり内容の濃いトレーニングのようです。



コース内容



  1. Application Server SE/EE 8.xの概要紹介

  2. 管理アーキテクチャ

  3.   (DASやノードエージェント、中央レポジトリ、JMXによる管理等)
  4. Appliaction Server SE/EE 8.xのインストール

  5. 設定と管理

  6. 配備

  7. HTTPロードバランサ(負荷分散)

  8. HADBの基礎

  9. HTTPセッションの永続性

  10. RMI/IIOP の負荷分散とフェールオーバ

  11.   リッチクライアント(ACC)からの負荷分散

  12. EJBコンテナの高可用性

  13. JMSのクラスタ(SJS MQ3.6 クラスタ)

  14. アップグレードとマイグレーション

  15.    他のアプリケーションサーバからのマイグレーション方法

       アプリケーションの動作が可能か確認するツール(AVK)の紹介
  16. アプリケーションサーバのパフォーマンスチューニング

  17. トラブルシューティング






今回紹介するトレーニングは、最新のGlassFish/Sun Java System Application Server 9.1ur1についての

トレーニングではありませんが、8.1と9.1は管理の概念(ドメイン、インスタンス等)も

同じで、(内部の実装は全く異なりますが)また、ロードバランサの設定や

HADBについては殆ど同じ内容になりますので、8.1を御使用されている方以外に、

9.1でこれから御使用される方にも十分に参考にして頂ける内容になっていると思います。



日程も、4/22-4/25までの4日間のコースでまるごとアプリケーションサーバの

トレーニングですので、普段私が1時間かそこらで話をする内容とは密度も異なり、

実機を使って実際に操作をしながら学ぶ事ができますので、本番環境で運用される方は

とても有用な情報を得られると思います。



  #値段は4日間コースで288,000円 (税込:302,400円)

  #本番環境での運用を本格的に検討されている方は

  #是非、受講されてみては如何でしょうか。



先ほど、教育の知り合いに電話で空席がどの程度あるのか

直接聞いてみたのですがまだ席は若干数残っているようでした。



教育で記載されているスケジュールによると次回開催は9/16まで

無いようですので、今回はかなりレアなトレーニングだと思います。



  #仮に定員がいっぱいになってしまって、今回入れなかった方が

  #どうしても早期の開催を希望される場合は、別途

  #エデュケーション・サービス TEL:03-5717-4300 までお問い合わせください。



PS.

今回、何故このエントリを書いたかというと、アプリケーションサーバのトレーニングって

本当に回数が少ないんですよね。

毎回、定期的に開催しているようなトレーニングであればわざわざ私が告知する必要もないのですが、

本当に回数が少ないので紹介しました。

  #たまたま今日トレーニングのサイトを覗いて見つけました。



私の記憶が確かならば、ついこの間までApplication Server 7.1のトレーニングを

開催していたので、Application Server 8.1のトレーニングはまだ初めて回数も少ないはずですし

この後も何回、開催されるかわからないので、是非このチャンスに御興味のある方は

参加してみてください。(対象は運用管理者の方の方が良いと思います。)



PS 2.

というか、僕も教育の方がどのようなトレーニングを開催しているのか

わからないので、一度本気で聞いてみたいのですが。。。。。。




2008年3月25日 at 8:10 午前 1件のコメント

プロジェクトHudson日本語コミュニティ開始?

Translate to English by Google Translator



開発者の皆様、Hudsonってご存知ですか?



Hudsonは継続的インテグレーション(Continuous Integration)のツールです。
「継続的インテグレーションって何?」と初めて聞く方もいらっしゃるかと思いますので、少しだけかんたんに

説明をすると、今まで中規模から大規模の開発を行う際に、Ant,Mavenといったビルドツール、CVS,Subversionと

いったバージョン管理ツールそれぞれを独立して使用してきたと思います。このHudsonを使用するとこういった

ビルドツールとバージョン管理ツールの連携等がかんたんに実現できるようになります。

たとえば、ある開発者の方がソースコードをコミットしたとします。するとコードが

コミットされた直後に自動的にビルドを実行して実行結果をメールで飛ばすなんて事ができるようになります。

それ以外に、テストツールとの連携や、インスペクションツールとの連携もできるようになります。

また、ビルドした結果をテスト用のサーバに自動的にデプロイしてくれるようになったりします。



小規模な開発環境では少ない人数でコード管理、ビルド管理等を行うのでなんとかなるかもしれません。

実際、このようなCIのツールがでてくるまでは、中規模から大規模な環境でもそうされてきたでしょう。

しかし、今後このようなCIツールを利用する事により、中規模から大規模なシステム開発においては、

非常に重宝するツールです。実際に、GlassFishやJBossの開発においてこのHudsonは使われています。

開発者の皆様、是非御使いください。



Hudsonの開発者の中には、US Sunの川口さんの他、
最近、今井さんという方もコミッタとして

参加されているようです。



こういった日本人のコミッタがいるおかげ?!か、既にマルチリンガル版に対応しており、

起動をすると下記のように日本語の管理画面が表示されます。











また、最近になって日本語でやりとりができるメーリングリストも作成されているようで、

ja@hudson.dev.java.netのアドレスから参加できるようです。



それ以外にも、feed://feeds.feedburner.com/HudsonBlogs-jaで日本人ブロガーによる情報が提供されています。



是非、日本の開発者の方もHudsonを使ってください。



Hudosonについての過去投稿された記事等



● 川口さん

● cactusmanさん

● 高井さんより

  WEB+DB Vol 41(2007) Java カウボーイプログラマの実験室 第3回

● 岡崎さんのHudson NetBeansプラグインの紹介

● InforQ: HudsonとFindBugsを用いた継続的インテグレーションとコードインスペクション

2008年3月24日 at 8:50 午後

相関図ジェネレータ

Translate to English by Google
ちょっと、古いネタですがコネタを!!



http://genzu.net/sokan/



やっぱり、GlassFishとNetBeansは肉体関係なんですね。(^_^)






2008年3月19日 at 8:32 午前

I will use the Google translator since today.

Since today I will attach the technical information which is translated to English by Google on my blog entry.

At the top of my blog Entry, I will attach the “English translate” link .

If you push the link , the request will send to Google translator .



Thus , foreigner also may be able to read my entry .



Please refer to following link ?



My Top Page.



Web Server related tech info



App Server(glassfish) related tech info





Note:

My attachment screen image was got on Japanese locale environment.

So It is not equal to the English screen .



Yoshio.


2008年3月19日 at 8:05 午前

3. OpenSSLでクライアント認証「クライアント認証環境構築編」

Translate to English / Google/Yahoo

今日は、OpenSSLを使用してディレクトリサーバとブラウザにクライアント証明書をインストールして、Web サーバとブラウザ間でクライアント認証を行う方法について紹介します。

設定手順は下記の通りです。

設定手順

手順1:Web サーバとディレクトリサーバの連携設定
手順2:Web サーバのHTTPリスナーの編集
手順3:Web サーバのアクセスコントロールの設定
手順4:Web サーバのcertmap.confの編集
手順5:ディレクトリサーバの拡張設定
手順6:新規ユーザの作成
手順7:クライアント証明書の作成
手順8:ブラウザへクライアント証明書のインストール
手順9:ディレクトリサーバへクライアント証明書のインストール

前提:

ブラウザから送信されたクライアント証明書をWebサーバ側で比較するわけですが、比較対照のクライアント証明書はディレクトリサーバ側で保持します。そこで、Webサーバとディレクトリサーバの連携を行う必要があります。

※ Webサーバ上の静的ファイル中に証明書を保持する事もできますが、セキュアな環境を構築したい場合、外部のディレクトリサーバに証明書データを保持しておいた方が安全です。

※ ディレクトリサーバは既に別途インストールされている事を前提として記述します。

手順1:Web サーバとディレクトリサーバの連携設定

Web サーバの管理画面より、「構成」→「対象の構成(sw-120)」→「アクセス制御」
→「認証データベース」を選択してください。
ここでは、デフォルトで「keyfile」と呼ばれる認証データベースが存在しますが、
ディレクトリサーバと連携する為に、「新規」ボタンを押下してください。

「新規」ボタンを押下すると下記の画面が表示されます。
ここでディレクトリサーバに接続する為に必要な情報を入力し、「了解」ボタンを押下してください。

「了解」ボタンを押下すると下記の画面が表示されます。
「配備保留中」リンクをクリックしてください。

「配備保留中」リンクをクリックすると下記のウィンドウが表示されます。「配備…」
ボタンを押下してください。

「配備…」ボタンを押下すると下記の画面が表示されます。
「閉じる」ボタンを押下してください。

「閉じる」ボタンを押下すると「認証データベース」一覧中に
「LDAP-SERVER」のエントリが追加されている事を確認できます。

次に、ディレクトリサーバと正常に接続ができているか確認する為に、下記の図のように
「アクセス制御」の「ユーザ」タブを選択してください。
「ユーザ」タブを選択すると、下記の画面が表示されます。
この画面ではユーザの参照、追加、削除等の操作ができます。
それでは、実際に「ユーザの検索」を行ってみましょう。
「認証データベースの選択:」で「LDAP-SERVER(ldap)」を選択し、
検索ボタンを押下しましょう。
既存のユーザが存在している場合、検索結果に一覧が表示されます。仮に既存ユーザが
存在しない場合、「新規」ボタンを押下するとディレクトリサーバに新規ユーザを
追加する事もできます。

以上で、Web サーバからディレクトリサーバに対して接続ができる事が確認できました。

手順2:Web サーバのHTTPリスナーの編集

次に、Web サーバの対象のインスタンスにおいて、クライアント認証を受け付ける事が
できるようにHTTPリスナーの設定を変更します。
既にWebサーバでSSLの設定がされている必要があります。
WebサーバのSSLの設定はWebサーバのサーバ証明書設定を参照してください。

「構成」→「対象の構成(sw-120)」→「HTTPリスナー」タブを選択し、
現在有効になっているHTTPリスナー(http-listener-1)のリンクを押下してください。

リンクを押下すると下記の画面が表示されます
「クライアント認証:」の「必要なディスク容量」を選択し
「適用」ボタンを押下してください。

※「必要なディスク容量」と表示されている日本語メッセージは
日本語翻訳のバグです!!
英語版では「Required」と表示されているので「必須」と訳されるべきです。
「適用」ボタンを押下した後、「閉じる」ボタンを押下してください。

「閉じる」ボタンを押下すると下記の画面が表示されます。
「配備保留中」リンクを押下してください。

「配備保留中」のリンクを押下すると、下記のウィンドウが表示されます
「配備…」ボタンを押下し配備して下さい。

配備が正常に完了すると下記の画面が表示されます。
「閉じる」ボタンを押下し配備を終了して下さい。

これで、HTTP リスナーの設定が完了しました。
以上の設定でクライアントのWeb ブラウザが443番ポートに
HTTPSで接続した際に、必ずクライアント証明書を要求するようになります。

手順3:Web サーバのアクセスコントロールの設定

HTTPリスナーの設定が完了した後、アクセスコントロール(ACL)の設定を行いましょう。
「構成」→「対象の構成(sw-120)」→「アクセス制御」→「アクセス制御リスト(ACL)」を
選択してください。「アクセス制御リスト(ACL)」を選択すると下記の画面が表示されます。
ここで、アクセス制御リスト中の「リソース欄」に「default」と記載された項目が
表示されますので、このリンクを押下します。

「default」のリソースを選択すると下記の画面が表示されます。
ここで、「認証方法:」をSSLに変更して下さい。
その後で、「アクセス制御エントリ(ACE)」中の「ACE動作」の
「編集」を行います。
「編集」のリンクを押下して下さい。

※ 「default」は全てのアクセスに対する設定になります。特定のURLに対して
だけアクセス制限をかけたい場合は、「新規」ボタンを押下して別途作成
してください。

「編集」のリンクを押下すると下記の画面が表示されます。
ここで、「ユーザとグループ」の設定を「認証データベース中
のすべて」に変更して、最後に「了解」ボタンを押下してください。

「了解」ボタンを押下すると下記の画面が表示されます。
再度、「認証方法:」が「SSL」になっている事を確認した後、
「了解」ボタンを押下します。

「了解」ボタンを押下すると下記の画面が表示されます。
「配備保留中」のリンクを押下してください。

「配備保留中」のリンクを押下すると下記の画面が表示されます。
「配備…」ボタンを押下してください。

配備が正常に終了すると下記の画面が表示されます。
「閉じる」ボタンを押下して終了してください。

以上で、アクセスコントロールの設定が完了しました。
上記までの設定を行う事により、Web サーバは接続する全てのクライアントである
Webブラウザに対して、クライアント証明書を要求し、クライアント認証が完了しない
リクエストは全て拒否するようになります。

手順4:Web サーバのcertmap.confの編集

次に、Web サーバのcertmap.confと呼ばれるファイルを編集します。
この設定ファイルはWeb ブラウザから送信されるクライアントの証明書と、
ディレクトリサーバ上に存在するクライアントの証明書を比較する為に必要な
マッピング等の設定を行います。
下記のように設定を変更して下さい。

修正前:

>
vi /sun/webserver7/https-sw-120/config/certmap.conf
…..(前略)
certmap
default default
#default:DNComps
#default:FilterComps e, uid
#default:verifycert on
#default:CmapLdapAttr certSubjectDN
#default:library <path_to_shared_lib_or_dll>
#default:InitFn <Init function’s name>

修正後:

>
vi /sun/webserver7/https-sw-120/config/certmap.conf
…..(前略)
certmap default default        //コメントアウト
default:DNComps          //コメントアウト
default:FilterComps e, cn //コメントアウト
default:verifycert on        //コメントアウト
default:CmapLdapAttr certSubjectDN //コメントアウト

certmap.confの詳細は下記URLを参照してください。

http://docs.sun.com/app/docs/doc/819-2630/6n4thbjc4?l=Ja&a=view#abumq

certmap.conf設定ファイルを手動で変更後、管理画面に戻って「仮想サーバ」タブ、
もしくは他のタブを押下して下さい。
すると下記のように画面右上部に「インスタンス設定が変更されています」というリンクが
表示されます。このリンクを押下して下さい。

※ ここで表示されるリンクは設定ファイルが手動で変更された後に管理画面の操作
を行った場合に表示されるようになります。(手動設定変更の自動検知)

リンクを押下すると下記の画面が表示されます。
ここで、「構成を取得し配備します」を選択し、「了解」ボタンを押下してください。

「了解」ボタンを押下する前に、「詳細を表示」ボタンを押下すると、
手動で変更されたファイル名を確認する事もできます。
実際に「了解」ボタンを押下すると今回手動で設定変更を行ったのは、
「config/certmap.conf」ファイルであることを確認できます。

「了解」ボタンを押下すると下記の画面が表示されます。
「閉じる」ボタンを押下し、配備を終了してください。

以上でWebサーバ側のクライアント認証を行うための全ての設定は完了です。

手順5:ディレクトリサーバの拡張設定

Webサーバの設定が完了しましたので、次にディレクトリサーバの設定を行いましょう。
今回ディレクトリサーバとして、Sun Java System Directory Server 5.2 Update 6を
使用しています。同様の設定は最新の、Sun Java System Directory Server Enterprise
Editionでも可能ですので、新しいバージョンを使用されている場合も、同様の設定を行ってください。
まず、ディレクトリサーバの管理コンソールにログインしてください。

次に、ディレクトリサーバのインスタンスを選択して「開く」ボタンを押下します。

「開く」ボタンを押下すると下記の画面が表示されます。
「設定」タブを押下し左のメニュー画面より「スキーマ」を選択してください。

「スキーマ」を選択すると下記の画面が表示されます。

右画面より「属性」を選択し「作成」ボタンを押下してください。
すると下記の画面が表示されます。
ここで、「属性名:」に「certSubjectDN」を入力し、「構文:」に「DN」を選択し、「複数値」のチェックを外して「了解(O)」ボタンを押下してください。

※ ここで追加するLDAPの属性は、Web サーバの「certmap.conf」ファイル中に記載した

下記の内容に一致します。
仮に「certmap.conf」の「CmapLdapAttr」で名前を変更している場合、
同一の名前の属性を作成してください。

certmap.conf

default:CmapLdapAttr certSubjectDN

「了解(O)」ボタンを押下すると下記の画面が表示されます。

次に、「オブジェクトクラス」タブを選択し、新規クラスを作成します。
「オブジェクトクラス」タブを押下し、「作成…」ボタンを押下してください。

「作成…」ボタンを押下すると下記の画面が表示されます。
オブジェクトクラスの「名前」に任意の名前(例:client-cert-person)を
入力し、「必須属性:」に「certsubjectdn」、「許可された属性」に
「usercertificate」を追加し、「了解」ボタンを押下してください。

※ usercertificateを必須属性にしない理由は後ほど説明します。

「了解」ボタンを押下すると下記の画面が表示されます。
作成したオブジェクトクラスが存在しているか確認してください。

以上でディレクトリサーバ上の設定は全て完了です。

手順6:新規ユーザの作成

それでは新規ユーザを登録しましょう。
Web サーバの管理画面より、「構成」→「対象の構成(sw-120)」→
「アクセス制御」→「ユーザ」より「新規…」ボタンを押下して下さい。

「新規」ボタンを押下すると下記の画面が表示されます。
ここで必要事項に入力して「了解」ボタンを押下してください。

ユーザが正常に追加されると下記の画面が表示されます。

また、ディレクトリサーバのコンソールから確認しても
ユーザが追加されている事を確認できます。

手順7:クライアント証明書の作成

新規ユーザを作成したので、このユーザに対する新規クライアント証明書を作成しましょう。
OpenSSLでクライアント証明書の秘密鍵を作成するには下記のコマンドを実行します。

下記では、トリプルDESを使い1024bitの秘密鍵(client-private-key)を生成しています。

>
openssl genrsa -des3 -out client-private-key 1024
Generating
RSA private key, 1024 bit long modulus
………..++++++
……………………….++++++
e
is 65537 (0x10001)
Enter
pass phrase for client-private-key:[******]
Verifying
– Enter pass phrase for client-private-key:[******]
>
ls
client-private-key

クライアントの秘密鍵を生成しましたので、次に署名要求(CSR)を作成します。
下記のコマンドを実行してください。
するとclientcsr.pemと呼ばれる署名要求(CSR)が生成されます。

>
openssl req -new -days 365 -key client-private-key -out
clientcsr.pem

Enter pass phrase for client-private-key: [******]
You are about to be asked to enter information that will be
incorporated into your certificate request.
What you are about to enter is what is called a Distinguished Name or a
DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,

If you enter ‘.’, the field will be left blank.
—–
Country
Name (2 letter code) [US]:JP
State or Province Name (full name) [Some-State]:Tokyo
Locality Name (eg, city) []:Setagaya
Organization Name (eg, company) [Unconfigured OpenSSL Installation]:Sun
Microsystems K.K.

Organizational Unit Name (eg, section) []:Software Practice
Common Name (eg, YOUR name) []:Foo Bar
Email Address []:Foo.Bar@foo.bar.com
Please enter the following ‘extra’ attributes
to be sent with your certificate request

A challenge password []:
An optional company name []:
> ls
client-private-key
clientcsr.pem

次に、認証局(CA)で署名を行いますが、その前に
認証局(CA)の設定を一部変更してください。

>
cp /etc/sfw/openssl/openssl.cnf
/etc/sfw/openssl/openssl-client.cnf

>
vi /etc/sfw/openssl/openssl-client.cnf
basicConstraints=CA:FALSE
<—FALSE
より変更
# For normal client use this is typical
nsCertType = client, email <—- コメントアウト

それでは実際に、認証局(CA)でクライアント証明書の署名を行います。

>openssl ca -config /etc/sfw/openssl/openssl-client.cnf -in
./clientcsr.pem -out clientcert.pem
Using configuration from /etc/sfw/openssl/openssl-client.cnf
Enter pass phrase for /etc/sfw/openssl/private/cakey.pem:
[******]
DEBUG[load_index]: unique_subject = "yes"
Check that the request matches the signature
Signature ok
Certificate Details:
Serial Number: 10 (0xa)
Validity
Not Before: Mar 18 07:10:14 2008 GMT
Not After : Mar 18 07:10:14 2009 GMT
Subject:
countryName               = JP
stateOrProvinceName       = Tokyo
organizationName          = Sun Microsystems K.K.
organizationalUnitName    = Software Practice
commonName                = Foo Bar
emailAddress              = Foo.Bar@foo.bar.com
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Cert Type:
SSL Client, S/MIME
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
56:64:98:F2:33:16:62:82:2B:50:91:36:29:87:48:46:74:26:00:44
X509v3 Authority Key Identifier:
keyid:06:C7:E8:90:D1:04:7C:36:16:FE:AA:D2:B2:B6:EC:C4:13:84
:36:A1
DirName:/C=JP/ST=Tokyo/L=Setagaya/O=Sun Microsystems K.K./OU=
Software Practice/CN=Hanako Yamada/emailAddress=Hanako.Yamada@foo.bar.jp
serial:00
Certificate is to be certified until Mar 18 07:10:14 2009 GMT (365 days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

上記で署名済みのクライアント証明書(clientcert.pem)が生成されました。

手順8:ブラウザへクライアント証明書のインストール

Web ブラウザへ証明書をインストールする為には、秘密鍵と
クライアント証明書をまとめた、PKCS#12形式のファイルを作成し、
PKCS#12形式のファイルをブラウザへインストールします。
下記のようにクライアント証明書とクライアントの秘密鍵、
認証局の証明書を使用してPKCS#12形式のファイルを作成しましょう。
下記のコマンドを実行するとclientcert.p12と呼ばれる
PKCS#12形式のファイルが生成されます。

>
ls
client-private-key
clientcert.pem clientcsr.pem
sw-120-web
> openssl pkcs12 -export -in clientcert.pem -inkey
client-private-key -certfile /etc/sfw/openssl/cacert.pem -out
clientcert.p12

Enter pass phrase for client-private-key: [******]
Enter Export Password:[******]
Verifying – Enter Export Password:[******]
> ls
client-private-key
clientcert.p12 clientcert.pem clientcsr.pem
>

上記で、PKCS#12形式の「clientcert.p12」ファイルを
生成しましたので、Webブラウザにインストールしましょう。
下記図のようにWebブラウザのメニューより「環境設定」→
「詳細」→「暗号化」タブを選択し、「証明書を表示」ボタンを
押下してください。(ブラウザがFirefoxの場合)

「証明書を表示」ボタンを押下すると下記の画面が表示されます。
ここで「インポート」ボタンを押下してください。

「インポート」ボタンを押下すると下記のファイルダイアログ画面が表示されます。
ここで、事前に作成した、PKCS#12形式のファイル(clientcert.p12)を選択し、
「開く」ボタンを押下します。

「開く」ボタンを押下すると下記の画面が表示されます。
ここで「パスワード」欄にPKCS#12を生成する際に入力した
Exportのパスワードを入力し「OK」ボタンを押下します。

「OK」ボタンを押下すると下記の警告画面が表示されます。
「OK」ボタンを押下し終了してください。

「OK」ボタンを押下しすると「証明書マネージャ」に
インストールされたクライアント証明書が表示されます。

念のためクライアント証明書の内容を確認してみましょう。
インストールしたクライアント証明書を選択し「表示」ボタンを押下してください。
ボタンを押下すると下記の画面が表示されます。
内容を確認すると、「この証明書は以下の用途に使用する証明書であると検証されました」
というメッセージが表示され、一覧の中に「SSLクライアント証明書」が含まれている事を
確認できます。

以上で、クライアントのWeb ブラウザ側の設定は完了です。

手順9:ディレクトリサーバへクライアント証明書のインストール

クライアント証明書より証明書のSubjectのDNを入手
クライアントの証明書の中に含まれるSubjectのDNをディレクトリサーバに格納します。
そしてアクセスして来たクライアントが提示したクライアント証明書よりSubjectのDNを抽出し、
ディレクトリサーバ上のSubjectのDNとクライアント証明書のSubjectのDNを比較します。
内容が異なる場合、アクセスを拒否します。

>openssl x509 -in clientcert.pem -text 
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 10 (0xa)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=JP, ST=Tokyo, L=Setagaya, O=Sun Microsystems K.K., OU=Softwa
re Practice, CN=Hanako Yamada/emailAddress=Hanako.Yamada@foo.bar.jp
Validity
Not Before: Mar 18 07:10:14 2008 GMT
Not After : Mar 18 07:10:14 2009 GMT
        Subject: C=JP, ST=Tokyo, O=Sun Microsystems K.K., OU=Software Practi
ce, CN=Foo Bar/emailAddress=Foo.Bar@foo.bar.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:f6:4c:58:aa:bb:2b:80:71:fb:8f:21:f9:9d:03:
07:9e:91:58:b4:3a:6a:a6:fa:74:18:89:e1:99:a9:
45:79:70:ae:46:bd:91:22:62:9f:e0:d7:fd:d7:03:
c3:9e:10:36:f2:ef:37:52:cc:92:86:fa:c1:a7:3c:
08:af:4e:43:55:94:87:a1:22:ad:26:b3:f6:1b:65:
19:fe:81:50:92:84:a0:34:7a:b4:c7:2c:3e:45:b3:
7e:76:a7:44:87:e3:4b:75:9a:64:ea:81:c9:fa:94:
43:ad:b3:7a:75:92:87:89:fe:a5:8e:c6:5b:bb:59:
8d:50:e7:8b:75:9c:3a:47:6f
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Cert Type:
SSL Client, S/MIME
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
56:64:98:F2:33:16:62:82:2B:50:91:36:29:87:48:46:74:26:00:44
X509v3 Authority Key Identifier:
keyid:06:C7:E8:90:D1:04:7C:36:16:FE:AA:D2:B2:B6:EC:C4:13:84:36:A1
DirName:/C=JP/ST=Tokyo/L=Setagaya/O=Sun Microsystems K.K./OU=So
ftware Practice/CN=Hanako Yamada/emailAddress=Hanako.Yamada@foo.bar.jp
serial:00
Signature Algorithm: md5WithRSAEncryption
4b:ec:fe:fb:c2:33:50:7c:86:bb:0d:ba:a7:c6:94:49:38:bf:
49:92:4f:c3:40:71:d7:8c:15:b0:8e:19:38:ba:87:a6:04:6d:
07:c8:fa:82:1f:11:ae:e4:2b:d8:aa:be:cf:29:e8:bf:ac:e7:
2d:42:5b:9b:2e:ff:f4:b5:d9:00:e0:4c:92:57:44:93:f5:c6:
dc:c1:7a:45:f6:20:14:9b:cd:09:e2:5f:e7:31:d7:74:d0:4c:
22:37:bd:e3:e3:39:b5:be:0e:6a:97:4f:08:8c:89:46:f8:60:
0a:f2:48:73:b3:36:8a:8d:84:bd:64:0f:d0:6d:91:2d:1b:35:
08:e5
-----BEGIN CERTIFICATE-----
MIIEAjCCA2ugAwIBAgIBCjANBgkqhkiG9w0BAQQFADCBrTELMAkGA1UEBhMCSlAx
DjAMBgNVBAgTBVRva3lvMREwDwYDVQQHEwhTZXRhZ2F5YTEeMBwGA1UEChMVU3Vu
IE1pY3Jvc3lzdGVtcyBLLksuMRowGAYDVQQLExFTb2Z0d2FyZSBQcmFjdGljZTEW
MBQGA1UEAxMNSGFuYWtvIFlhbWFkYTEnMCUGCSqGSIb3DQEJARYYSGFuYWtvLllh
bWFkYUBmb28uYmFyLmpwMB4XDTA4MDMxODA3MTAxNFoXDTA5MDMxODA3MTAxNFow
gY8xCzAJBgNVBAYTAkpQMQ4wDAYDVQQIEwVUb2t5bzEeMBwGA1UEChMVU3VuIE1p
Y3Jvc3lzdGVtcyBLLksuMRowGAYDVQQLExFTb2Z0d2FyZSBQcmFjdGljZTEQMA4G
A1UEAxMHRm9vIEJhcjEiMCAGCSqGSIb3DQEJARYTRm9vLkJhckBmb28uYmFyLmNv
bTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA9kxYqrsrgHH7jyH5nQMHnpFY
tDpqpvp0GInhmalFeXCuRr2RImKf4Nf91wPDnhA28u83UsyShvrBpzwIr05DVZSH
oSKtJrP2G2UZ/oFQkoSgNHq0xyw+RbN+dqdEh+NLdZpk6oHJ+pRDrbN6dZKHif6l
jsZbu1mNUOeLdZw6R28CAwEAAaOCAUwwggFIMAkGA1UdEwQCMAAwEQYJYIZIAYb4
QgEBBAQDAgWgMCwGCWCGSAGG+EIBDQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0
aWZpY2F0ZTAdBgNVHQ4EFgQUVmSY8jMWYoIrUJE2KYdIRnQmAEQwgdoGA1UdIwSB
0jCBz4AUBsfokNEEfDYW/qrSsrbsxBOENqGhgbOkgbAwga0xCzAJBgNVBAYTAkpQ
MQ4wDAYDVQQIEwVUb2t5bzERMA8GA1UEBxMIU2V0YWdheWExHjAcBgNVBAoTFVN1
biBNaWNyb3N5c3RlbXMgSy5LLjEaMBgGA1UECxMRU29mdHdhcmUgUHJhY3RpY2Ux
FjAUBgNVBAMTDUhhbmFrbyBZYW1hZGExJzAlBgkqhkiG9w0BCQEWGEhhbmFrby5Z
YW1hZGFAZm9vLmJhci5qcIIBADANBgkqhkiG9w0BAQQFAAOBgQBL7P77wjNQfIa7
DbqnxpRJOL9Jkk/DQHHXjBWwjhk4uoemBG0HyPqCHxGu5CvYqr7PKei/rOctQlub
Lv/0tdkA4EySV0ST9cbcwXpF9iAUm80J4l/nMdd00EwiN73j4zm1vg5ql08IjIlG
+GAK8khzszaKjYS9ZA/QbZEtGzUI5Q==
-----END CERTIFICATE-----

実際に、ディレクトリサーバに格納するSubjectのDNは上記のSubjectのDNと逆の
下記の文字列を生成します。
上記の強調(ボールド)文字を下記のように変換してください。

E=Foo.Bar@foo.bar.com,
CN=Foo Bar, OU=Software Practice, O=Sun Microsystems K.K.,
ST=Tokyo,C=JP

次に、ディレクトリサーバに保存するクライアント証明書のバイナリを作成します。
下記のコマンドを実行してクライアント証明書のバイナリデータ(DER形式)を作成してください。

>
ls
client-private-key
clientcert.p12 clientcert.pem clientcsr.pem
> openssl x509 -in clientcert.pem -outform DER -out
clientcert.der

> ls
client-private-key
clientcert.der clientcert.p12 clientcert.pem
clientcsr.pem

ディレクトリサーバの該当のユーザにクライアント証明書と証明書のSubject DNを設定します。
ディレクトリサーバの該当のユーザを選択し、右マウスクリックで「汎用エディタで編集」を
選択してください。

汎用エディタで開くと下記の画面が表示されます。ここで、「オブジェクトクラス」に
マウスカーソルをあてて「値を追加」ボタンを押下して下さい。

「値を追加」ボタンを押下すると下記のウィンドウが表示されます。ここで、先ほど、
ディレクトリサーバに新しく追加したオブジェクトクラス「client-cert-person」を選択し、
「了解」ボタンを押下します。

上記の新規オブジェクトクラスを追加すると、下記の属性が現れます。

ここには、下記のクライアント証明書のSubject DNを入力してください。

E=Foo.Bar@foo.bar.com,
CN=Foo Bar, OU=Software Practice, O=Sun Microsystems K.K.,
ST=Tokyo,C=JP

次にクライアント証明書のバイナリファイルをディレクトリサーバに保存します。
証明書のバイナリファイルを追加するために、「属性の追加」ボタンを押下してください。

「属性の追加」ボタンを押下すると下記の画面が表示されます。ここで、「usercertificate」を
選択して、「サブタイプ」の「バイナリ」を選択して「了解」ボタンを押下してください。

※ 「usercertificate」の属性を「必須属性」ではなく、
「許可された属性」にしたのは理由があります。
Web サーバがクライアント証明書のSubjectDNで
パターンマッチを行った後、取得する属性は、
「usercertificate」ではなく「usercertificate;binary」です。
そこで、「許可された属性」で属性を追加する際に
「サブタイプ」で「バイナリ」を選択しなければ
なりません。「バイナリ」を選択することで
「usercertificate;binary」という属性が作成されます。
仮に必須属性にした場合デフォルトで、「usercetificate」
になりますので、この属性にクライアント証明書の
バイナリデータを入力しても「usercertificate;binary」
の属性は空ですので、証明書比較に失敗し、
全てのアクセスは拒否されてしまいます。
属性は、「usercertificate」ではなく
「usercertificate;binary」になっている事を
確認して下さい。

ディレクトリサーバのアクセスログより、実行された検索フィルタの確認

[18/Mar/2008:18:46:17 +0900] conn=252 op=1 msgId=2 – SRCH base=”dc=japan,
dc=sun,dc=com” scope=2 filter=”(certSubjectDN=E=Foo.Bar@foo.bar.com,CN=Foo
Bar,OU=Software Practice,O=Sun Microsystems K.K.,ST=Tokyo,C=JP)”
attrs=”uid userCertificate;binary”

「了解」ボタンを押下すると、下記の属性が追加されます。

上記は、ラジオボタンの「属性の名前を表示」を選択すると表示されます。

次に「値の設定」のボタンを押下してください。ボタンを押下すると下記の画面が表示されます。
ここで、事前に入手したクライアント証明書のバイナリ(DER)を指定して「了解」ボタンを押下します。

> ls
client-private-key
clientcert.der clientcert.p12 clientcert.pem
clientcsr.pem

「了解」ボタンを押下すると下記の画面に戻りますので、「了解」ボタンを押下して終了してください。

以上で、クライアント認証に必要な全てのデータの登録は完了です。
実際にユーザの情報が正常に登録されているかldapsearchコマンドを使用し確認してみましょう。

>ldapsearch -h localhost -p 389 -b “dc=japan,dc=sun,dc=com”
-D “cn=Directory Manager” -w adminadmin “(uid=foobar)”

version: 1
dn: uid=foobar,ou=People,dc=japan,dc=sun,dc=com
telephoneNumber: +81-3-1234-5678
sn: Bar
title: Solution Architect
givenName: Foo
uid: foobar
mail: Foo.Bar@foo.bar.com
cn: Foo Bar
userPassword: {SSHA}wWRFRscPqeZgMiKlih1VcRem5G1dQFBxqWLRfw==
objectClass: top
objectClass: person
objectClass: organizationalperson
objectClass: inetorgperson
objectClass: client-cert-persion
certSubjectDN: E=Foo.Bar@foo.bar.com, CN=Foo Bar, OU=Software Practice, O=Sun
Microsystems K.K., ST=Tokyo,C=JP
userCertificate;binary:: MIIEAjCCA2ugAwIBAgIBCjANBgkqhkiG9w0BAQQFADCBrTELMAkG
A1UEBhMCSlAxDjAMBgNVBAgTBVRva3lvMREwDwYDVQQHEwhTZXRhZ2F5YTEeMBwGA1UEChMVU3Vu
IE1pY3Jvc3lzdGVtcyBLLksuMRowGAYDVQQLExFTb2Z0d2FyZSBQcmFjdGljZTEWMBQGA1UEAxMN
SGFuYWtvIFlhbWFkYTEnMCUGCSqGSIb3DQEJARYYSGFuYWtvLllhbWFkYUBmb28uYmFyLmpwMB4X
DTA4MDMxODA3MTAxNFoXDTA5MDMxODA3MTAxNFowgY8xCzAJBgNVBAYTAkpQMQ4wDAYDVQQIEwVU
b2t5bzEeMBwGA1UEChMVU3VuIE1pY3Jvc3lzdGVtcyBLLksuMRowGAYDVQQLExFTb2Z0d2FyZSBQ
cmFjdGljZTEQMA4GA1UEAxMHRm9vIEJhcjEiMCAGCSqGSIb3DQEJARYTRm9vLkJhckBmb28uYmFy
LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA9kxYqrsrgHH7jyH5nQMHnpFYtDpqpvp0
GInhmalFeXCuRr2RImKf4Nf91wPDnhA28u83UsyShvrBpzwIr05DVZSHoSKtJrP2G2UZ/oFQkoSg
NHq0xyw+RbN+dqdEh+NLdZpk6oHJ+pRDrbN6dZKHif6ljsZbu1mNUOeLdZw6R28CAwEAAaOCAUww
ggFIMAkGA1UdEwQCMAAwEQYJYIZIAYb4QgEBBAQDAgWgMCwGCWCGSAGG+EIBDQQfFh1PcGVuU1NM
IEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUVmSY8jMWYoIrUJE2KYdIRnQmAEQwgdoG
A1UdIwSB0jCBz4AUBsfokNEEfDYW/qrSsrbsxBOENqGhgbOkgbAwga0xCzAJBgNVBAYTAkpQMQ4w
DAYDVQQIEwVUb2t5bzERMA8GA1UEBxMIU2V0YWdheWExHjAcBgNVBAoTFVN1biBNaWNyb3N5c3Rl
bXMgSy5LLjEaMBgGA1UECxMRU29mdHdhcmUgUHJhY3RpY2UxFjAUBgNVBAMTDUhhbmFrbyBZYW1h
ZGExJzAlBgkqhkiG9w0BCQEWGEhhbmFrby5ZYW1hZGFAZm9vLmJhci5qcIIBADANBgkqhkiG9w0B
AQQFAAOBgQBL7P77wjNQfIa7DbqnxpRJOL9Jkk/DQHHXjBWwjhk4uoemBG0HyPqCHxGu5CvYqr7P
Kei/rOctQlubLv/0tdkA4EySV0ST9cbcwXpF9iAUm80J4l/nMdd00EwiN73j4zm1vg5ql08IjIlG
+GAK8khzszaKjYS9ZA/QbZEtGzUI5Q==

最後に、ブラウザからWeb サーバに対して接続が可能か確認してみましょう。
作成したクライアント証明書を指定して「OK」ボタンを押下してください。

下記のように表示されれば正常にクライアント認証後にアクセスができています。

以上で、クライアント認証を行うために必要な設定はすべて完了です。
Webサーバ、もしくはProxyサーバをDMZに配置して、クライアント認証を
完了したユーザだけ、後段のアプリケーションサーバが提供するサービスを
うける為には、上記のような設定を行い実現できます。
リバース機能を設定する場合は、上記の設定を行った後で設定を行ってください。
ちなみに上記の設定は、他にSun Java System Proxy Server4.0.xでも同じような手順で設定を行います。
Web サーバ、Proxyサーバでクライアント認証を実現したい方は是非、本エントリを
是非参考にして頂ければと思います。

2008年3月19日 at 4:20 午前

Sun Business .Next 2008



2008年4月18日に六本木の東京ミッドタウンホールでSun Business .Next 2008

というイベントが開催されます。



Sun Business .Next 2008



本セミナーは、サン・マイクロシステムズが提供する最先端のテクノロジーや、

グローバル・ソリューションをあますところなくご覧頂ける総合イベントです



セミナーは大きく3つに分かれていていますが、私もコミュニティトラックの中で

発表させていただく事になりました。



● ソリューショントラック

● テクノロジートラック

● コミュニティトラック



15:35 – 16:20

C-4 Java:オープンソースの潮流と開発者コミュニティ



Java プラットフォームのオープンソース化の流れの中で、企業における

アプリケーション開発においても、コミュニティの重要性がますます高まっています。

そこで、このセッションでは、最近の Java 関連の話題からコミュニティに関係する

トピックを選んで紹介します。また、現在ホットな2つのコミュニティである NetBeans と

GlassFish について、それぞれを代表する Java エバンジェリストから現状を熱く語ってもらいます。





サン・マイクロシステムズ株式会社

Java エバンジェリスト

片貝正紀



サン・マイクロシステムズ株式会社

Java エバンジェリスト

寺田佳央



サン・マイクロシステムズ株式会社

Java エバンジェリスト

山口 浩



実は私も先ほど、プログラムを見たのですが、コミュニティトラックは

ブログやセミナーで有名なSolarisエバンジェリストの早々たるメンバーで

参加されるのですね!!

Solaris エバンジェリストの方々すごい!!



Java エバンジェリストも山口さんと片貝さんと僕で頑張ります!!



PS .

今、クライアント認証の下書き書いているのですが、すごい事になっています。

多分、今まで(世界中)で最も長いブログエントリーになりそう。

というか、そろそろブログでは限界かな。

気付くの遅い?

次のエントリは恐らく一部の方にしか為にはならないんじゃ?と思いますが、

世の中にはそういった要望もたくさんあるので、必要ない人は飛ばしてみてください。

2008年3月18日 at 8:35 午前

2. OpenSSLでクライアント認証「HTTPSサーバ構築編」

Translate to English / Google


前回は、Solaris 10に付属するOpenSSLで認証局を作成しました。

そこで、今回は作成した認証局でサーバ証明書を署名し、

Sun Java System Web Serverにサーバ証明書をインストールする手順までを

紹介します。





1. まず、はじめにWeb サーバ上で認証局でサーバ証明書を署名する為に

  証明書署名要求(CSR)を作成します。



Web サーバの管理画面より、構成より対象のインスタンス(ここではsw-120)を選択し、

「証明書」タブより、「サーバ証明書」タブを押下します。

すると、サーバ証明書の設定の画面で、「要求 …」ボタンがありますので、

「要求 …」ボタンを押下します。







「要求 …」ボタンを押下すると下記の画面が表示されます。ここでは使用可能なトークンを

選択する事ができます。



トークンは、例えば、Sun Crypto Accelerator 6000や、Sun Fire T2000のようなT1プロセッサ等の

H/Wのアクセラレータを使用するような場合に使用します。



このようなH/Wアクセラレータを使用する場合は、トークンを作成しますが、

このウィザードの画面では、それぞれの用途に応じたトークンを選択する事になります。

仮に、Webサーバ以外の物を使用しない場合は、デフォルトの「internal」を選択して下さい。

今回は、Webサーバの中に暗号を保存しますので、「internal」を選択します。

選択した後、「次へ」ボタンを押下してください。



補足:

WebサーバのSSLパフォーマンス

SSLの処理は暗号解析等を行うため、非常にシステムに対して負荷の掛かる作業を行っています。

そこで、SSLの処理を外部のH/Wアクセラレータ等を使用する事により、HTTPS通信における

パフォーマンスを向上させる事ができます。



また、現在RSAによる暗号化が主流ですが、将来的にはECC(楕円暗号化曲線)のアルゴリズムが主流

になる事が予想されます。



ECC(楕円曲線暗号)を使用する事によりRSAに比べ、暗号化強度を向上しても暗号化キーのサイズが

少なく済むため、ネットワーク帯域的にも、SSL処理に対する負荷も軽減できるようになります。

SJS Web Server 7.0 はこのECC もサポートしています。(RSAの場合、暗号化強度を高めるためには

キーサイズを大きくするしか方法はありませんが、ECCは、適用する曲線の選択を変更するだけです。

暗号化強度を強くしたい場合もサイズは比例して大きくなる事はありませんので、より暗号化強度が

必要な環境、もしくは大量のSSL通信が発生する環境の方がECCのメリットを実感できるようになります。)



Sun Java System Web Server 7.0 は下記をサポートしています。



Solaris 10 オペレーティングシステムを使用している場合は、カーネル SSL (KSSL) が使用できます。

SSL 用の暗号化カードハードウェアアクセラレータ(SCA 6000等)を使用してパフォーマンスを向上させることもできます。

Solaris で 64 ビットの Web Server を使用している場合は、UltraSPARC T1 プロセッサの暗号化アクセラレータを使用できます。



docs.sun.comより:SSLパフォーマンス













「次へ」ボタンを押下すると下記の画面が表示されます。ここでは、Webサーバの詳細を入力します。

ここで、注意すべき点は、組織 (o) の項目です。この部分は認証局(CA)を構築した際に、

Organization Name (eg, company)で指定した、組織名と完全一致する必要があります。

仮に異なる名前を入力した場合、認証局(CA)での署名に失敗しますので、注意して下さい。


Organization Name (eg, company) [Unconfigured OpenSSL Installation]:Sun Microsystems K.K.

</TD









次に、証明書のキーの種類を選択します。Sun Java System Web Server 7.0では、RSA,ECCを

サポートしていますので、何れかを選択して「次へ」ボタンを押下して下さい。















「次へ」ボタンを押下すると、下記の画面が表示されます。下記の画面は入力した内容を最終確認する画面です。

入力した内容に問題がない場合は、「完了」ボタンを押下して下さい。







「完了」ボタンを押下すると、下記の画面が表示されます。下記の画面はWebサーバから、認証局(CA)に対して

リクエストする「証明書署名要求(CSR)」の画面になります。ここで表示される、「BEGIN NEW CERTIFICATE REQUEST」から

「END NEW CERTIFICATE REQUEST」までの箇所をマウスで選択しコピー(Ctrl + C)して下さい。







コピーした上記の内容をファイルに保存してください。


> pwd

/.vfrCA/work/ssl/CA/server

> vi csr.pem


—–BEGIN NEW CERTIFICATE REQUEST—–
MIIB+zCCAWQCAQAwgYsxCzAJBgNVBAYTAkpQMQ4wDAYDVQQIEwVUb2t5bzERMA8G
A1UEBxMIU2V0YWdheWExHjAcBgNVBAoTFVN1biBNaWNyb3N5c3RlbXMgSy5LLjEa
MBgGA1UECxMRU29mdHdhcmUgUHJhY3RpY2UxHTAbBgNVBAMTFHN3LTEyMC5qYXBh
bi5zdW4uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDTAgjVmg7Hqxp3
18bhJP2WvDGXu62Pm7M+igkbQPz0KYiBpSqE9ur4N5J6WrTvECcG8GSzsqoQlRCo
MB9st1KEi9wvgbAgJRYrh3nv+G/B11jocZ731CzHnMS9hbRC8xC4P+mUz1RJMqkv
djJe5HUM3sx49yOLmK+bC7mXm2f6kwIDAQABoC8wLQYJKoZIhvcNAQkOMSAwHjAc
BgNVHREEFTATggZzdy0xMjCCCXdlYnNlcnZlcjANBgkqhkiG9w0BAQUFAAOBgQC4
NnM6s5pUGXu9nRcbCFV/yiH+Es1hIqcDzyC44exBCXpSWkdfj0ezcujLI+/Poe3V
pY5+BoaUPeqIus9dYJhqu07ANU2B1mZDNys8koizRqWMpFH2Kz0XGrlNQIXWWoa2
TyTt+glQhcvzHGnrC5Xpe+3QktmRk7P2uGVi3Ir3bg==

—–END NEW CERTIFICATE REQUEST—–


>



ファイルに保存した後、上記画面の「閉じる」ボタンを押下します。ボタンを押下すると

下記の画面が表示されますので、「配備保留中」のリンクを押下して下さい。







「配備保留中」のリンクを押下すると下記の新規ウィンドウが表示されます。ここで、「配備 …」ボタンを押下

して下さい。







「配備 …」ボタンを押下すると下記の画面が表示されます。ここで「インスタンスを再起動」で「今すぐ」を

選択し、「了解 …」ボタンを押下して下さい。

以上で、Sun Java System Web Server 上に自動的に秘密鍵が生成され、「証明書署名要求(CSR)」までが

生成されました。







次に、上記で作成した証明書署名要求(CSR)を元に、認証局(CA)で実際に署名を行う方法を紹介します。

まず、既存のopenssl.confのコピーを生成し、サーバ証明書を作成する為に若干設定変更を行います。


> cp /etc/sfw/openssl/openssl.cnf /etc/sfw/openssl/openssl-server.cnf


> vi /etc/sfw/openssl/openssl-server.cnf

basicConstraints=CA:FALSE <—FALSEに変更

# This is OK for an SSL server.

nsCertType = server <———- ここをコメント会うと



さてそれでは実際に、認証局で署名を行いましょう。

-config には先ほど修正したファイルを指定します。

-in にはWebサーバで生成した証明書署名要求(CSR)を指定します。

-keyfile には認証局の秘密鍵を指定します。

-cert には認証局の証明書を指定します。

-out には署名済みのWebサーバの生成されたサーバ証明書を指定します。


> openssl ca -config /etc/sfw/openssl/openssl-server.cnf -in ./csr.pem -keyfile
/etc/sfw/openssl/private/cakey.pem -cert /etc/sfw/openssl/cacert.pem -out cert.pem



Using configuration from /etc/sfw/openssl/openssl-server.cnf
29833:error:0E06D06C:configuration file routines:NCONF_get_string:no value:
/on10/build-nd/F10U4B12b/usr/src/common/openssl/crypto/conf/conf_lib.c:329:
group=CA_default name=unique_subject
Enter pass phrase for /etc/sfw/openssl/private/cakey.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
Serial Number: 1 (0x1)
Validity
Not Before: Mar 11 06:05:20 2008 GMT
Not After : Mar 11 06:05:20 2009 GMT
Subject:
countryName = JP
stateOrProvinceName = Tokyo
organizationName = Sun Microsystems K.K.
organizationalUnitName = Software Practice
commonName = sw-120.japan.sun.com
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Cert Type:
SSL Server
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
3C:08:1D:CA:8C:90:54:DB:F3:39:4F:E8:15:C3:90:4C:94:40:1C:D0
X509v3 Authority Key Identifier:
keyid:36:1F:D0:6B:95:99:BC:CB:FE:D9:C5:E6:F0:27:6B:36:96:89:E5:B0
DirName:/C=JP/ST=Tokyo/L=Setagaya/O=Sun Microsystems K.K./OU=Software
Practice/CN=Hanako Yamada/emailAddress=Hanako.Yamada@foo.bar.jp
serial:00
Certificate is to be certified until Mar 11 06:05:20 2009 GMT (365 days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated



ここで生成されたWeb サーバの証明書の中身を確認してみましょう。


> cat cert.pem


Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=JP, ST=Tokyo, L=Setagaya, O=Sun Microsystems K.K., OU=Software
Practice, CN=Hanako Yamada/emailAddress=Hanako.Yamada@foo.bar.jp
Validity
Not Before: Mar 11 06:05:20 2008 GMT
Not After : Mar 11 06:05:20 2009 GMT
Subject: C=JP, ST=Tokyo, O=Sun Microsystems K.K., OU=Software Practice,
CN=sw-120.japan.sun.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:d3:02:08:d5:9a:0e:c7:ab:1a:77:d7:c6:e1:24:
fd:96:bc:31:97:bb:ad:8f:9b:b3:3e:8a:09:1b:40:
fc:f4:29:88:81:a5:2a:84:f6:ea:f8:37:92:7a:5a:
b4:ef:10:27:06:f0:64:b3:b2:aa:10:95:10:a8:30:
1f:6c:b7:52:84:8b:dc:2f:81:b0:20:25:16:2b:87:
79:ef:f8:6f:c1:d7:58:e8:71:9e:f7:d4:2c:c7:9c:
c4:bd:85:b4:42:f3:10:b8:3f:e9:94:cf:54:49:32:
a9:2f:76:32:5e:e4:75:0c:de:cc:78:f7:23:8b:98:
af:9b:0b:b9:97:9b:67:fa:93
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Cert Type:
SSL Server
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
3C:08:1D:CA:8C:90:54:DB:F3:39:4F:E8:15:C3:90:4C:94:40:1C:D0
X509v3 Authority Key Identifier:
keyid:36:1F:D0:6B:95:99:BC:CB:FE:D9:C5:E6:F0:27:6B:36:96:89:E5:B0
DirName:/C=JP/ST=Tokyo/L=Setagaya/O=Sun Microsystems K.K./OU=Software
Practice/CN=Hanako Yamada/emailAddress=Hanako.Yamada@foo.bar.jp
serial:00
Signature Algorithm: md5WithRSAEncryption
89:19:7f:25:55:3b:00:23:33:42:95:67:be:13:22:16:ba:46:
c1:a4:d0:73:df:96:47:c8:2c:63:a9:50:7c:02:30:32:69:39:
1f:1f:c6:fc:5e:4d:e2:28:7b:a5:ba:ba:43:67:c0:72:6a:58:
f6:87:c4:02:5e:48:4d:a8:2b:79:1e:1a:14:03:aa:0e:62:7c:
9d:2e:d6:1f:15:d6:bd:75:59:d0:41:05:8d:a6:0c:24:11:b4:
c2:87:e0:87:ca:d8:ca:b4:5d:d5:87:b0:97:83:25:da:46:0c:
32:17:0d:30:9d:55:62:19:fe:9f:96:1f:d8:99:57:6d:4d:31:
55:05
—–BEGIN CERTIFICATE—–
MIID6jCCA1OgAwIBAgIBATANBgkqhkiG9w0BAQQFADCBrTELMAkGA1UEBhMCSlAx
DjAMBgNVBAgTBVRva3lvMREwDwYDVQQHEwhTZXRhZ2F5YTEeMBwGA1UEChMVU3Vu
IE1pY3Jvc3lzdGVtcyBLLksuMRowGAYDVQQLExFTb2Z0d2FyZSBQcmFjdGljZTEW
MBQGA1UEAxMNSGFuYWtvIFlhbWFkYTEnMCUGCSqGSIb3DQEJARYYSGFuYWtvLllh
bWFkYUBmb28uYmFyLmpwMB4XDTA4MDMxMTA2MDUyMFoXDTA5MDMxMTA2MDUyMFow
eDELMAkGA1UEBhMCSlAxDjAMBgNVBAgTBVRva3lvMR4wHAYDVQQKExVTdW4gTWlj
cm9zeXN0ZW1zIEsuSy4xGjAYBgNVBAsTEVNvZnR3YXJlIFByYWN0aWNlMR0wGwYD
VQQDExRzdy0xMjAuamFwYW4uc3VuLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw
gYkCgYEA0wII1ZoOx6sad9fG4ST9lrwxl7utj5uzPooJG0D89CmIgaUqhPbq+DeS
elq07xAnBvBks7KqEJUQqDAfbLdShIvcL4GwICUWK4d57/hvwddY6HGe99Qsx5zE
vYW0QvMQuD/plM9USTKpL3YyXuR1DN7MePcji5ivmwu5l5tn+pMCAwEAAaOCAUww
ggFIMAkGA1UdEwQCMAAwEQYJYIZIAYb4QgEBBAQDAgZAMCwGCWCGSAGG+EIBDQQf
Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUPAgdyoyQ
VNvzOU/oFcOQTJRAHNAwgdoGA1UdIwSB0jCBz4AUNh/Qa5WZvMv+2cXm8CdrNpaJ
5bChgbOkgbAwga0xCzAJBgNVBAYTAkpQMQ4wDAYDVQQIEwVUb2t5bzERMA8GA1UE
BxMIU2V0YWdheWExHjAcBgNVBAoTFVN1biBNaWNyb3N5c3RlbXMgSy5LLjEaMBgG
A1UECxMRU29mdHdhcmUgUHJhY3RpY2UxFjAUBgNVBAMTDUhhbmFrbyBZYW1hZGEx
JzAlBgkqhkiG9w0BCQEWGEhhbmFrby5ZYW1hZGFAZm9vLmJhci5qcIIBADANBgkq
hkiG9w0BAQQFAAOBgQCJGX8lVTsAIzNClWe+EyIWukbBpNBz35ZHyCxjqVB8AjAy
aTkfH8b8Xk3iKHulurpDZ8Byalj2h8QCXkhNqCt5HhoUA6oOYnydLtYfFda9dVnQ
QQWNpgwkEbTCh+CHytjKtF3Vh7CXgyXaRgwyFw0wnVViGf6flh/YmVdtTTFVBQ==
—–END CERTIFICATE—–

>



以上で、認証局(CA)による署名済みのサーバ証明書が生成されました。

署名済みのサーバ証明書が生成されましたので、ここで生成された証明書を

Web サーバにインストールしましょう。

Web サーバの管理画面より、「構成」→「対象の構成(sw-120)」を選択し、「証明書」タブを

選択後、「サーバ証明書」を選択して下さい。

「サーバ証明書」タブを選択すると「インストール …」ボタンが表示されますので、ボタンを

押下します。





「インストール …」ボタンを押下すると下記の画面が表示されます。ここでトークンを選択し、

「次へ」ボタンを押下して下さい。







「次へ」ボタンを押下すると下記の画面が表示されます。下記の画面では、署名済みの証明書から、

「BEGIN CERTIFICATE」から「END CERTIFICATE」までを画面内にコピー&ペーストして貼付けます。

コピー&ペーストした後「次へ」ボタンを押下して下さい。







「次へ」ボタンを押下すると下記の画面が表示されます。ここでは、Web サーバに保存する証明書の

ニックネームを入力します。

分かり易いニックネームを入力して、「次へ」ボタンを押下して下さい。







「次へ」ボタンを押下すると下記の画面を表示されます。ここではインストールする証明書の内容を

確認する画面になります。

問題がない場合は、「完了」ボタンを押下してください。







「完了」ボタンを押下すると下記の画面が表示されます。「Installation of Certificate successful」が

表示されれば、正常に認証局(CA)で署名されたサーバ証明書がインストールされています。









「完了」ボタンを押下すると、下記の画面が表示されます。ここで、「配備保留中」のリンクを押下して下さい。







「配備保留中」のリンクを押下すると下記の新規ウィンドウが表示されます。ここで、「配備」ボタンを

押下して下さい。







「配備」ボタンを押下した後、下記の画面が表示されますので、「了解」ボタンを押下し、

インスタンスを再起動して下さい。





「了解」ボタンを押下して下さい。ボタンを押下すると下記の画面が表示されます。







「閉じる」ボタンを押下すると、画面に下記のように表示されます。サーバ証明書が正常にインストール

されているか画面より確認して下さい。





上記までで、Web サーバのサーバ証明書のインストールが完了しました。しかしこの状態ではまだ、HTTPSの

通信ができません。そこで、HTTPSの通信ができるようにHTTPリスナーの設定を変更してみましょう。

「構成」→「対象の構成(sw-120)」を選択した後、「HTTPリスナー」タブを選択して下さい。

インスタンス中に存在する、HTTPのリスナー(http-listener-1)を選択して下さい。







HTTP リスナーを選択すると下記の画面が表示されます。ここで、「SSL」のタブを選択して下さい。



補足:

サーバ証明書の署名要求で設定した「サーバ名(cn)」と同一のサーバ名が下記で設定されていることを

確認して下さい。仮に署名要求で設定したサーバ名と、HTTPリスナー内のサーバ名が異なる場合は、

正常なサーバと認識されない為、サーバ名には御注意ください。

また、HTTPSのデフォルトのポート番号は443になります。443以外のポート番号が指定されている場合、

(デフォルトでは80等)はHTTPSの通信ができるように443に変更して「適用」ボタンを押下して先の手順に

進んでください。







「SSL」のタブを押下すると下記の画面に切り替わります。ここで、「SSL」のチェックボックスにチェックを付け

「適用」ボタンを押下して下さい。







「適用」ボタンを押下すると下記の画面が表示されます。「配備保留中」のリンクを押下して下さい。







「配備保留中」リンクを押下すると、下記の新規ウィンドウが表示されます。ここで、「配備」ボタンを

押下して下さい。







「配備」ボタンを押下すると下記の画面が表示されます。「インスタンスを再起動 今すぐ」にチェックを付け

「了解」ボタンを押下して下さい。







「了解」ボタンを押下した後、下記の画面が表示されます。「閉じる」ボタンを押下し、

完了して下さい。







次に、認証局(CA)の証明書をWeb サーバにインストールします。管理画面から「構成」→

「対象の構成(sw-120)」→「証明書」タブより「認証局」タブを押下して下さい。

すると下記の画面が表示されます。ここで「インストールボタン」を押下し認証局(CA)の証明書を

インストールする事ができます。



Pasted Graphic.tiff



「インストール」ボタンを押下すると下記の画面が表示されます。トークンを選択し、「次へ」ボタンを

押下して下さい。







「次へ」ボタンを押下すると下記の画面が表示されます。この画面で認証局(CA)の証明書を貼付けます。

証明書を貼付けた後「次へ」ボタンを押下してください。







認証局(CA)の証明書の入手先ですが、OpenSSLのディレクトリ配下にcacert.pemというファイルがありますので、

こちらの「BEGIN CERTIFICATE」から「END CERTIFICATE」までをコピー&ペースとしてご利用ください。


> less /etc/sfw/openssl/cacert.pem <–このファイルの内容を表示


—–BEGIN CERTIFICATE—–
MIID4jCCA0ugAwIBAgIBADANBgkqhkiG9w0BAQQFADCBrTELMAkGA1UEBhMCSlAx
DjAMBgNVBAgTBVRva3lvMREwDwYDVQQHEwhTZXRhZ2F5YTEeMBwGA1UEChMVU3Vu
IE1pY3Jvc3lzdGVtcyBLLksuMRowGAYDVQQLExFTb2Z0d2FyZSBQcmFjdGljZTEW
MBQGA1UEAxMNSGFuYWtvIFlhbWFkYTEnMCUGCSqGSIb3DQEJARYYSGFuYWtvLllh
bWFkYUBmb28uYmFyLmpwMB4XDTA4MDMxMTA1MzgxM1oXDTA5MDMxMTA1MzgxM1ow
ga0xCzAJBgNVBAYTAkpQMQ4wDAYDVQQIEwVUb2t5bzERMA8GA1UEBxMIU2V0YWdh
eWExHjAcBgNVBAoTFVN1biBNaWNyb3N5c3RlbXMgSy5LLjEaMBgGA1UECxMRU29m
dHdhcmUgUHJhY3RpY2UxFjAUBgNVBAMTDUhhbmFrbyBZYW1hZGExJzAlBgkqhkiG
9w0BCQEWGEhhbmFrby5ZYW1hZGFAZm9vLmJhci5qcDCBnzANBgkqhkiG9w0BAQEF
AAOBjQAwgYkCgYEAwrSQg6m9CizA7xXjS3yVAgUNklxKuM9uKT8foOby72RmTfvR
Uoi3dwUI00JxQDvBvmZPElOcL1qk6H7HEMCAffAJkPvvyBCTFNKH0GgIvCaSyQX1
tmx7IVpeae+jwKVRhwUwsz8X+njXdF9rhtwIPTq8QRj+G4BOtWVKPLet/PUCAwEA
AaOCAQ4wggEKMB0GA1UdDgQWBBQ2H9BrlZm8y/7ZxebwJ2s2lonlsDCB2gYDVR0j
BIHSMIHPgBQ2H9BrlZm8y/7ZxebwJ2s2lonlsKGBs6SBsDCBrTELMAkGA1UEBhMC
SlAxDjAMBgNVBAgTBVRva3lvMREwDwYDVQQHEwhTZXRhZ2F5YTEeMBwGA1UEChMV
U3VuIE1pY3Jvc3lzdGVtcyBLLksuMRowGAYDVQQLExFTb2Z0d2FyZSBQcmFjdGlj
ZTEWMBQGA1UEAxMNSGFuYWtvIFlhbWFkYTEnMCUGCSqGSIb3DQEJARYYSGFuYWtv
LllhbWFkYUBmb28uYmFyLmpwggEAMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEE
BQADgYEAjo9baqRceGPaZkKWm8eFSooa/b5cinz3v7qKxZKmKhsjZhyFne7BXCqY
umtzgycAgXkKzLyeyL/RulXtde1oubCIfAlzEhD3hp1MBbJ4/Pw7I6ixyf1kkrf7
+aJ3/KQBZrclXK1aGyjnQKOQE2XHGewUf+Ouk6v7B+TrERivZF0=
—–END CERTIFICATE—–



「次へ」ボタンを押下すると下記の画面が表示されます。ここでは認証局(CA)の証明書をインストールしていますので、

「CA 証明書」のラジオボタンにチェックを付け「次へ」ボタンを押下します。







「次へ」ボタンを押下すると下記の画面が表示されます。ここではインストールする認証局(CA)の証明書の確認を

行います。サブジェクトや発行者に記載されている内容を確認し「完了」ボタンを押下して下さい。







「完了」ボタンを押下すると下記の画面が表示されます。「閉じる」ボタンを押下しインストールウィザードを終了して下さい。







下記の画面では認証局(CA)の証明書が正しくインストールされているかを確認しています。インストールした認証局(CA)の

証明書は一覧の最後のエントリに記載されてますので、確認を行う際にはページを移動して確認を行ってください。







確認が終わった後、「配備保留中」のリンクを押下して下さい。







「配備」を行った後、インスタンスを再起動する必要がありますので、画面の内容に従い

インスタンスを再起動して下さい。









以上で、Web サーバに対するサーバ証明書のインストール作業は全て完了です。

この状態で、信頼されたHTTPS通信が可能なWeb サーバの構築が完了です。





次は、クライアントのブラウザからHTTPSの通信ができるかを確認してみましょう。

実際にクライアントのブラウザからアクセスする前に、ブラウザで1点だけ準備する事があります。

それは、認証局(CA)の証明書をブラウザにインストールしなければならない点です。


現在、Web サーバは自前のOpenSSLで構築した認証局(CA)で署名されたサーバ証明書を利用してHTTPSの
通信ができるように設定が完了していますが、クライアントのブラウザは自前で構築したOpenSSLの認証局(CA)
を信頼する設定にはなっておりません。そこで、OpenSSLの認証局(CA)で署名された全ての証明書を信頼する為に
クライアントのブラウザに対しても認証局(CA)の証明書をインストールする必要があります。
以下に、ブラウザに認証局(CA)の証明書のインストール手順を記載します。
ちなみに、下記はFirefoxを例にして記述しています。
Firefoxのメニューより、「環境設定」を選択して下さい。すると下記のような新規ウィンドウが表示されます。
この中で、「詳細」→「暗号化」タブを選択し、「証明書を表示」ボタンを押下して下さい。







「証明書を表示」ボタンを押下すると下記のような画面が表示されます。この中で「認証局証明書」タブを

選択し「インポート」ボタンを押下して下さい。







「インポート」ボタンを押下するとファイルダイアログが表示されますので、事前に認証局(CA)より

FTP等で入手しておいたcacert.pemを指定して「開く」ボタンを押下します。







ボタンを押下すると下記の画面が表示されますので、全てのチェックボックスにチェックを付け

「OK」ボタンを押下して認証局(CA)のインストールを完了します。







認証局(CA)の証明書が正しくインストールされているかを確認してみましょう。

下記のように、証明書名と発行者名中に独自で作成した証明書が表示されていれば問題ありません。

念のため、証明書を確認してみましょう。対象の署名書を選択し「表示」ボタンを押下してください。







「表示」ボタンを押下すると下記の画面が表示されます。この認証局(CA)の証明書では、

認証局で署名された、クライアント証明書やサーバ証明書、メール署名者の証明書、メール受信者の

証明書等を信頼できるようになっています。







以上で、クライアントであるブラウザ側の準備も完了しました。

それでは、実際にブラウザからWebサーバにHTTPSで通信を行ってみましょう。

警告画面等が表示されずに正常にHTTPSの通信ができたでしょうか?

ブラウザの鍵の絵の部分をダブルクリックすると「ページ情報」を表示する画面が表示されます。

内容を確認すると、このサイトへの接続は検証されており、信頼していますというメッセージが

表示されているかと思います。









以上で、OpenSSLを使用したセキュアなWebサーバの構築が完了です。

次回は、いよいよクライアント認証の設定方法について紹介します。





すいません、体裁が悪くて、これから外出で直前でアップしましたので、

体裁は後で綺麗にしなおします。


2008年3月13日 at 10:10 午後

過去の投稿


Java Champion & Evangelist

Translate

ご注意

このエントリは個人の見解であり、所属する会社の公式見解ではありません

カレンダー

2008年3月
 12
3456789
10111213141516
17181920212223
24252627282930
31  

カテゴリー

Twitter

clustermap

ブログ統計情報

  • 1,263,765 hits

RSSフィード

アーカイブ