GlassFish SSLの設定 (サーバ証明書の設定)

2010年2月5日 at 6:29 PM

※ GlassFish で証明書の管理や鍵の管理を行う場合、
管理コンソールからは行えません.コマンドを使用してください.

SSLの設定(サーバ認証の設定)

クライアントのWebブラウザからサーバに対してSSL通信を行う場合,通常アプリケーションサーバの前段に配置するロードバランサもしくはリバースプロキシなどのシステムでSSL設定を行い,前段のシステムとアプリケーションサーバ間はSSLによる通信を行わない場合が多いです.しかしミッションクリティカルな環境では,前段のシステムとアプリケーションサーバ間もセキュアな通信路を確保する必要があリます.そのような場合,アプリケーションサーバ上でもSSLのサーバ証明書を設定する必要があります.ここでは前段のシステムからSSLで負荷分散されることを想定しクラスタ環境に対してSSLの設定を行う方法について紹介します.単一サーバインスタンスに対する設定を行う場合も基本的には同様の手続きで可能ですので参考にしてください.

今回紹介するクラスタ環境におけるSSL証明書管理の利点は,クラスタ構成に対して一度だけ設定を行えばクラスタに所属する全てのインスタンスに対して共通のSSL設定が有効になりますので,管理するマシンの台数が多い場合非常に便利です。
GlassFishのSSL設定はサーバ証明書のニックネームを変更する以外の殆どの設定操作をコマンドを使用して行います.そこで以下の説明では全ての操作をコマンドを使用して管理する方法を紹介します.

また,下記の手順は開発者プロファイル,クラスタプロファイル(Sun GlassFish Enterprise Server/OSS版GlassFish)を使用した場合の方法を紹介します.開発者プロファイル,クラスタプロファイルを使用する場合,証明書の管理にJava SEに付属するkeytoolを使用して管理します.エンタープライズプロファイル(Sun GlassFish Enterprise Server with HADB)を使用する場合は,NSS (Network Security Service)のcertutilコマンドやライブラリを使用します.certutilコマンドを使用した証明書管理方法は別途「GlassFish Enteprise Server管理ガイド」をご参照ください.

既存の自己署名証明書の確認

keytoolの-listコマンドを使用してGlassFishのインストール時に,デフォルトでインストールされている証明書を確認できます.証明書のキーストアはドメインのconfigディレクトリ中に存在しています.keystore.jksにはサーバ証明書などを格納します.またcacerts.jksには認証局(CA)の証明書などを格納します.

dashost > cd /export/home/appserv/domains/clusterDomain/config/
dashost > ls keystore.jks cacerts.jks
cacerts.jks keystore.jks
dashost > keytool -list -keystore ./keystore.jks -alias s1as -storepass changeit
s1as, 2009/12/03, PrivateKeyEntry,
証明書のフィンガープリント (MD5): E7:3A:3C:2A:F1:AE:7D:E8:72:0D:E5:A7:AE:87:97:DA
dashost > keytool -list -keystore cacerts.jks -alias s1as -storepass changeit
s1as, 2009/12/03, trustedCertEntry,
証明書のフィンガープリント (MD5): E7:3A:3C:2A:F1:AE:7D:E8:72:0D:E5:A7:AE:87:97:DA

鍵のペア(公開鍵および関連する非公開鍵)の生成

keytoolの-genkeypairコマンドを使用して鍵のペアを生成します.クラスタ環境では実際の接続先はクラスタに所属するノードエージェントのホスト名になるため,CNにワイルドカードでホスト名を指定(*.japan.sun.com)することをおすすめします.ワイルドカードを使用すると,実際の接続先がnodeagent1.japan.sun.comやnodeagent2.japan.sun.comであった場合も正当なサーバ証明書として利用できます.単一のサーバインスタンスに対するサーバ証明書を作成する際は,CNに対してサーバ名をFQDN(www.japan.sun.com)で指定してください.

dashost > keytool -genkeypair -alias cluster -keystore keystore.jks -keyalg RSA -keysize 2048 -validity 365 -dname “CN=*.japan.sun.com, OU=Software Practice, O=Sun Microsystems, L=Setagaya, ST=Tokyo, C=JP” -storepass changeit -keypass changeit

証明書署名要求(CSR)の生成

keytool の-certreqコマンドを使用して証明書署名要求(CSR)を作成します.クラスタ環境における実際の接続先はクラスタに所属するノードエージェント上のインスタンスになるため,ワイルドカードでホスト名を指定することをおすすめします.ワイルドカードを使用すると,実際の接続先がnodeagent1.japan.sun.comやnodeagent2.japan.sun.comであった場合も正当なサーバ証明書として利用できます.(単一のサーバインスタンスに対してサーバ証明書を作成する際は,*(アスタリスク)の代わりにサーバ名をFQDNで指定してください.)

dashost > keytool -certreq -alias cluster -keystore ./keystore.jks -file cluster.japan.sun.com.csr -storepass changeit

署名前のサーバ証明書の確認

下記のコマンドを実行しkeytoolで作成したCSRの内容を確認します.

dashost > openssl req -text -in ./cluster.japan.sun.com.csr
Certificate Request:
Data:
Version: 0 (0x0)
Subject: C=JP, ST=Tokyo, L=Setagaya, O=Sun Microsystems, OU=Software Practice, CN=*.japan.sun.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (2048 bit)
(省略)

認証局(CA)でサーバ証明書を署名

GlassFish 上で生成した CSR を元に認証局で署名を行います.

ca-server > openssl ca -in cluster.japan.sun.com.csr -keyfile ./demoCA/private/cakey.pem -cert ./demoCA/cacert.pem -out /tmp/signed-cluster.japan.sun.com.cert
Using configuration from /usr/local/ssl/openssl.cnf
Enter pass phrase for ./demoCA/private/cakey.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
Serial Number:
cd:ea:db:f4:c8:e3:93:8f
(省略)
Certificate is to be certified until Dec 3 11:23:45 2010 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

認証局(CA)でサーバ証明書をバイナリ(DER)形式に変換

keytool で証明書(鍵)データベースに保存するため,署名された証明書(signed-cluster.japan.sun.com.cert)をバイナリ(DER)形式(signed-cluster.japan.sun.com.der)に変換します.

ca-server > openssl x509 -in /tmp/signed-cluster.japan.sun.com.cert -outform DER -out /tmp/signed-cluster.japan.sun.com.der

認証局(CA)の証明書(cecert.pem)からX.509形式の証明書を準備

自己認証局によって署名されたサーバ証明書をGlassFishにインポートする前に,認証機関の証明書をGlassFishの証明書(鍵)データベースにインポートする必要があります.下記のように認証局のX.509形式のフォーマットを別ファイルにコピー&ペーストして保存してください.

