000030016 - How to replace the RSA  Authentication Manager 8.1 SP1 self-signed console certificate with a certificate that uses SHA-256

Document created by RSA Customer Support Employee on Jun 14, 2016Last modified by RSA Customer Support Employee on Apr 21, 2017
Version 5Show Document
  • View in full screen mode

Article Content

Article Number000030016
Applies ToRSA Product Set: SecurID
RSA Product/Service Type: Authentication Manager
RSA Version/Condition: 8.1 SP1
IssueBy default the Authentication Manager 8.1 SP1 self-signed console certificate can be replaced, but the Operations Console interface only requests certificates that use SHA-1, and does not accept SHA-256 or SHA-512.  This occurs because only SHA1 certificates were tested and work with cross realm/trusted realm connections, as well as with all devices that import software tokens via CT-KIP.
If your deployment does not use trusted realm and all devices that import software tokens with CT-KIP can handle SHA-256, you may try this unsupported workaround to use a SHA-256 console certificate.  Authentication Manager 8.2 may include this as a supported option.
  1. Request a certificate by generating a Certificate Signing Request (CSR) in the Authentication Manager 8.1 SP1 Operations Console, which will request a SHA-1 certificate, but request that your CA use SHA-256 in their reply, and import that SHA-256 reply using this KB solution.
  2. Optionally, use a third party tool (e. g., Java Keytool) to generate a CSR on behalf of the Authentication Manager 8.1 SP1 server that requests the SHA-256 certificate, but you will need to use Keytool to import the private key that will be used by this SHA-256 certificate as well as import the replacement certificate.  This process is not covered in this solution.
  1. Generate the Certificate Signing Request (CSR) in the RSA Operations Console for a console certificate (Deployment Configuration > Certificates > Console Certificate Management).  This defaults to SHA-1 and cannot be modified.
  2. Download this CSR file.  When done with this step, the CSR will be listed in the Operations Console with a Pending status, as shown below

  1. Present the CSR file to your Certificate Authority (CA) and ask that the CA set the Response to use SHA-256 and not SHA-1. If possible, also request that this response be in a PKCS#7 format with either a .P7B or .cer extension for the file name
  2. Download the CA response as a PKCS#7 with .P7B extension and, if the trust chain is not included in the single file, also download any root CA and intermediate root CA certificates that are part of the trust chain for your replacement console certificate.
  3. Import the response file in the Operations Console. and test/verify 

  1. If the PKCS#7 file does not work, try PKCS#12, and if that fails then talk to your CA
NotesThis solution will most likely break any cross realm or trusted realm connection to another Authentication Manager primary, and may break some CT-KIP delivery of software tokens to older devices that do not support SHA-256 certificates.  Also be sure to confirm that RADIUS authentication is working after importing the SHA-256 certificate.
Optionally, use Keytool to view these console certificates.  Steps are as follows:
  1. SSH to the Authentication Manager 8.1 SP1 primary or replica on which you are replacing the certificate.
  2. Login with the rsaadmin operating system account.
  3. Navigate to /opt/rsa/am/utils.
  4. Obtain the SSL Server Identity Certificate Keystore File Password, with the command below.  Enter the Operations Console administrator credentials, when prompted.  The SSL Server Identity Certificate Keystore File Password for this server is in bold below.
login as: rsaadmin
Using keyboard-interactive authentication.
Password: <enter operating system password>
Last login: Wed Jan 25 14:54:39 2017 from jumphost.vcloud.local
RSA Authentication Manager Installation Directory: /opt/rsa/am
rsaadmin@am81p:~> cd /opt/rsa/am/utils
rsaadmin@am81p:/opt/rsa/am/utils> ./rsautil manage-secrets -a list com.rsa.signing.key
Please enter OC Administrator username: <enter Operations Console admin user name>
Please enter OC Administrator password: <enter Operations Console admin password>
Secrets stored in ./etc/systemfields.properties.
Command API Client User ID ............................: CmdClient_6hbts4ws
Command API Client User Password ......................: AZxs8HRh3uxoyyE5do4wUoSTHkET9H
SSL Server Identity Certificate Private Key Password ..: iGegdeO9ev1XG0Y10gIzaAeiLaXY5g
SSL Server Identity Certificate Keystore File Password : MA8eMBMiDSWz6ApxEDLC2oeKWBhtZh
Root Certificate Private Key Password .................: fEJua8xHwn4eEJrRpX5Fpeab5vOTEc
Root Certificate Keystore File Password ...............: odXmoFy4f0vseDhQaD9ZddZYcQqkE2
The "listkeys" action displays the key names to use when setting the values.

  1. Using Keytool, view the certificates in the SSL Identity Certificate Keystore by alias using the command below.  Enter the SSL Server Identity Certificate Keystore File Password when prompted.  
rsaadmin@am81p:/opt/rsa/am/utils> ../appserver/jdk/jre/bin/keytool -list -keystore /opt/rsa/am/server/security/webserver-inactive.jks
Enter keystore password: <enter SSL Server Identity Certificate Keystore File Password captured above>
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 3 entries
vm1152015, Apr 9, 2015, PrivateKeyEntry,
Certificate fingerprint (MD5): AA:6E:3E:12:2D:52:18:0C:9E:F9:BD:93:4C:B9:F2:38
rsa am internal ca, Aug 28, 2014, trustedCertEntry,
Certificate fingerprint (MD5): B8:63:B7:79:1B:45:D4:30:07:5F:47:0D:BC:B3:94:E7
rsa am default server cert, Aug 28, 2014, PrivateKeyEntry,
Certificate fingerprint (MD5): 16:0C:E8:DB:62:BE:83:53:CF:75:55:F1:02:E5:2E:57

  1. In the output above, the new alias for the pending CSR is vm1152015, which matches the Operations Console image in step 2 of Resolution.
Note that there are also -delete and -export options for this command, in addition to -list, so please be careful when typing.