Certificate troubleshooting, supportability, and trust requirements for vRealize Automation
search cancel

Certificate troubleshooting, supportability, and trust requirements for vRealize Automation

book

Article ID: 324632

calendar_today

Updated On:

Products

VMware Aria Suite

Issue/Introduction

The various components of VMware vRealize Automation (formerly known as VMware vCloud Automation Center) have different requirements for the certificates used for authentication. This article contains reference information that helps you solve some of the known common problems specific to certificates with VMware vRealize Automation.

Common Issues

  • 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.

Environment

VMware vRealize Automation 6.x
VMware vRealize Automation 7.x

Resolution

Supported Certificate types:

  • 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.

Certificate properties covered:

  • Hash Algorithm - SHA1, SHA2 (256, 384, 512)
  • Signature Algorithm - RSASSA-PKCS1_V1_5
  • Key Length - 2048, 4096
Note: RSASSA-PSS is not a supported signature for vRealize Automation setup. This is the default signature selected when using Microsoft CA on Windows 2012 R2.
This is a configurable parameter, so in case of using a MS-CA, ensure that it is properly set to a supported value.
 

Certificates supportability matrix for vRealize Automation

Hash algorithm

SHA1

SHA2-256

Signature algorithm

RSASSA-PKCS1_V1_5

RSASSA-PSS

RSASSA-PKCS1_V1_5

RSASSA-PSS
Key Size 2048 4096 2048 4096 2048 4096 2048 4096
vRA Supported
Supported
Verified

Supported
Verified
Not
Supported
Not
Supported

Supported
Verified

Supported
Verified
Not
Supported
Not
Supported

Hash algorithm

SHA2 - 384

SHA2 - 512

Signature algorithm

RSASSA-PKCS1_V1_5

RSASSA-PSS

RSASSA-PKCS1_V1_5

RSASSA-PSS

Key Size

 2048 4096 2048 4096 2048 4096 2048 4096
vRA Supported
Supported
Verified
Supported
Verified
Not
Supported
Not
Supported

Supported

Verified

Supported

Verified
Not
Supported
Not
Supported
 
Note: The preceding certificate support matrix is also applicable for vRA 7.x versions.
 

Certificate trust requirements between VMware vRealize Automation components

vRealize Automation Component (alias)

Certificate file type required

Node Cryptographic provider

Needs to be trusted by

Keystores on node (alias)
SSO .pem OpenSSL 0.9.8* vRealize Automation VA vcac.keystore
(websso)
IaaS hosts IaaS DB *
vRealize Automation .pem

1) OpenSSL 0.9.8j*

  • used by Apache httpd server

2) Java

  • used by all vRA services
 vRealize Automation VA

1) server.pem


2) vcac.keystore
(café)
IaaS hosts IaaS DB **
IaaS Web components .pfx Window CA vRealize Aurtomation VA Postgres DB
IaaS host Windows certificate store
/ local / computer account / Personal certificates
Iaas Manager Service .pft Windows CA IaaS hosts Windows certificate store
/ local / computer account / Personal certificates
Orchestrator***
(vCO, vRO)		 .jks Java

vRealize Automation VA

IaaS hosts

 jssecacerts (dunes)
 
  • * 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 listing all server names in the SAN instead.
  • IaaS components require 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 with the problem description.
  • 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).

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.
  • Windows Guest Agent fails on a Windows 2012 server with the error: Client certificate chain file not specified. This issue occurs when WIndows 2012 does not support SHA512 signed certificates.

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.example.com/crl-directory/filename.crl
    • curl -k https://www.example.com/crl-directory/filename.crl (-k ignores certificates)

Additional Information

VMware vRealize Certificate Generation Tool

VMware recommends you use the VMware vRealize Certificate Generation Tool. For more information on creating signed certificates, see Using the vRealize Certificate Generation tool to assist with creating signed certificates

Powered by Wolken Software