GlassFish SSLの設定 (サーバ証明書の設定)
※ 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: 未分類.
寺田 佳央 - Yoshio Terada 