Sample generation and registration of a signed cert to Catalog JKS
search cancel

Sample generation and registration of a signed cert to Catalog JKS


Article ID: 96537


Updated On:


CA Service Catalog CA Service Management - Asset Portfolio Management CA Service Management - Service Desk Manager


This shows one example of generating an SSL signed certificate to enable HTTPS and then registering it to Service Catalog's JKS. This would also work for USS, SDM, or other sites using java keytool.


CA Service Management 17.3


Important notes before we begin:

  • Please remember that keytool is a java utility and is supported by Oracle should you run into problems not documented below.
  • Newer versions of Java/Tomcat no longer allow self-signed certs like we used to use for testing. Even if you sign it yourself with your own Certificate Authority, you must use a "signed" cert.
  • To debug problems, you can check Catalog's ServiceCatalog.log file for any Java errors when Catalog binds to 8443 (or 443 if you use this port) and loads the JKS. Any errors will be java errors you can google or find information on from Oracle's website. Just search the log file for the port number to check if it loaded properly. Other products use other startup files.
  • All of these commands should be run from the JRE\bin folder that Service Catalog (or whatever application you are doing this for) is using. I used JRE 1.8
  • I used storetype P7B to show this switch, but the storetype below could be JKS if you like. For Service Catalog you should use JKS due to it's wrapper. Other products like SDM may not care.
  • Modern Java matches SAN names with the website as shown below and not the CN (common name). Make sure you have all website names in the SAN list.
  • The Alias name must be the alias name you specified in vewservice.conf and server.xml. It should be consistent in your commands.

1) Generate self signed cert/private key from the catalog server. Once again, I used PKS in the example below but will import it into our existing JKS file. If you want to use JKS or don't have an existing JKS file in your Service Catalog folder already then use JKS. Again, for Service Catalog stick with JKS. For other products like Service Desk you can just point to P7B or any keystore type. Obviously replace the alias name, SAN values, and other things below with your information!

keytool -genkeypair -v -alias -dname ", OU=support, O=CA, L=example-city, ST=NY, C=US" -keystore c:\certs\name_fqdn.pfx -keyalg RSA -keysize 2048 -validity 385 -storetype PKCS12 -ext,dns:secondName,ip:

2) Generate CSR that you will submit to your certificate authority:

keytool -certreq -v -alias -keystore c:\certs\machine_name-fqdn.PFX -storetype pkcs12 -ext,dns:secondName,ip: -file c:\certs\name-fqdn.csr

Once you have the response, this may contain the full chain in a single .cer file. For some products like Service Desk you can just load this into your keystore. However some products like Service Catalog use a wrapper which requires that you separate out the individual cer files. In that case, the steps 3 and 4 below are required. These steps will not hurt to be run in any case:

3) Open *.p7b file that you got back from your Certificate Authority. (double click it to open it on windows)

4) Right click the individual certs and copy to file (using base64) the individual certificate files. 

5) Import signed certs as shown below:

Important Note: You will likely get back a .p7b file from your certificate authority that contains the full certificate chain. In other words it will contain the website certificate, intermediary certficates, and the root CA certificate. Some utilities let you import this .p7b itself. However, Java's wrapper that Service Catalog uses does not seem to like this and this is why we exported the individual .cer files above. So now import the individual certificates as shown below. Make sure the alias name is correct and substitute your values as appropriate.

keytool -importcert -v -alias rootCA -keystore c:\certs\machine_name-fqdn.PFX -storetype pkcs12 -file c:\certs\root.cer

keytool -importcert -v -alias intermediate -keystore c:\certs\machine_name-fqdn.PFX -storetype pkcs12 -file c:\certs\intermediate.cer

keytool -importcert -v -alias -keystore c:\certs\machine_name-fqdn.PFX -storetype pkcs12 -file c:\certs\name-fqdn.cer

6) Import and convert .pfx to .jks. Or if you do not have an existing JKS (and used JKS as your format) then you can just point to your new keystore. 

For Service Catalog you point to the keystore in viewservice.conf and server.xml (this should be a JKS keystore with the cer files imported indivudually). 

For Service Desk you point to the keystore in \bopcfg\www\CATALINA_BASE\conf\server.xml  (Obviously for SDM this ONLY applies if you are securing Tomcat. For IIS, use Microsoft's utility, not java)

To import it to an existing JKS, run:

keytool -importkeystore -deststorepass changeit -destkeystore <full_path>\keystore.jks -srckeystore <full_path>\name-fqdn.pfx -srcstoretype PKCS12 -srcstorepass changeit

7) Import your root cert into Java's trusted keystore. This is required if you use your own CA or you used a certificate authority java does not recognize out of the box. If you do not do this then you may see a trusted anchor error or a certificate chain error:

keytool -import -trustcacerts -alias root -file c:\certs\rootCert.cer -keystore <JRE-PATH>\lib\security\cacerts

(If you like, you can also load the intermediate. I usually do)

for USS (if needed):

1) Set environment variables:

JAVA_HOME="C:\Program Files\CA\Self Service\OSOP\tomcat-7.0.40\jre"


2) Update \OSOP\tomcat-7.0.40\bin\wrapper.conf:"C:\Program Files\CA\Self Service\OSOP\tomcat-7.0.40\jre\lib\security\cacerts""changeit"

3) Import the Catalog root certiificate:

C:\Program Files\CA\Self Service\OSOP\tomcat-7.0.40\jre\lib\security>keytool -import -trustcacerts -alias root -file rootCert.cer -keystore cacerts -storepass changeit

4) Use fqdn in data source from the GUI (or whatever the Catalog cert was issued to. It must be in the SAN)