How to manage RSA Authentication Manager console and virtual host certificates with keytool
a day ago
Originally Published: 2024-01-31
Article Number
000071953
Applies To

RSA Product Set: SecurID
RSA Product/Service Type: 8.x through 8.9

Issue

Console Certs OC

The Authentication Manager console, web tier and SDK application trust certificates are stored in .jks files in /opt/rsa/am/server/security/, as shown:

  • AM Console Certificates are in webserver-inactive.jks
  • Web Tier Virtual Host Certificates are in vh-inactive.jks
  • AM Prime Cert is in <AMIS install directory>/primekit/certificates/truststore.jks

There are two versions of each .jks, an inactive version that you can edit with keytool, and an active version that is created when you click on the [Activate] drop-down/button in the Operations Console.

When you import a certificate through the Operations Console, it is imported into the inactive.jks.

When you generate a CSR, you create your public/private key pair, and place the public key in the CSR signing request file, but keep the primary key in the local inactive.jks file. That is why no password is needed on this type of CSR, as there is no private key in it.

RSA only allows one active Console cert or one active Virtual Host certificate, which is copied into the webserver-active.jks or the vh-active.jks

OC-Deploy-Certs-VH-Manage

 

Tasks

Complete the following: 

  1. Obtain the .jks keystore password with the command /opt/rsa/am/utils/rsautil manage-secrets -a listall
  2. On the primary, navigate to /opt/rsa/am/server/security/ then copy both the webserver-inactive.jks and vh-inactive.jks:

cp webserver-inactive.jks webserver-inactive.jks.bak<date>
cp vh-inactive.jks vh-inactive.jks.bak<date>

WARNING:

  • Do not edit the active version with keytool.
  • Always make a backup copy of the inactive version before you edit it (that is, every time you edit it!). 

A copy of keytool on AM servers is in /opt/rsa/am/appserver/jdk/jre/bin/keytool.

Articles like this one use relative directory references to keytool and local working directory for .jks file locations

Resolution

You DO NOT need the .jks password to list or look at a .jks keystore, but you do need the password to delete, import or change. After you get the keystore password, test it with a list command.

You DO NOT need the .jks password to list or look at a .jks keystore, but you do need the password to delete, import or change. After you get the keystore password, test it with a list command.

To get the .jks password,

  1. Navigate to /opt/rsa/am/utils.
  2. Run the command ./rsautil manage-secrets -a listall. Output shown:

rsautil_manage-secrets_listall2

 

To view just the RSA signing key value, run ./rsautil manage-secrets -a list com.rsa.signing.key

Backup the .jks files

Make a backup copy of the inactive versions of both the webserver-inactive.jks and vh-inactive.jks located in /opt/rsa/am/server/security

cd /opt/rsa/am/server/security/
cp webserver-inactive.jks webserver-inactive.jks.back_Jan31_2024
cp vh-inactive.jks vh-inactive.jks.back_Jan31_2024

 

  • Keytool is in /opt/rsa/am/appserver/jdk/jre/bin/keytool
  • Relative directory reference to keytool is from ../../appserver/jdk/jre/bin/keytool

 

  • List all AM console certs and keys  

../../appserver/jdk/jre/bin/keytool -list -keystore ./webserver-inactive.jks

Enter keystore password: <enter Host Certificate Private Key Password from above>

 

  • List AM console cert with rsaserv2023 alias

../../appserver/jdk/jre/bin/keytool -list -alias rsaserv2023 -keystore ./webserver-inactive.jks

 

  • List AM console cert with rsaserv2023 alias in verbose mode

../../appserver/jdk/jre/bin/keytool -list -alias rsaserv2023 -v -keystore ./webserver-inactive.jks

 

  • Delete an old CSR (Cert signing request)

When the list -alias shows you the CSR you want to delete, use the up arrow and change -list to -delete

  ../../appserver/jdk/jre/bin/keytool -list -alias rsaserv2020 -keystore ./webserver-inactive.jks

../../appserver/jdk/jre/bin/keytool -delete -alias rsaserv2020 -keystore ./webserver-inactive.jks

 

  • Example of importing new Root_CA cert into AMIS truststore.jks for AM PrimeKit

/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

This keytool command imported a Public Root CA cert from an F5 Load Balancer in front of a pair of AMIS SSP servers.

 

  • Import into AMIS keystore

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

Notes

Related KBs

Do not edit the active .jks file versions with keytool and always make a backup copy of the inactive version before you edit it (every time you edit it!).

You can make a copy of any .jks  filesand use it to practice with keytool. There are GUI versions on keytool that you might find easier to use, but conceptually keytool works fine and is a good way to 'see' what you are doing while you learn.


Trusted application certs are in trust.jks. There is only one .jks for this; there are no active and inactive versions. The trust.jks stores certs from connections to:

  • AMIS AM PrimeKit, 
  • Custom applications that use the AM Admin SDK,
  • Trusted (cross) realm connections to other AM Primaries 
  • If your primary has a replacement console cert, but your replica(s) do not, the replica(s) will need to trust the Primary's console replacement Root CA cert that needs to be imported into the replica's trust.jks. Failure to do this will cause a replica promotion for maintenance to fail

Authentication Manager 8.10, with a tentative release slated for early 2027, will include the ability to replace console certificates without having to use the Operations Console.