Getting Started with Secure Connections

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

Introduction

The following text will explain how to get secure connections from the CIM client to the CIM Object Manager and vice-versa (for indications) working.

SSL/TLS may provide

  • confidentiality - no third party can read the content of the communication.
  • integrity - no third party can alter the content of the communication unnoticed.
  • authentication - the identity of one or both partners is confirmed.
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 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 it's 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 our 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 we 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 does not support truststores.

The described mechanism would enforce every receiver to have the certificate of every trusted sender stored in it's truststore. Certificate chains were invented to get around this. In a certificate chain an organization certifies the autheticity of an entities certificate and the receiver just validates the authenticity of the organizations 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 release does not use truststores, the configurations 2 and 4 are not supported.

Configurations for client connections

ConfigurationEncryption/HashingCIMOM authentifiedClient authentifiedSecure indication
listeners supported
Notes
No authenticationyesnonono 
CIMOM authenticationyesyesnonoNot yet implemented
Client authenticationyesnoyesyes 
Mutual authenticationyesyesyesyesNot yet implemented

"No authentication" configuration

  • Confidentiality: given
  • Integrity: given
  • Authentication: no
  • Keystore: No
  • Truststore: No

To open a 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. We also decided not to send any X509 certificate to the CIMOM to authenticate ourselves. Well, 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 is configured not to check client certificates.

-->

"Client authentication" configuration

  • Confidentiality: given
  • Integrity: given
  • Authentication: client only
  • Keystore: Required
  • Truststore: No

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. 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 where to find it. There are two possibilities:

    -->
  • Setting https.keystore.path and https.keystore.password to the keystore path/password in the cim.defaults (aka cimclient.properties) file.
  • Use org.sblim.wbem.util.SessionProperties.setKeystore() and setKeystore_password() at runtime.
-->