How to replace the RSA Authentication Manager 8.x Web Tier certificate

[#1]

Article Number

000034367

Applies To

RSA Product Set: SecurID
RSA Product/Service Type: Authentication Manager Web Tier
RSA Version/Condition: 8.2, 8.1 SP1

Issue

This article provides information on how to replace the Authentication Manager 8.1 or 8.2 self-signed Web Tier virtual host SSL identity certificate with one signed by a private or public Certificate Authority (CA), using a Certificate Signing Request (CSR) generated in the Operations Console.

Task

1. Create or verify that the Virtual Host exists for the Web Tier(s).
2. Generate the CSR for the Virtual Host Certificate - Status = 'pending'
3. Import the CA response file(s) to the CSR, in the order listed:
   1. Root CA .cer.
   2. Any intermediary CA signing files.
   3. The Web Tier identity replacement Certificate.
4. Activate the replacement certificate to change status from Pending.

Resolution

A certificate binds a public/private PKI key to a device's fully qualified domain name (FQDN), which in certificate terms must equal the device's distinguished name or DN.

To resolve this issue, 

1. First create or verify that you have a virtual host for your Web Tier(s).  Login to the Operations Console and select Deployment Configuration > Virtual Host & Load Balancing.  Normally the name for a virtual host would be a public name, but in this example we use virtualhost81p.vcloud.local.

Image description

2. The Load Balancer Details of the IP addresses would be the internal IP addresses that the Web Tier would see from the Load Balancer, most likely in the DMZ.
3. Next, generate a Certificate Signing Request (CSR) for a Web Tier virtual host in the Operations Console by navigating to Deployment Configuration > Certificates > Virtual Host Certificate Management.

Image description

4. The CSR generates the public/private key pair, and inserts the public key into the certificate request, so that the Certificate Authority can sign this CSR and return a response file.  The private key is in the Authentication Manager keystore.
5. After the CSR has been generated, when you look at Manage Virtual Host Certificates, you should see the virtual host, virtualam81p in the example below, with an alias of the virtual host name and a status of Pending.

Image description

5. You can see that the primary's FQDN is am81p.vcloud.local and that the original default certificate shown in the third row of the image (the active virtualhost-id-key in the Subject column with serial number 44837c5a9266…), was signed by the default RootCA with serial number 2660b7301e…, shown in the Issued By column. The pending CSR for the replacement certificate, shown in row 2 above, will have an FQDN of virtualam81p.vcloud.local and a serial number of 9c15c2b1bdb…  If there has never been a Virtual Host replacement certificate, you will see only two entries here:  the signer certificate and the virtualhost-id-key, which would be active.  If other CSRs were generated but not used, they will all show as Pending, but each new CSR invalidates the previous ones because a new private key is generated for the newest CSR.
6. In the normal process, you download and send the CSR to a CA.  You get back an identity certificate for the virtual Web Tier host (typically a PKCS#7 file with no password protection and no private key, with file extension of either .cer or .p7b), and the root CA that signed it, and any intermediary signing CAs in the trust chain.  For these examples, an RSA Keon server was used as a CA to take the CSR and generate the certificate for the virtual host.  Two files were returned: the virtual server certificate and it’s root CA certificate.  There were no intermediary certificates.  Sometimes you get a third file with the intermediary signing CA certificate, other times one file is returned that has all three certificates inside it.  This file might be password protected.

Image description

7. If the CSR was generated in the Operations Console, you should get a PKCS#7 file with either a .cer or .p7b file extension and no password on them.
8. Import the replacement root CA .cer file first, because the Import Certificate option will complain if you try to import the Virtual Host certificate first without the trust chain for it.  Root and intermediary show with an alias of Signer Certificate.

Image description

9. If there is an intermediary certificate, import that next.  
10. Third, or last, import the replacement certificate.  After importing the root CA certificate file, which was the single entry above the replacement in the trust chain, the replacement certificate for the virtual Web Tier host was imported.  Note that it still has the serial number of of 9c15c2b1bdb… from the CSR for the FQDN of virtualam81p.vcloud.local.  It will not import without the entire trust chain imported ahead of it.

Image description

11. The status is listed as Inactive until it is activated as the replacement Virtual Host certificate:

Image description

12. Review the Activation Request for the replacement virtual host certificate:

Image description

13. Click Activate Certificate .  The response from the server should be "Successfully activated the Virtual Host Certificate."  Now the virtual host certificate is active and still has the serial number of 9c15c2b1bdb… from the CSR, but has the Issued/Signed By serial number of the replacement Root CA:

Image description

Notes

There are other KBs that show how to break apart password protected files which contain the entire trust chain of certificate files using IE, Keytool or OpenSSL.  Other KBs explain how to export the private key for this virtual host certificate so it can be imported into a load balancer and terminate SSL connections at the load balancer instead of at the web tier.