In today's blog post I will be discussing securing different communication points in an Anywhere environment.
Securing communications between Mofile First and Maximo:
Using the iKeyman SSL tool on Windows to create and manage keystores, keys and certificates as well as provide some examples of how we can use this tool. We will describe the differences between self-signed and CA signed certificates, and will be creating a self-signed certificate for signing our own certificate request. Once signed, we will receive our certificates into the keystore our application will use.
iKeyman is shipped with WebSphere application server as well as many other IBM applications to manage keystores and certificates. Since WebSphere Application Server uses JKS keystores by default, we will use the iKeyman command line tool to create and work with our certificates and keystores.
There are command line and GUI versions of the iKeyman tool available but the GUI is limited in its functionality. For example, it does not provide a mechanism for adding a basic constraint to a certificate. Without the basic constraint, we cannot create a Certificate Authority type of signer certificate which is needed when using self-signed certificates for use with the Maximo application server. For this presentation, we will use the ikeycmd command line tool to accomplish all tasks related to the creation, signing, and receiving of signed certificates.
Self-signed vs CA signed certificates:
So, what are self-signed certificates? These are certificates that have been signed by themselves - The Subject and Issuer Distinguished Names are identical
- The Subject key identifier and authority key identifier are identical and the public key from the public/private key pair is used by client applications to validate the server's personal certificate
- A self-signed certificate can be created using most SSL tools quickly and is supported by most SSL enabled software or middleware. WebSphere application server provides facilities to create self-signed certificates within the administration console but does not provide a mechanism to set the basic constraints needed when creating a trusted CA certificate. The administration console is best used for creating a certificate request, to be signed by a third party.
- A self-signed certificate does not require a certificate request to be signed by a Certificate Authority since it is signed solely by itself.
- When a self-signed certificate is used as a personal certificate, it's typically only used for testing purposes because it is not trusted or known by external client applications without first being explicitly added and trust being enabled within the client application.
- The public portion of this type of certificate must be installed, and trust must be enabled in every client application that needs to be able to validate the personal certificate it receives from the server during the ssl handshake.
There are many benefits to using a Certificate Authority (or CA) signed certificates including insurance protection, guarantees made by the certificate authority against data loss or unauthorized access as well as revocation checking.
- In a CA signed certificate, the Subject and Issuer Distinguished Names are distinct from one another, whereby the issuer Distinguished name belongs to an established certificate authority such as Verisign, Comodo, Entrust, and others you probably have heard of before. These signer certificate are found in most software already, such as IE, Firefox, and many other types of software that employ digital cryptography. The top level certificate in the certificate chain is always a self-signed certificate, but is issued by a trusted certificate authority.
- The Subject key identifier of the CA certificate matches the authority key identifier specified on the personal certificate. Applications use these values to determine the path to the root level signer certificate.
- To obtain a CA signed certificate, a certificate request must be generated and sent to a Certificate Authority to be signed. Once signed and returned, the certificate is added to the key store. This process usually involves a fee for the certificate ranging in price.
- When used as a personal certificate for an application server such as Maximo, it is typically installed in a production environment where security and strict validation must be enforced.
- Certificates issued by Certificate Authorities are trusted and provide security assurances over self-signed certificates such as external CRL and OSCP revocation checking, enforcing stronger cipherspec and key size requirements during SSL handshaking, and preventing man-in-the-middle attacks.
- The top most signer certificate, known as the root certificate, must be installed on every client that needs to be able to validate the personal certificate it receives from the server during the SSL handshake.
Using the ikeycmd tool
Now we will perform the necessary commands using the iKeyman command line tool.
In the examples that follow, we will create two key stores. keyselfsigned.jks which will be used to create a self-signed certificate, and keypersonalcert.jks, which will be used to create a certificate request and to receive the final signed certificate. The keypersonalcert.jsk is the keystore that you would use with your application server since it will contain the final signed certificate along with the self-signed CA certificate.
A self-signed certificate will be used in this example as a Certificate Authority signer to sign the certificate request. This is the same type of process a certificate authority uses to sign certificate requests receive by customers.
Let's start by creating our keystores.
ikeycmd -keydb -create -db keyselfsigned.jks -pw 1234 -type jks
ikeycmd -keydb -create -db keypersonalcert.jks -pw 1234 -type jks
In these examples, we set the password for each key store to "1234", and specified the type jks which is used by java applications. The next command creates a self-signed certificate in keyselfsigned.jks key store and enables this certificate to be used as a signer certificate, in order to allow us to sign our personal certificate request. The resulting certificate is our CA signer.
ikeycmd -cert -create -db keyselfsigned.jks -pw 1234 -label mysigner -dn "cn=My self-signed Signer Certificate ou=Software Group o=IBM c=CA" -size 2048 -expire 365 -ca true
In this example, we created a self-signed certificate using the -cert -create parameters, specified the distinguished name between double quotes, set a label for identification purposes, and specified the size of the key to be 2048 bits in length. We also set the certificate expiry to 365 days, and added the critical basic constraint "ca" which we set to true.
Some implementations of SSL will not allow a signer certificate to act as a signer unless this critical basic constraint exists, and is set to true. This is the case for Firefox, and will prevent you from adding it to the certificate authority key repository if missing.
The next command will allow us to view the details of the certificate we just created:
ikeycmd -cert -details -label mysigner -db keyselfsigned.jks -pw 1234
Key Size: 2048
Version: X509 V3
Serial Number: 54 AF ED 9A
Issued by: CN="My self-signed Signer Certificate ou=Software Group o=IBM c=CA"
Subject: CN="My self-signed Signer Certificate ou=Software Group o=IBM c=CA"
Valid: From: Friday, January 9, 2015 10:02:50 AM EST To: Saturday, January 9, 2016 10:02:50 AM EST
- AuthorityKeyIdentifier: ObjectId: 126.96.36.199 Criticality=false
0000: 0e db 91 b7 a3 79 9d 4b .....y.K
- BasicConstraints: ObjectId: 188.8.131.52 Criticality=true
- SubjectKeyIdentifier: ObjectId: 184.108.40.206 Criticality=false
0000: 0e db 91 b7 a3 79 9d 4b .....y.K
Signature Algorithm: SHA1withRSA (1.2.840.1135220.127.116.11)
Trust Status: enabled
The -details parameters requires the -label parameter and a valid label name to be passed so we can see the full details of the certificate. In the output we can see that the Issuer and Subject names are identical which is: "My self-signed Signer Certificate". This is our new CA signer certificate.
Previously, we created the keypersonalcert.jks key store, which we will use to create the certificate request, to be signed and used for our application server.
ikeycmd -certreq -create -db keypersonalcert.jks -pw 1234 -label ibmwebsphereformaximo -dn "cn=My Personal Certificate ou=MQ o=IBM c=CA" -size 2048 -file personalcertreq.arm
The result is a certificate request created in the keystore, as well as a file called personalcertreq.arm whose contents will look similar to the output shown.
-----BEGIN NEW CERTIFICATE REQUEST-----