Getting Started with Secure Connections

Introduction
Authentication basics
"No authentication" configuration
"CIMOM authentication" configuration
"Client authentication " configuration
"Mutual authentication" configuration
Indications
Creation of a keystore
Export of a certificate
Creation of a truststore
Import of a certificate
Configuration parameters for secure connections
Custom socket factories

Introduction

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

Confidentiality is ensured by encryption of any data sent over the network. Integrity is ensured by hashes of the data that can be used by the receiver to detect any changes. Authentication is implemented by exchanging X509 certificates between client and CIMOM. Note that SSL/TLS authentication is on a communication endpoint scope and not on a user scope. It ensures that two systems talking to each other really have the identities they proclaim. User authentication is usually done on an application level (here CIMOM) in addition to SSL/TLS.

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.

Authentication basics

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.

Configurations for client connections

ConfigurationEncryption/HashingCIMOM authenticatedClient authenticatedSecure indication
listeners supported
No authenticationyesnonono
CIMOM authenticationyesyesnono
Client authenticationyesnoyesyes
Mutual authenticationyesyesyesyes

"No authentication" configuration

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.

"CIMOM authentication" configuration

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.

"Client authentication" configuration

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.

"Mutual authentication" configuration

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.

Indications

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.

Creation of a Keystore

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:

Creation of a Truststore

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:

Import of a Certificate

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
Please refer to the CIMOM's documentation regarding the export of the CIMOM's certificate.

Export of a certificate

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
Please refer to the CIMOM's documentation regarding the import of the certificate into the CIMOM's truststore.

Configuration parameters for secure connections

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.

Custom socket factories

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.