|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,
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- If there is an intermediary certificate, import that next.
- 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.
- The status is listed as Inactive until it is activated as the replacement Virtual Host certificate:
- Review the Activation Request for the replacement virtual host certificate:
- 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: