How to request and configure an SSL cerificate for CLM 501 running Apache Tomcat
Hi,
Currently we are in the process of migrating the existing CLM 501 environment on to a new hardware.
In the current server we noticed that in the directory - C:\Program Files\IBM\JazzTeamServer\server\tomcat
There is a file - ibm-team-ssl.keystore that come along with the installation
Also noticed two new files - Look like these files are obtained from the self signed certificate authority
abc-team-ssl.jks and abc-team-ssl.jks.qer
What we are trying to find out is - Do we need to generate some files from Apache Tomcat and sent to Identity Management Team for getting it signed.
Note: In websphere there is way we can generate a file then sent it to the identity management team and import the signed certificate back into WAS. Following this way can get pass the browser exception error.
11 answers
It might be helpful to refer to the online help : install a security certificate. There is ikeyman.exe (The keytool program) is located in the JazzInstallDir/server/jre/bin/ directory.
Comments
You can confirm the certificate when opening the .jks file in the ikeyman.
Another thread https://jazz.net/forum/questions/120873/setup-new-ssl-certificate-to-rtc-40.
Hi - I saw this reference late and tied running the command
C:\Program Files\IBM\JazzTeamServer501\server\jre\bin>keytool.exe -genkey -alias
tomcat_test -keyalg RSA -- Dont see anyfile generated in bin directory.
First, check the Tomcat server.xml file for the property "keystoreFile" for the SSL connection realm and determine which keystore is being used by the current server. You would want to use the same keystore in the new environment if possible. You can ignore the one not being used.
As a certificate is normally bound to an FQDN, if you don't change the public URI of the CLM server (i.e. the clients use the same URL to access CLM applications), you don't need to get the certificate re-issued. Just copy the keystore (and the password stash if appropriate) over to the new environment and you are good to go.
As a certificate is normally bound to an FQDN, if you don't change the public URI of the CLM server (i.e. the clients use the same URL to access CLM applications), you don't need to get the certificate re-issued. Just copy the keystore (and the password stash if appropriate) over to the new environment and you are good to go.
Hi,
Let me put this in other way - How to place a certificate request / generate a >> cert_req.arm) file using Apache as the web server.
When we looked at the server.xml file noticed it is pointing to the KeystoreFile generated by CA.
Here in the snapshot below , the file extension .JKS and .QER is the one currently being used.
Going through the CLM Parent documentation there is a reference to Keytool documentation
Can someone confirm the same and let me know if there is a proper syntax mentioning the correct parameters.
C:\Program Files\IBM\JazzTeamServer501\server\jre\bin>keytool.exe -help
keytool usage:
-certreq [-v] [-protected]
[-alias <alias>] [-sigalg <sigalg>]
[-file <csr_file>] [-keypass <keypass>]
[-keystore <keystore>] [-storepass <storepass>]
[-storetype <storetype>] [-providerName <name>]
[-providerClass <provider_class_name> [-providerArg <arg>]] ...
[-providerPath <pathlist>]
Comments
Here we are starting from the scratch as we are moving to a new hardware.
On the existing from where I have posted the snapshot - the keys were requested and configured years back
It's quite likely your current certificate was generated by the method detailed in this article.
http://www.ibm.com/developerworks/rational/library/create-server-side-certificates-collaborative-lifecycle-management/
Note that it uses iKeyMan, not keytool. If you want to use keytool, you can follow these steps instead.
http://docs.oracle.com/cd/E19798-01/821-1841/gjrgy/index.html
2 votes
Thanks for clarifying - now that I plan to use the same tool - iKeyMan to generate.
- Now that I have generated the clm_staging_keys.jks file -
- Hope this file can be sent to our CA to get it signed.
- Once we receive the signed certificate back.
- Will be copying the signed certificate back to the tomcat directory.
- In the next step - update the Tomcat - Server.xml file with the new Keyfile name and password.
- Restart the tomcat services.
Other question we have is - Currently we use distributed topology (separate server for JTS / CCM / QM and RM) and is it required to repeat the same activity on each server.
Following the URL - http://www.ibm.com/developerworks/rational/library/create-server-side-certificates-collaborative-lifecycle-management/ using iKeyMan.exe could generate the certreq.arm file
The file was sent to Identity Management team to get it signed.
In return have received four files back with extension *.cer
Now the question is :- Should we import these four files into Apache Tomcat. OR
How to import the .Cert files into Apache Tomcat. Dont see any document relevant to this.
Note: In the current PROD we see the files which is mentioned in server.xml file have .JKS extension.
Comments
You need to understand what is a key, a certificate, and a key store. The files that you listed are certificates, and you need to import them into the key store. Follow the steps in the following document (see section: Receiving a CA-signed certificate).
http://www-01.ibm.com/software/webservers/httpservers/doc/v1312/ibm/9atikeyu.htm
Dear Team,
Here is what I have followed by referring to the article : Section - Receiving a CA-signed certificate
http://www-01.ibm.com/software/webservers/httpservers/doc/v1312/ibm/9atikeyu.htm
Following this way we have opened the keys.jks DB file from the C:\ drive.
Here as seen above we have received four certificates signed by CA -- *.CER file - Tried receiving the one that has hostname,
Could see the name - clmstaging which was provided at the time of creating a new certificate request.
Now verifying the key.jks file size -- have increased to 4 kb
When tried to receive the remaining set of .CER file following the same way. It is throwing the below error.
Not sure what is wrong here.
With what has worked we have updated the server.xml file to point to the key.jks file . When tries loading the JTS page it still ask for browser exception.
Comments
The error is expected as the other certificates are "CA's certificates", not personal certificates. You should follow the instructions in the section "Storing a CA's certificate" in the same document to add them to the key store.
1 vote
Hi Don,
The same I have referenced earlier but unable to trace the
Select Signer Certificates in the Key Database content frame, then click the Add button.
In the below screen
Click on the downward arrow next to "Personal Certificates" and you should see something like this.
1 vote
Testing around this - I have noticed another issue - now we have recieved signed certificates only for our JTS server.
We also have CCM, QM and RM server running separately.
After importing the signer certificates on JTS Server . When tested using browser and it pass without any issues.
https://jtsservername:9443/jts/admin
Where as when tried loading the CCM URL - https://ccmservername:9443/ccm/web it is asking for browser exception same for RM and QM.
Question I have is :- Do we need to request separate signed certificate for each application (CCM,QM and RM) and import it using iKeyman tool.
Currently I tried copying the same *.jks file we have on JTS server over to the QM, CCM and RM server.
The JKS file name is mentioned as - rm_staging_cert.jks not sure if this make any difference.
One more clarification I am looking for is - Since we use distributed topology ( different server for JTS, CCM, QM and RM)
Why do we need separate signed certificates for each server apart from JTS server.
For example when we try to access https://<rmserver>:9443/rm/web
An additional window (JTS Server) will pop up asking for authentication. The authentication happens via JTS server. (Snapshot is attached below)
My thinking is why don't we import the signed certificate on JTS server then copy it across to other servers (CCM, RM and QM) updating the respective server.xml file
End Goal is - When the end-user navigate to the application URL it should pass the browser exception.
I did receive separate signed certificate for our RM server and when tested it throw the above cypher overlap error.
Any suggestions would be of great help.
page 1of 1 pagesof 2 pages