How to Replace the Operations Console SSL Certificate with SHA-256 in RSA Authentication Manager 8.1 SP1
a day ago
Originally Published: 2015-04-10
Article Number
000067611
Applies To
RSA Product Set: SecurID
RSA Product/Service Type: Authentication Manager
RSA Version/Condition: 8.1 SP1
Issue
Use this article to replace the default SHA-1 self-signed console certificate in RSA Authentication Manager 8.1 SP1 with a SHA-256 certificate. The Operations Console generates CSRs using SHA-1 only — this procedure instructs your Certificate Authority (CA) to sign the response using SHA-256 instead.
 
⚠️ CAUTION: This is an unsupported workaround — it is not QA-tested and is not subject to bug fixes. Do not proceed if your deployment uses trusted realm/cross-realm connections or if any CT-KIP devices do not support SHA-256.
 
Prerequisites:
  • Operations Console administrator credentials
  • SSH access to the Authentication Manager 8.1 SP1 primary or replica server
  • Access to a Certificate Authority (CA) that can sign with SHA-256
Tasks
This article covers two approaches for replacing the console certificate. Follow the task that matches your environment:
 
TaskTool
Key Detail
Task 1: Generate CSR via Operations Console and import SHA-256 response
Operations Console + 
Covered in this article. CA must sign the response with SHA-256.
 
Task 2: Generate CSR via Java Keytool
Java Keytool
Not covered in this article. Requires Keytool to generate CSR and import private key separately.
Resolution
Step 1: Log in to the RSA Operations Console.
 
Step 2: Navigate to Deployment Configuration > Certificates > Console Certificate Management.
 
pending
 
Step 3: Generate a Certificate Signing Request (CSR) for the console certificate. The CSR defaults to SHA-1 — this cannot be modified in the Operations Console.
 
Step 4: Download the CSR file to your local machine.
Expected result: The CSR is listed in the Operations Console with a Pending status.
 
Step 5: Submit the CSR file to your Certificate Authority (CA). Request the following:
  • Sign the response using SHA-256 (not SHA-1).
  • Return the response in PKCS#7 format with a .P7B or .cer file extension.
Step 6: Download the CA response file (.P7B). If the trust chain is not included in the single file, also download any root CA and intermediate CA certificates that form the trust chain.
 
Step 7: Import the CA response file into the Operations Console under Deployment Configuration > Certificates > Console Certificate Management.
 
import
 
⚠️ CAUTION: If the .P7B file fails to import, try PKCS#12 format. If that also fails, contact your CA to confirm the response format and certificate chain are correct.
 
Step 8 (Verification): Confirm the certificate has been successfully replaced by checking that:
  • The console certificate listed in the Operations Console reflects the new SHA-256 certificate.
  • RADIUS authentication is functioning correctly after the import.
  • CT-KIP software token delivery is working on all devices.
 
Notes
⚠️ CAUTION — Known Risks of This Workaround:
  • This procedure will most likely break any cross-realm or trusted realm connection to another Authentication Manager primary.
  • It may break CT-KIP software token delivery to older devices that do not support SHA-256 certificates.
  • Always confirm RADIUS authentication is functioning correctly after importing the SHA-256 certificate.
ℹ️ NOTE — Optional: View Console Certificates Using Java Keytool
You can use Java Keytool to inspect the certificates in the SSL Identity Certificate Keystore. Follow the steps below.
Step 1: SSH to the Authentication Manager 8.1 SP1 primary or replica server.
Step 2: Log in with the rsaadmin operating system account.
Step 3: Navigate to the utils directory:
cd /opt/rsa/am/utils
Step 4: Retrieve the SSL Server Identity Certificate Keystore File Password by running:
 
./rsautil manage-secrets -a list com.rsa.signing.key
Enter your Operations Console administrator credentials when prompted. The SSL Server Identity Certificate Keystore File Password will appear in the output.
Example output (values will differ in your environment):
SSL Server Identity Certificate Private Key Password ..: <private-key-password>
SSL Server Identity Certificate Keystore File Password : <keystore-file-password>
Root Certificate Private Key Password .................: <root-private-key-password>
Root Certificate Keystore File Password ...............: <root-keystore-password>
 
Step 5: View the certificates in the SSL Identity Certificate Keystore by alias:
../appserver/jdk/jre/bin/keytool -list -keystore /opt/rsa/am/server/security/webserver-inactive.jks
Enter the SSL Server Identity Certificate Keystore File Password retrieved in Step 4 when prompted.
Example output:
 
Keystore type: JKS
Keystore provider: SUN

Your keystore contains 3 entries

<new-csr-alias>, <date>, PrivateKeyEntry,
Certificate fingerprint (MD5): <fingerprint>

rsa am internal ca, <date>, trustedCertEntry,
Certificate fingerprint (MD5): <fingerprint>

rsa am default server cert, <date>, PrivateKeyEntry,
Certificate fingerprint (MD5): <fingerprint>
 
ℹ️ NOTE: The new alias for the pending CSR (e.g., the first entry above) will match the alias shown in the Operations Console after Step 4 of the Resolution.
 
⚠️ CAUTION: The keytool command also supports -delete and -export options. Use caution when typing — only use -list unless you intend to modify the keystore.