dashost > vi cacert.x509
“cacert.x509” [新規ファイル]
—–BEGIN CERTIFICATE—–
MIIDmTCCAwKgAwIBAgIJAM3q2/TI45OEMA0GCSqGSIb3DQEBBQUAMIGQMQswCQYD
VQQGEwJKUDEOMAwGA1UECBMFVG9reW8xGTAXBgNVBAoTEFN1biBNaWNyb3N5c3Rl
bXMxGjAYBgNVBAsTEVNvZnR3YXJlIFByYWN0aWNlMRowGAYDVQQDExFjYS1zZXJ2
ZXIuc3VuLmNvbTEeMBwGCSqGSIb3DQEJARYPY2FhZG1pbkBTdW4uQ09NMB4XDTA5
MTEwOTA0NDAwOVoXDTEyMTEwODA0NDAwOVowgZAxCzAJBgNVBAYTAkpQMQ4wDAYD
VQQIEwVUb2t5bzEZMBcGA1UEChMQU3VuIE1pY3Jvc3lzdGVtczEaMBgGA1UECxMR
U29mdHdhcmUgUHJhY3RpY2UxGjAYBgNVBAMTEWNhLXNlcnZlci5zdW4uY29tMR4w
HAYJKoZIhvcNAQkBFg9jYWFkbWluQFN1bi5DT00wgZ8wDQYJKoZIhvcNAQEBBQAD
gY0AMIGJAoGBALbumBZl+9qUSGdxADtmgW8JRlriRmwOgOoYyrifayZz7to2SB09
+gk7alqzEFz1vFA2jUZu4X8veWMP/PLFvmjwPVXtSbk3HeRWosinb0ge49sX1/Nl
GOe90wGQzxci30O6V8FlHo1bWt9p/SSXZzLAtSn9Y5Au1GlpGHO4gL4hAgMBAAGj
gfgwgfUwHQYDVR0OBBYEFB24TDDMoTWycjWgisz6+RecxNJKMIHFBgNVHSMEgb0w
gbqAFB24TDDMoTWycjWgisz6+RecxNJKoYGWpIGTMIGQMQswCQYDVQQGEwJKUDEO
MAwGA1UECBMFVG9reW8xGTAXBgNVBAoTEFN1biBNaWNyb3N5c3RlbXMxGjAYBgNV
BAsTEVNvZnR3YXJlIFByYWN0aWNlMRowGAYDVQQDExFjYS1zZXJ2ZXIuc3VuLmNv
bTEeMBwGCSqGSIb3DQEJARYPY2FhZG1pbkBTdW4uQ09NggkAzerb9Mjjk4QwDAYD
VR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQAyiypjUnJBMMyy615ZYM3oOUYZ
3UgwLOnos/rGGCov9CIcxiLH8PcXc3IXRYgRFDqINRhSqfDrjt4YP9cz4QmEbNqy
9wPxrje4HPYZU+AKErN7Wt058dKFSeA+Wp2JsDiwdoARy4Ow/j/tkhVoOm07E3fM
TbEdS42dtkHlBgdSrw==
—–END CERTIFICATE—–

GlassFish 上で認証局の証明書をインポート

認証期間の署名書(cacert.x509)を,GlassFishが稼働するマシン上にコピーしそれぞれ証明書データベース,鍵データベースにインポートしてください.

dashost > keytool -import -file /tmp/cacert.x509 -trustcacerts -alias private-ca -keystore keystore.jks -storepass changeit
所有者: EMAILADDRESS=caadmin@Sun.COM, CN=ca-server.sun.com, OU=Software Practice, O=Sun Microsystems, ST=Tokyo, C=JP
発行者: EMAILADDRESS=caadmin@Sun.COM, CN=ca-server.sun.com, OU=Software Practice, O=Sun Microsystems, ST=Tokyo, C=JP
シリアル番号: cdeadbf4c8e39384
有効期間の開始日: Mon Nov 09 13:40:09 JST 2009 終了日: Thu Nov 08 13:40:09 JST 2012
証明書のフィンガープリント:
MD5: 7C:21:2B:4A:DF:A4:5D:BF:78:1D:56:22:54:3F:4E:48
SHA1: 00:3C:55:1E:34:60:FC:77:24:38:7E:64:39:C4:38:48:79:92:2F:31
署名アルゴリズム名: SHA1withRSA
バージョン: 3
(省略)
この証明書を信頼しますか? [no]: yes
証明書がキーストアに追加されました。

dashost > keytool -import -file /tmp/cacert.x509 -trustcacerts -alias private-ca -keystore cacerts.jks -storepass changeit
所有者: EMAILADDRESS=caadmin@Sun.COM, CN=ca-server.sun.com, OU=Software Practice, O=Sun Microsystems, ST=Tokyo, C=JP
発行者: EMAILADDRESS=caadmin@Sun.COM, CN=ca-server.sun.com, OU=Software Practice, O=Sun Microsystems, ST=Tokyo, C=JP
シリアル番号: cdeadbf4c8e39384
有効期間の開始日: Mon Nov 09 13:40:09 JST 2009 終了日: Thu Nov 08 13:40:09 JST 2012
証明書のフィンガープリント:
MD5: 7C:21:2B:4A:DF:A4:5D:BF:78:1D:56:22:54:3F:4E:48
SHA1: 00:3C:55:1E:34:60:FC:77:24:38:7E:64:39:C4:38:48:79:92:2F:31
署名アルゴリズム名: SHA1withRSA
バージョン: 3
(省略)
この証明書を信頼しますか? [no]: yes
証明書がキーストアに追加されました。

GlassFish上で認証局(CA)で署名されたサーバ証明書をインポート

認証局の証明書をインポートした後に,認証局で署名されたバイナリ(DER)形式のサーバ証明書を鍵データベースにインポートします。この時このサーバ証明書を識別するためのエイリアスとして cluster という名前を設定して実行します.

dashost > keytool -import -alias cluster -file /tmp/signed-cluster.japan.sun.com.der -keystore keystore.jks -storepass changeit
証明書応答がキーストアにインストールされました。


署名済みサーバ証明書をインポートした後,鍵データベースの内容を確認してみましょう.

dashost > keytool -list -keystore keystore.jks -storepass changeit
キーストアのタイプ: JKS
キーストアのプロバイダ: SUN
キーストアには 3 エントリが含まれます。
cluster, 2009/12/03, PrivateKeyEntry,
証明書のフィンガープリント (MD5): 2A:50:2A:50:1E:B9:3F:42:DB:4C:AF:8D:48:38:AB:05
private-ca, 2009/12/03, trustedCertEntry,
証明書のフィンガープリント (MD5): 7C:21:2B:4A:DF:A4:5D:BF:78:1D:56:22:54:3F:4E:48
s1as, 2009/12/03, PrivateKeyEntry,
証明書のフィンガープリント (MD5): B0:69:F8:C5:C0:09:44:D7:0C:9A:06:4B:33:53:E0:05


次に,インポートしたサーバ証明書をクラスタ環境で利用できるように,クラスタで使用するSSLのサーバ証明書ニックネームを全てs1asからcluster変更します.クラスタ設定で s1as を参照するSSLの設定一覧を表示し確認します.

dashost > asadmin get “*” | grep cluster1 | grep s1as
cluster1-config.admin-service.jmx-connector.system.ssl.cert-nickname = s1as
cluster1-config.http-service.http-listener.http-listener-2.ssl.cert-nickname = s1as
cluster1-config.iiop-service.iiop-listener.SSL.ssl.cert-nickname = s1as
cluster1-config.iiop-service.iiop-listener.SSL_MUTUALAUTH.ssl.cert-nickname = s1as
cluster1.admin-service.jmx-connector.system.ssl.cert-nickname = s1as
cluster1.http-service.http-listener.http-listener-2.ssl.cert-nickname = s1as
cluster1.iiop-service.iiop-listener.SSL.ssl.cert-nickname = s1as
cluster1.iiop-service.iiop-listener.SSL_MUTUALAUTH.ssl.cert-nickname = s1as


s1as の証明書ニックネームを参照している全ての設定をasadmin setコマンドを使用してclusterに変更します.

dashost > asadmin set cluster1-config.admin-service.jmx-connector.system.ssl.cert-nickname=cluster
dashost > asadmin set cluster1-config.http-service.http-listener.http-listener-2.ssl.cert-nickname=cluster
dashost > asadmin set cluster1-config.iiop-service.iiop-listener.SSL.ssl.cert-nickname=cluster
dashost > asadmin set cluster1-config.iiop-service.iiop-listener.SSL_MUTUALAUTH.ssl.cert-nickname=cluster
dashost > asadmin set cluster1.admin-service.jmx-connector.system.ssl.cert-nickname=cluster
dashost > asadmin set cluster1.http-service.http-listener.http-listener-2.ssl.cert-nickname=cluster
dashost > asadmin set cluster1.iiop-service.iiop-listener.SSL.ssl.cert-nickname=cluster
dashost > asadmin set cluster1.iiop-service.iiop-listener.SSL_MUTUALAUTH.ssl.cert-nickname=cluster


上記で,GlassFish のサーバ証明書の設定はすべて完了です.設定内容を反映させるため,最後にクラスタを再起動します.

dashost > asadmin stop-cluster cluster1
クラスタ化されたインスタンス instance1 の停止に成功しました。
クラスタ化されたインスタンス instance2 の停止に成功しました。
コマンド stop-cluster は正常に実行されました。
dashost > asadmin start-cluster cluster1
クラスタ化されたインスタンス instance1 の起動に成功しました。
クラスタ化されたインスタンス instance2 の起動に成功しました。
コマンド start-cluster は正常に実行されました。


ブラウザからアクセスして証明書の内容を表示すると,
ca-server.sun.comによって署名されたサーバ証明書を確認できます.

ブラウザでサーバ証明書の内容を確認

ブラウザでサーバ証明書の内容を確認

SSL 設定に関するデバッグ方法

最後に、SSLの設定に関するデバッグ方法を紹介します.SSLの設定で何らかの問題が発生した場合は,下記コマンドを実行して各インスタンスのログを確認してください.

dashost > asadmin create-jvm-options –target cluster1 “-Djavax.net.debug=ssl”
コマンド create-jvm-options は正常に実行されました。
dashost > asadmin stop-cluster cluster1
クラスタ化されたインスタンス instance1 の停止に成功しました。
クラスタ化されたインスタンス instance2 の停止に成功しました。
コマンド stop-cluster は正常に実行されました。
dashost > asadmin start-cluster cluster1
クラスタ化されたインスタンス instance1 の起動に成功しました。
クラスタ化されたインスタンス instance2 の起動に成功しました。
コマンド start-cluster は正常に実行されました。


証明書失効リスト(CRL)のチェック方法については下記のブログを参照してください.
http://weblogs.java.net/blog/kumarjayanti/archive/2007/11/ssl_and_crl_che.html

広告

Entry filed under: 未分類.

GlassFish ドメイン管理サーバのバックアップとリストア GlassFish SSLの設定(クライアント認証)


Java Champion & Evangelist

ご注意

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

カレンダー

2010年2月
« 1月   3月 »
1234567
891011121314
15161718192021
22232425262728

カテゴリー

Twitter

  • RT @backpaper0: てらださんには「テラダヨシオガンバル」って書かれたTシャツ着てほしい 4 hours ago
  • RT @sandayuu: 明日 DevOpsDays Tokyoなのですが、MR. Be Lazyの@DrewRobbins がマイクロソフトブースき来てくれることになりました!こら、質問するチャンスですよ! #DevOpsJP 9 hours ago
  • RT @navitime_tech: JJUG CCC 2017 Spring に日本マイクロソフト寺田様(@yoshioterada)と共同で登壇します。LUISを採用した理由、これからのAIやbot活用の可能性について話す予定です。https://t.co/wjRUbaNw… 3 days ago
  • RT @JJUG: JJUG CCC 2017 Spring(5/20)まで1ヶ月!コンテンツが出そろってきました。タイムテーブルをチェックして、行きたいコンテンツを確認してください。皆様のご参加をお待ちしております! buff.ly/2pGUNlu #jjug3 days ago
  • RT @vrize_inc: マイクロソフトのテクニカルエバンジェリストの方にhackfestを開催していただき、技術的な課題を一緒に解決しました。本社ブログに取り上げていただいてます!! blogs.technet.microsoft.com/livedevopsinja… 3 days ago

clustermap

ブログ統計情報

  • 944,169 hits

Feeds


%d人のブロガーが「いいね」をつけました。