Article Content

AFX Servers and remote collection agents communicate securely through the server.keystore and the client.keystore. The RSA Identity Governance & Lifecycle application is the server and each AFX Server and remote collection agent is the client. These keystores are saved in the oracle database and on the linux file system. These certificates can get out of sync with each other which can cause AFX and remote collection agents to fail.

This article explains how to update the RSA Identity Governance & Lifecycle root (server) certificate and corresponding client certificates for use with AFX and remote collection agents. Some examples of when you might want to do this are:

After an upgrade of the AFX Server.

After restoring a database from another system.

After restoring an AFX Server archive from another system.

After installing the AFX Server archive on a soft-appliance.

The client and server certificates are out of sync.

You have run modifyhostname.sh.

To configure WebSphere or WebLogic to use server.keystore for incoming AFX connections.

AFX and remote agents will not be running until this entire process is completed. Therefore, do this at a time when the system is quiet.

The server certificate (first step) does not always need to be regenerated. Sometimes just downloading the server and client keystores is sufficient as long as their fingerprints match. Sometimes only the client certificate needs to be regenerated. Once regenerated, both the server and client keystores may be downloaded and their fingerprints checked. The complete process is to regenerate both the server and client keystores and that is what article describes.

Click the Change Certificate button. This action generates a new client certificate based off the new server certificate just generated and ensures the client certificate stored in the database matches the server certificate stored in the database.

You will see the following dialog message. Click OK to generate the new client certificate.

Click the Download Keystore button and save the client.keystore to a location on your computer.

Login to the application server where AFX is installed as the afx user.

Download the new client.keystore to your RSA Identity Governance & Lifecycle AFX server. In this example the keystore file was downloaded to $AVEKSA_HOME (/home/oracle).

Go to the keystore directory.

cd $AFX_HOME/esb/conf

Backup the existing client.keystore.

mv client.keystore client.keystore.bak

Replace the existing client.keystore with the new client.keystore file that was just downloaded.

mv $AVEKSA_HOME/client.keystore $AFX_HOME/esb/conf

Restart AFX and the RSA Identity Governance & Lifecycle application.

afx stopacm restartafx start

Update each remote collection agent client certificate

For each remote agent (not the default local AveksaAgent), click on the remote agent name.

Click the Change Certificate button. This action generates a new client certificate based off the new server certificate just generated and ensures the client certificate stored in the database matches the server certificate stored in the database.

You will see the following dialog message. Click OK to generate the new server certificate.

Click the Download Agent button to download a new agent with the new certificate in a zip file called AveksaAgent.zip.

Login to the remote server that has the remote agent as user oracle.

Download the new AveksaAgent.zip to the remote server. In this example, the zip file was downloaded to /home/oracle.

Stop the agent by running agent_stop.sh in the AveksaAgent/bin directory, as follows:

cd home/oracle/AveksaAgent/bin./agent_stop.sh

Backup the agent directory.

cd /home/oraclemv <agent-directory> <agent-directory.bak>

Unzip the agent on the remote server where it runs (replacing the old one).

unzip AveksaAgent.zip

Start the agent by running agent_start.sh in the AveksaAgent/bin directory, as follows:

cd home/oracle/AveksaAgent/bin./agent_start.sh

Notes

The steps in this article ensure that the versions of the client and server certificates in the database and on the file system have the same fingerprints. To check that the keystores have the same fingerprints, you can do the following: