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. |
|
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
2
It's quite likely your current certificate was generated by the method detailed in this article.
|
|
Thanks for clarifying - now that I plan to use the same tool - iKeyMan to generate.
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).
|
|
Hi,
Using ikeyman tool I could generate .JKS file as shown below. Can someone guide from here.
|
|
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.
|
|
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.
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.