Getting Started with Secure Connections
IntroductionAuthentication 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.
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
Configuration | Encryption/Hashing | CIMOM authentified | Client authentified | Secure indication listeners supported | Notes |
---|---|---|---|---|---|
No authentication | yes | no | no | no | |
CIMOM authentication | yes | yes | no | no | Not yet implemented |
Client authentication | yes | no | yes | yes | |
Mutual authentication | yes | yes | yes | yes | Not 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
andhttps.keystore.password
to the keystore path/password in the cim.defaults (aka cimclient.properties) file. - Use
org.sblim.wbem.util.SessionProperties.setKeystore()
andsetKeystore_password()
at runtime.