To set up SSL, you must generate a keystore to be used by the JMX agent’s RMI adapter. For detailed information about keystores, see the Sun Web page. Use this syntax to generate the keystore for each JMX agent installed in the network:
keytool [-alias <alias>] \ -genkey -v -keystore <keystore> \ -storepass <storepwd> -keypass <keypass> \ -dname <dname> \ -validity <validity>
Where:
The keytool executable is located in the jdk/jdk1.4/bin subdirectory of your EAServer installation.
<alias> is the alias used for the key. If omitted, it defaults to “mykey”.
<keystore> identifies the keystore.
<storepwd> is the password used to protect the keystore itself.
<keypass> is the password used to protect the key being generated.
<dname> is a distinguished name; for example:
“CN=Chris Jobson, O=Sybase\, Inc., C=UK”
<validity> is the number of days the key is valid; for example, 365 (one year).
This example generates a keystore and a key, then puts the new key in the keystore:
keytool -genkey -v -keystore key.store -storepass storepwd -keypass keypwd \ -dname "CN=Chris Jobson, O=Sybase\, Inc., C=UK" -validity 365
Next, you must export the X.509 certificate that authenticates the key you just created:
keytool [-alias <alias>] -export \ -v -storepass <storepwd> -keystore <keystore> -file <certfile>
Where, in addition to the variables described in the previous example:
<certfile> is the name of the certificate file.
This example exports the X.509 certificate:
keytool -export -v -storepass storepwd -keystore -file x509cert
Once you have exported the key (in the X.509 certificate), you must import it into the truststore used by the clients that connect to the RMI adapter. Currently, the only clients run in servlets that are deployed in EAServer. Import the certificate into a truststore located in the servlet’s WEB-INF/lib directory, located under $JAGUAR/Repository/WebApplication/SysMgmtm/. You must copy the x509cert file to the same machine where the servlet is deployed, and then import it using this syntax:
keytool [-alias <alias>] -import \ -v -storepass <storepwd> -keystore <truststore> -file <certfile>
Where, in addition to the previously defined variables:
<truststore> is the truststore to be used by the clients.
This example creates a truststore, which contains a single certificate that wraps the original key, and puts the X.509 certificate in C:\tmp\x509cert:
keytool -import -v -storepass storepwd -keystore trust.store \ -file C:\tmp\x509cert
Delete the X.509 certificate after using it.
Do this for all clients that will connect to the JMX agent. After creating the various keys and truststores, you must ensure that the JMX agent starts the RMI adapter so that it uses SSL. To do this, make these changes to the boot.xml file:
Locate the definition for the sybase.system.adaptor.service:Name=SSLServerSocketFactory MBean, then set the appropriate values for its KeyStoreName, KeyStorePassword, and KeyManagerPassword attributes:
Locate the definition for the sybase.system.adaptor:Protocol=RMI-JRMP MBean, and to ensure that the JMX agent starts and the RMI adapter accepts only SSL connections, verify that the SSLFactory attribute is set to “sybase.system.adaptor.service:Name=SSLServerSocketFactory”.
The RMI adapter exports its certificate, which is checked by the client using its truststore. Therefore, the client can verify that the server is who it purports to be.
To configure the servlet to use SSL to connect:
Change to the ROOT/WEB-INF/classes/com/sybase/servlet/jmx directory.
In each <agent>.properties file—there is one for each agent that is defined—verify that the com.sybase.management.jmx.adaptor.rmi.truststore.resource property is set to point to the truststore that contains the trusted certificate for the appropriate JMX agent. For example:
com.sybase.management.jmx.adaptor.rmi.truststore.resource= /clienttrust.store
/clienttrust.store is
loaded by appropriate class loaders, and should load the truststore
created by the keytool -import command. To load
a truststore from another location, verify that it can be loaded
by the class loader used to load the servlet, or use one of these
alternate properties, and set the location appropriately:
com.sybase.management.jmx.adaptor.rmi.truststore.url – requires a property value in this format:
<protocol>:<value>
For example, file:<location> or http://<host>:<port>/location.
com.sybase.management.jmx.adaptor.rmi.truststore.file – the property value must be a path to the truststore.
Each JMX agent requires its own trusted certificate; they can all be stored in the same truststore, or in separate ones.
If you are not using SSL, remove the trust_store property
from the properties file.
The server can also verify whether the client is presenting a valid certificate. This is the inverse of the process described above. The server has a truststore it consults to verify that the client’s certificate matches. To set this up, create keystores for the clients, and matching truststores for the server (containing the exported key). Follow the steps outlined above using keytool, then:
In boot.xml, locate the definition for the com.sybase.system.adaptor.service:Name=SSLServerSocketFactory MBean, then edit the values for the TrustStoreName, TrustStorePassword and NeedClientAuth attributes appropriately:
On the client end, edit the agent.properties file, and set the value of the com.sybase.management.jmx.adaptor.rmi.keystore.resource property to point to the keystore containing the certificate for the relevant JMX agent. The resource is loaded by the appropriate class loaders, and should load the keystore that was created using the keytool -genkey command.
Alternately, set the values for these properties:
com.sybase.management.jmx.adaptor.rmi.keystore.url – requires a property value in this format:
<protocol>:<value>
For example, file:<location> or http://<host>:<port>/location.
com.sybase.management.jmx.adaptor.rmi.keystore.file – a path to the keystore.
com.sybase.management.jmx.adaptor.rmi.keymanager.password – the key manager password used to create the key that is located in the keystore.
| Copyright © 2005. Sybase Inc. All rights reserved. |
|
|
