The following text will explain how to get secure connections from the SBLIM CIM Client for Java to the CIM Object Manager and vice-versa (for indications) working.
SSL/TLS may provide
The more complex part of SSL/TLS setups is the authentication. If you can live without it, things get much easier. Below you'll find a table with the possible configurations. The higher the number the more complex and secure it becomes. Keep in mind that you cannot choose the security configuration independently of your counterpart (the CIMOM), e.g. if the CIMOM defines client authentication as mandatory you cannot get around it. Vice-versa if the CIMOM doesn't care about client authentication you might send as many certificates you want - it will never ever evaluate them.
SSL/TLS authentication is X509 certificate-based. Each side provides a X509 certificate that confirms its identity. The certificates are exchanged and each side validates the received certificate against a local copy.
To store the certificates two files are used. The first is the so-called keystore and contains your own certificate with all private and public key information. The second is the so-called truststore and contains local copies of certificates from other systems you trust. These copies contain only the public key information.
How to create a keystore for Java is explained here. As of today, the SBLIM CIM Client for Java does not support truststores.
The described mechanism would enforce every receiver to have the certificate of every trusted sender stored in its truststore. Certificate chains were invented to get around this. In a certificate chain an organization certifies the authenticity of an entity's certificate and the receiver just validates the authenticity of the organization's certificate. Therefore with just the certificate of the organization in the truststore the receiver can validate all entities that have certificates based on the organization's certificate.
The table below shows the possible configurations. Note that since the current SBLIM CIM Client for Java release does not use truststores, the CIMOM and mutual authentication configurations are not supported.
Configuration | Encryption/Hashing | CIMOM authenticated | Client authenticated | Secure indication listeners supported |
---|---|---|---|---|
No authentication | yes | no | no | no |
CIMOM authentication | yes | yes | no | no |
Client authentication | yes | no | yes | yes |
Mutual authentication | yes | yes | yes | yes |
To open an SSL/TLS-secured client connection to a CIMOM just make your client call as usual, but replace "http" by "https" as well as the non-secure port (usually 5988) by the secure port (usually 5989) in the CIMOM URL. That's all!
Note: In this scenario we decided not to evaluate the CIMOM's X509 certificate. The client is free to do that.
Note: We also decided not to send any X509 certificate to the CIMOM to authenticate ourselves. This will work only if the CIMOM is configured to ignore client certificates. If the CIMOM's configuration is to check certificates the connection will be refused by the CIMOM. Today the vast majority of CIMOMs are configured to not check client certificates.
When we want to check the identity of the CIMOM we need to create a truststore. Once this is set up, the client checks automatically the CIMOM certificate against the truststore. Everything else is equal to the "no authorization" configuration
Note: In this scenario we decided to evaluate the CIMOM's X509 certificate. In order to do that we have to import the CIMOM's certificate into our truststore. See importing a certificate for details.
Note: In this scenario we decided not to send any X509 certificate to the CIMOM to authenticate ourselves. This will work only if the CIMOM is configured to ignore client certificates. If the CIMOM's configuration is to check certificates the connection will be refused by the CIMOM. Today the vast majority of CIMOMs are configured to not check client certificates.
In order to enable the CIMOM to check our identity we have to send it a certificate. For that we need to create a keystore. Once this is set up, the client automatically sends our certificate on request by the CIMOM. Everything else is equal to the "no authorization" configuration.
Note: In this scenario we decided not to evaluate the CIMOM's X509 certificate. The client is free to do that.
Note: The CIMOM has to be enabled to validate our certificate. This can be done by either copying our certificate to the CIMOM's truststore, deducing our certificate from an organization certificate the CIMOM already trusts, copying our certificate to an organization's central certificate store (e.g. LDAP) the CIMOM queries, etc. See exporting a certificate for a description on how to export a certificate from your keystore so that you can import it into the CIMOM's truststore.
When we want to check the identity of the CIMOM we need to create a truststore.
Once this is set up, the client checks automatically the CIMOM certificate against the truststore.
In order to enable the CIMOM to check our identity we have to send it a certificate. For that we
need to create a keystore.
Once this is set up, the client sends automatically our certificate if the CIMOM requests it.
Everything else is equal to the "no authorization" configuration.
Note: In this scenario we decided to evaluate the CIMOM's X509 certificate. In order to do that we have to import the CIMOM's certificate into our truststore. See importing a certificate for details.
Note: The CIMOM has to be enabled to validate our certificate. This can be done by either copying our certificate to the CIMOM's truststore, deducing our certificate from an organization certificate the CIMOM already trusts, copying our certificate to an organization's central certificate store (e.g. LDAP) the CIMOM queries, etc. See exporting a certificate for a description on how to export a certificate from your keystore so that you can import it into the CIMOM's truststore.
If we want to receive indications on secure connections the SSL/TLS implementation will require the server side of a connection (that's us in this case!) to provide a certificate. It might be used for authentication, but more importantly provides a public key for the session key negotiation handshake. Therefore receiving indications on a secure connection requires either the "client authentication" or "mutual authentication" configuration.
To start a secure HTTP server to receive indications replace your unsecure call
HttpServerConnection indicationServer = new HttpServerConnection(connectionHandler, port);
with this
HttpServerConnection indicationServer = new HttpServerConnection(connectionHandler, port, true);
Don't forget to change "http" to "https" in the CIM_ListenerDestinationCIMXML instance when you subscribe.
Keystores hold public/private key pairs that are used to authenticate ourselves with others
and as asymmetric key to encrypt the handshake for the symmetric session key. The JVM provides a
tool that creates a keystore and generates keys: keytool
keytool
creates a file named keystore, generates a private/public key pair and stores it in the
file. Such a file that stores private/public key pairs for authentication ourselves with others is
called "keystore". Open a shell, change to your JVMs bin directory and enter:
keytool -genkey -alias mykey -keyalg RSA -validity 7 -keystore keystore
keytool
will ask you a lot of questions and finally request a password for the keystore. This password
is essential for later access to the keystore.
Now that we have created a key and a keystore we have to tell the SBLIM CIM Client for Java where to find it. There are three possibilities:
-Djavax.net.ssl.keyStore=<path> -Djavax.net.ssl.keyStorePassword=<password>
javax.net.ssl.keyStore
and javax.net.ssl.keyStorePassword
to the
keystore path/password using System.setProperty()
at runtime.javax.net.ssl.keyStore
and javax.net.ssl.keyStorePassword
to the
keystore path/password in the sblim-cim-client2.properties
file.Truststores hold public certificates that are used to authenticate others with ourselves. The JVM provides a
tool that creates a truststore: keytool
A truststore file is automatically created when you import
a certificate with keytool, see import of a certificate for details.
Once we have created a truststore we have to tell the SBLIM CIM Client for Java where to find it. There are three possibilities:
-Djavax.net.ssl.trustStore=<path> -Djavax.net.ssl.trustStorePassword=<password>
javax.net.ssl.trustStore
and javax.net.ssl.trustStorePassword
to the
truststore path/password using System.setProperty()
at runtime.javax.net.ssl.trustStore
and javax.net.ssl.trustStorePassword
to the
truststore path/password in the sblim-cim-client2.properties
file.If you want to import the public part of a CIMOM's certificate in your truststore you can do that with keytool:
keytool -import -alias mycimom -file mycimom.cer -keystore truststore
If you want to export the public part of your certificate to a file (e.g. for transfer to a CIMOM's truststore) you can do that with keytool:
keytool -export -alias mykey -keystore keystore -rfc -file mykey.cer
The configuration parametes can be found here. The properties beginning with
KEYSTORE_
, TRUSTSTORE_
or SSL_
control the SSL configuration.
Note: The SSL system properties globally configure the JREs SSL support. If you want to use settings different from the global
JRE configuration, you'll have to use WBEMClientSBLIM.setProperty()
to override the global setting. Keep in mind that
this applies only to the specific WBEMClient
instance. There is no way to set a global SSL configuration for the CIM
client independent from the JRE configuration.
You can pass your own SocketFactory
to the SBLIM CIM Client for Java by casting the WBEMClient
returned
from WBEMClientFactory.getClient()
to WBEMClientSBLIM
and calling the setCustomSocketFactory()
.
This setting applies only to this specific WBEMClient
instance.
By setting your own SocketFactory
you're bypassing the SSL configuration of the SBLIM CIM Client for Java. When creating
the SocketFactory
you set up your own SSLContext
that defines things like keystores, truststores,
algorithms, etc. Using your own SocketFactory
you may be able to get around any limitations of the SBLIM CIM
Client for Java's SSL/TLS support.