How to import a Root CA or public key Certificate into an Authentication Manager (or AMIS) java key store .jks with keytool
2 years ago
Article Number
000067947
Applies To
Authentication Manager Appliance and Web Tiers, version 8.x
AM Prime all versions
Issue
Sometimes it might be necessary to import a certificate into an RSA Authentication Manager server, Web Tier or AM Prime server (SSP or HDAP) with keytool from a command line. For example, if your Web Tier or AMIS SSP or HDAP Server runs on Windows, Security Policy might prevent installing a utility like Keytool Explorer.  If you know where your java key store .jks file is, and you know its password, you can copy the .jks file to Suse Linux on an AM server and use keytool to modify the .jks, including importing a certificate file.
Tasks
1. locate your java key store, e.g. AMIS SSP servers have a java keystore called truststore.jks which typically lives in <AMIS install directory>primekit\certificates\truststore.jks
2. determine the keystore password
In Windows, the java password can be seen under PROPERTIES for the Tomcat-ssp icon
tomcat
Resolution
If you copy the truststore.jks and any certificate file, e.g. root_<company>_com.crt to /tmp/truststore on your AM server, you can use the following command to import root_<company>_com.crt into truststore.jks if you cd to /tmp/truststore

/opt/rsa/am/appserver/jdk/bin/keytool -v -importcert -alias amisvip2022 -file ./root_<company>_com.crt -deststoretype JKS -destkeystore ./truststore.jks

You will be prompted for the password for truststore.jks.  
Notes
This solution was needed for a case that involved two AMIS Self Service Portal, SSP on Windows, that had an F5 load balancer facing the internet.  The SSP servers had the original wildcard * cert that the F5 used, so that the F5 terminated SSL/TLS user browser connections from the Internet, then built additional SSL/TLS connections to the two SSP servers.

When the original wildcard certificate expired, the F5 imported a replacement wildcard cert, with same Root CA signing authority (in this case Digicert but it could have been any Public or Privat CA) the connection from the F5 to the SSP servers were refused, because the SSP servers could not trust the F5 wildcard cert since they only had the original widcard cert, not the whole trust chain of signing Certificate Authorities, CAs.  This resulted in the SSP logon failing with 
   "Login Failed I/O error on POST unable to find valid certification"
I~O_error_on_POST
We needed to import the Root CA from Digicert into the truststore.jks files on the SSP servers.  However we did not have a tool such as Keytool explorer on the Windows Servers, and Security Policy prevented installing that software anywhere in this company. So we had to copy the Root CA cert file and the truststore.jks to an AM server and use keytool

Related Articles

Trending Articles

Don't see what you're looking for?