• vRealize Automation components use different Cryptographic providers.
• vRealize Automation components work with different SSL certificate file formats.
• There are specific required trust dependencies between components.

• In many organizations, certificates are issued or requested by external authorities according to company regulations.
• An effort was made to identify formats and certificate types supported by VMware vRealize Automation components, based on Certification Authority and Offline Root CA.
  

• Hash Algorithm - SHA1, SHA2 (256, 384, 512)
• Signature Algorithm - RSASSA-PKCS1_V1_5
• Key Length - 2048, 4096

Certificates supportability matrix for vRealize Automation

Certificate trust requirements between VMware vRealize Automation components

• * vRealize certificate thumbprint is stored in IaaS database during installation
• ** SSO certificate thumbprint is stored in IaaS database during installation
• *** Application Director and Orchestrator as an external instance are optional services

Supportability details and best practices:

• Windows CA signed certificates converted with OpenSSL are not supported due to a mismatch in the order of the certificates in the chain. You may be able to get these certificates to work by editing the files and changing the order of the certificates to a client to root format:
  
  
  1. Client/Server certificate signed by the intermediate CA.
  2. One or more intermediate certificates in the chain. If more than one intermediate chain exists, they should be in the ascending order from client up to root.
     
  3. Root CA certificate.
     
     Note: If you use the incorrect order, you may see the Return code is: SslHandshakeFailed error.
     

• Always use host names (FQDN) for CN (common name) and SAN (subject alternative name) in certificates. Using an IP address is not supported.
• When using SAN certificates, ensure that the CN value is also included in the SAN.
• Wildcard certificates are supported but not recommended. If you want to reduce the number of certificates, VMware recommends to list all server names in the SAN instead.
• IaaS components requires Certificate Revocation List (CRL) access to successfully connect to vRealize Automation appliances. Checking of the CRL servers can be disabled on the IaaS side. If this is required, file a support request with VMware Support and note this Knowledge Base article ID ( 2106583) in the problem description. For more information, see Filing a Support Request in Customer Connect (2006985) or How to Submit a Support Request.
• vRA 6.2 uses RabbitMQ as one of its components. By default, RabbitMQ uses the same certificate that as the vRA web server. Manual updates to the RabbitMQ certificate are not supported.
• Never replace all the different platform certificates at once (Identity Appliance, vRA Appliance, and IaaS). Replace certificates one at a time and follow all of the steps in the System Administration Guide to fully distribute the updated certificate before moving on to the next platform.

Common issues and solutions:

• When vRA services are restarted or an upgrade is performed, certificates may become invalid. In some situations, vRealize Automation does not report the certificates as failed until services are started causing the issue to show up after a restart or upgrade.
• Accessing the Infrastructure tabs result in the error: Invalid Certificate and This Connection is Untrusted . To resolve this issue, see Accessing the Infrastructure tabs in VMware vRealize Automation 6.0 fails with errors: Invalid Certificate and This Connection is Untrusted (2073124).
  
• Windows Guest Agent fails on a Windows 2012 server with the error: Client certificate chain file not specified . To resolve this issue, see Connecting the guest agent to IaaS on Windows 2012 fails with the error: Client certificate chain file not specified (2092629).
  

Troubleshooting methodology:

• When troubleshooting certificate errors, extract/ view the certificate in question and check these:
  
  
  • Date: Confirm expiration dates on all certificates.
  • URL: Must match exactly the subject and/or subject alternative name on the certificates.
  • Chain:Verify the certificate chain to ensure that a full path to trust can be achieved. Ensure that the PEM file is copied into the Appliance management page in the correct order.
    
  • CRL: Ensure that the certificate revocation server is accessible. To test access to the CRL, log in to the vRealize Automation appliance you are testing from and use the curl command
  
  For example:
  
  • curl https://www.domain.com/crl-directory/filename.crl
  • curl -k https://www.domain.com/crl-directory/filename.crl (-k ignores certificates)

VMware vRealize Certificate Generation Tool