Hello bright minds!
Seeking some help here, with many people's favorite topic..SSL Certs (especially in the vSphere 6.x days!).
Here is my setup.
vCenter - latest build 8.0u3g (no new builds available per the build kb)
ESXi hosts - same thing as above.
vCenter uses a CA (Sectigo) signed SSL machine cert so that the web UI shows a nice secure encrypted comms channel. No issues there.
vCenter was configured to use Azure Entra ID for identity management. We followed the lengthy document from Broadcom on how to integrate vCenter and Entra and it works fine. No issues there.
Now here comes vROPS, er Aria Operations or whatever today's name is. For the pedantic who didn't get my sarcasm out there yes its VMware Aria Operations version 8.15.5 build 24967118. Enterprise edition. Freshly installed yesterday.
One of the first things I like to do before configuring a product is go ahead and get the SSL certs installed and out of the way.
I followed this KB for minting and installing a CA (Sectigo) signed cert: https://knowledge.broadcom.com/external/article/320343/configure-a-certificate-for-use-with-vmw.html
All was going fine, I got my CSR headed over to Sectigo and pasted it in and began the steps to mint the cert. Well when it reached the screen the shows you the details about the cert such as the SAN name (which the KB asks you to put the short name and IP in there), Sectigo didn't like that. Basically it was saying it was invalid. It gave me in the UI to remove the short name and IP, leaving only the FQDN of the vROPS server (1 node host not a cluster), after removing these, it said the request was valid and proceeded to mint a PEM cert.
I then logged into the Aria Ops admin page, stopped the collection process and clicked on the button to install the PEM encoded SSL cert. It was formatted with the private key, intermediate certs, and root CA as per the KB linked above and in the order specified in that KB.
Aria had no issues it validated the cert and installed it. Restarted everything closed out of my browser windows, opened up a fresh one and sure enough when I went to the FQDN of my Aria Ops install it showed a correctly secured SSL cert. Cool easy enough!
I proceeded to setup my VC in Aria Ops to start collecting data. Give it credentials and the FQDN, done. Works fine and started showing me metrics of my VC.
Then came trying to setup my IDP, I logged into Aria and headed over to where you set up your IDP. I selected VMware SSO as my choice, I was given very few options in terms of configuration, hostname and password essentially. So I gave it my vCenters FQDN and the administrator@vsphere.local username and its password. That's when an error, almost instantly, popped up: Failed to test VMware SSO auth source: Connection Failure
Now I already know that my VMware SSO configuration works with other products, as I had already installed Aria Log Insight and set it's IDP to VMware SSO, where a similar process of providing the VC's FQDN + local admin acct were required. It succeeded and Aria Logs works fine with "VMware SSO", everything was seamless, it found all my users / groups from our domain that we had set up in Azure Entra. So I know that the VMware SSO works with other products (at least one).
So it was time to start my search on the web and look at logs ect... it seems to very clearly be an SSL issue.
Whenever I try to configure the IDP in Aria Ops, I see in my VC's logs under /var/log/vmware/envoy/envoy.log a clear yet not clear enough (to me) error message: info envoy[2968] [Originator@6876 sub=connection] [Tags: "ConnectionId":"63898"] remote address:MY_VCENTERS_IP_ADDRESS:58460,TLS_error:|268436502:SSL routines:OPENSSL_internal:SSLV3_ALERT_CERTIFICATE_UNKNOWN:TLS_error_end
So clearly SSL comms are not working right. Problem is I don't know what that error translates to, and my web searches indicated a cert missing, say an intermediate cert or a CA cert. I found it odd that the address was an IP address instead of the FQDN of my VC, maybe that's normal.
Yes I have forward/reverse DNS records and both the VC and Aria Ops can resolve DNS just fine. (I know someone was thinking that, and hey that's fair!)
I dumped the cert from the command line in Aria Ops which again was in the same order as that of the KB:
-----BEGIN CERTIFICATE-----
(Your Primary SSL certificate: my_aria_ops_certificate.pem)
-----END CERTIFICATE-----
-----BEGIN RSA PRIVATE KEY-----
(Your Private Key: my.key)
-----END RSA PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
(Your Intermediate certificate: Sectico_intermediate2.pem)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Your Intermediate certificate: Sectico_intermediate1.pem)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Your Root certificate: Sectico_CA.pem)
-----END CERTIFICATE-----
I checked, no whitespaces or other oddness in the certs.
I ran the vRopsCertificateTool that comes on the system to try and figure it out and got the following in the vropsCertificateTool.log:
DEBUG: Will attempt to fix the intput file(s)
DEBUG: Will include bag attributes in output file.
DEBUG: Will check input file: "vrops.pem"
DEBUG: Will write output to file: "bags.pem"
DEBUG: Unpacking composite pem file "vrops.pem"
INFO: Found a CERTIFICATE
INFO: Found a PRIVATE_KEY
INFO: Found a CERTIFICATE
INFO: Found a CERTIFICATE
INFO: Found a CERTIFICATE
INFO: Parsing the 5 extracted sections.
INFO: Attempt to decrypt any encrypted keys
INFO: Found section: CERTIFICATE
INFO: description:
subject = /C=XXX/ST=XXX/O=XXX/CN=aria-vrops-fqdn
issuer = /C=GB/O=Sectigo Limited/CN=Sectigo Public Server Authentication CA OV R36
not before 2025-12-08 00:00:00
not after 2026-12-08 23:59:59
signature algorithm = b'sha256WithRSAEncryption'
10 extensions:
b'authorityKeyIdentifier' = XXX
b'subjectKeyIdentifier' = XXX
b'keyUsage' = Digital Signature, Key Encipherment
b'basicConstraints' = CA:FALSE
b'extendedKeyUsage' = TLS Web Server Authentication
b'certificatePolicies' = Policy: 1.3.6.1.4.1.6449.1.2.1.3.4 CPS: https://sectigo.com/CPSPolicy: 2.23.140.1.2.2
b'crlDistributionPoints' = Full Name: URI:http://crl.sectigo.com/SectigoPublicServerAuthenticationCAOVR36.crl
b'authorityInfoAccess' = CA Issuers - URI:http://crt.sectigo.com/SectigoPublicServerAuthenticationCAOVR36.crtOCSP - URI:http://ocsp.sectigo.com
b'ct_precert_scts' = Signed Certificate Timestamp: Version : v1 (0x0) Log ID : XXX XXX Timestamp : Dec 8 16:45:08.937 2025 GMT Extensions: none Signature : ecdsa-with-SHA256 XXX XXX XXX: XXX XXX:02Signed Certificate Timestamp: Version : v1 (0x0) Log ID : XXX: XXX Timestamp : Dec 8 16:45:09.122 2025 GMT Extensions: none Signature : ecdsa-with-SHA256 XXX: XXX: XXX: XXX: XXXSigned Certificate Timestamp: Version : v1 (0x0) Log ID :XXX XXX Timestamp : Dec 8 16:45:08.928 2025 GMT Extensions: none Signature : ecdsa-with-SHA256 XXX XXX XXX XXX XXX
b'subjectAltName' = DNS:aria-vrops-fqdn
INFO: Found section: PRIVATE_KEY
INFO: description:
Key Size = 2048 bits
INFO: Found section: CERTIFICATE
INFO: description:
subject = /C=GB/O=Sectigo Limited/CN=Sectigo Public Server Authentication CA OV R36
issuer = /C=GB/O=Sectigo Limited/CN=Sectigo Public Server Authentication Root R46
not before 2021-03-22 00:00:00
not after 2036-03-21 23:59:59
signature algorithm = b'sha384WithRSAEncryption'
8 extensions:
b'authorityKeyIdentifier' =XXX
b'subjectKeyIdentifier' = XXX
b'keyUsage' = Digital Signature, Certificate Sign, CRL Sign
b'basicConstraints' = CA:TRUE, pathlen:0
b'extendedKeyUsage' = TLS Web Server Authentication, TLS Web Client Authentication
b'certificatePolicies' = Policy: X509v3 Any PolicyPolicy: 2.23.140.1.2.2
b'crlDistributionPoints' = Full Name: URI:http://crl.sectigo.com/SectigoPublicServerAuthenticationRootR46.crl
b'authorityInfoAccess' = CA Issuers - URI:http://crt.sectigo.com/SectigoPublicServerAuthenticationRootR46.p7cOCSP - URI:http://ocsp.sectigo.com
INFO: Found section: CERTIFICATE
INFO: description:
subject = /C=GB/O=Sectigo Limited/CN=Sectigo Public Server Authentication Root R46
issuer = /C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority
not before 2021-03-22 00:00:00
not after 2038-01-18 23:59:59
signature algorithm = b'sha384WithRSAEncryption'
8 extensions:
b'authorityKeyIdentifier' = XXX
b'subjectKeyIdentifier' = XXX
b'keyUsage' = Digital Signature, Certificate Sign, CRL Sign
b'basicConstraints' = CA:TRUE
b'extendedKeyUsage' = TLS Web Server Authentication, TLS Web Client Authentication
b'certificatePolicies' = Policy: X509v3 Any Policy
b'crlDistributionPoints' = Full Name: URI:http://crl.usertrust.com/USERTrustRSACertificationAuthority.crl
b'authorityInfoAccess' = OCSP - URI:http://ocsp.usertrust.com
INFO: Found section: CERTIFICATE
INFO: description:
subject = /C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority
issuer = /C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority
not before 2010-02-01 00:00:00
not after 2038-01-18 23:59:59
signature algorithm = b'sha384WithRSAEncryption'
3 extensions:
b'subjectKeyIdentifier' = XXX
b'keyUsage' = Certificate Sign, CRL Sign
b'basicConstraints' = CA:TRUE
DEBUG: Verifying certificate order (leaf first).
DEBUG: Verifying validity dates of certificates.
DEBUG: Verifying that the key is valid.
DEBUG: Verifying the key size.
INFO: Key size is 2048 bits
DEBUG: Verifying certificates in the chain.
DEBUG: Adding root certificate to store: /C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority
DEBUG: Verifying certificate: /C=GB/O=Sectigo Limited/CN=Sectigo Public Server Authentication Root R46
DEBUG: Adding certificate to store: /C=GB/O=Sectigo Limited/CN=Sectigo Public Server Authentication Root R46
DEBUG: Verifying certificate: /C=GB/O=Sectigo Limited/CN=Sectigo Public Server Authentication CA OV R36
DEBUG: Adding certificate to store: /C=GB/O=Sectigo Limited/CN=Sectigo Public Server Authentication CA OV R36
DEBUG: Verifying certificate: /C=XXX/ST=XXX/O=XXX/CN=aria-vrops-fqdn
DEBUG: Adding certificate to store: /C=XXX/ST=XXX/O=XXX/CN=aria-vrops-fqdn
DEBUG: Verifying certificate attributes for all certificates in the chain.
DEBUG: Verifying attributes of leaf certificate /C=XXX/ST=XXX/O=XXX/CN=aria-vrops-fqdn
DEBUG: Basic Constraints extension was not specified.
DEBUG: Verifying attributes of intermediate certificate /C=GB/O=Sectigo Limited/CN=Sectigo Public Server Authentication CA OV R36
DEBUG: Basic Constraints extension was not specified.
DEBUG: keyUsage extension was not specified.
DEBUG: Verifying attributes of intermediate certificate /C=GB/O=Sectigo Limited/CN=Sectigo Public Server Authentication Root R46
DEBUG: Basic Constraints extension was not specified.
DEBUG: keyUsage extension was not specified.
DEBUG: Verifying attributes of root certificate /C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority
DEBUG: Basic Constraints extension was not specified.
DEBUG: keyUsage extension was not specified.
DEBUG: Root certificate in chain is self-signed.
INFO: Writing fixed file to "bags.pem".
INFO: Corrected file is valid: bags.pem
Now I looked at the bags.pem file and did not look like a traditional cert chain, I wont post the whole thing but it starts as such:
subject = /C=XXX/ST=XXX/O=XXX/CN=aria-fqdn
issuer = /C=GB/O=Sectigo Limited/CN=Sectigo Public Server Authentication CA OV R36
not before 2025-12-08 00:00:00
not after 2026-12-08 23:59:59
signature algorithm = b'sha256WithRSAEncryption'
10 extensions:
b'authorityKeyIdentifier' = XXX
b'subjectKeyIdentifier' = XXX
b'keyUsage' = Digital Signature, Key Encipherment
b'basicConstraints' = CA:FALSE
b'extendedKeyUsage' = TLS Web Server Authentication
b'certificatePolicies' = Policy: 1.3.6.1.4.1.6449.1.2.1.3.4 CPS: https://sectigo.com/CPSPolicy: 2.23.140.1.2.2
{...it continues to show the thumprints ect...similar to above}
b'subjectAltName' = DNS: correct fqdn for aria
-----BEGIN CERTIFICATE-----
XXX
-----END CERTIFICATE-----
subject = /C=GB/O=Sectigo Limited/CN=Sectigo Public Server Authentication CA OV R36
issuer = /C=GB/O=Sectigo Limited/CN=Sectigo Public Server Authentication Root R46
not before 2021-03-22 00:00:00
not after 2036-03-21 23:59:59
signature algorithm = b'sha384WithRSAEncryption'
8 extensions:
-----BEGIN CERTIFICATE-----
XXX
-----END CERTIFICATE-----
subject = /C=GB/O=Sectigo Limited/CN=Sectigo Public Server Authentication Root R46
issuer = /C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority
not before 2021-03-22 00:00:00
not after 2038-01-18 23:59:59
signature algorithm = b'sha384WithRSAEncryption'
8 extensions:
{.......}
-----BEGIN CERTIFICATE-----
XXX
-----END CERTIFICATE-----
subject = /C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority
issuer = /C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority
not before 2010-02-01 00:00:00
not after 2038-01-18 23:59:59
signature algorithm = b'sha384WithRSAEncryption'
3 extensions:
b'subjectKeyIdentifier' = XXX
b'keyUsage' = Certificate Sign, CRL Sign
b'basicConstraints' = CA:TRUE
-----BEGIN CERTIFICATE-----
XXX
-----END CERTIFICATE-----
-----BEGIN PRIVATE KEY-----
XXX
-----END PRIVATE KEY-----
So bags.pem clearly shuffled up the order of the certs and private key compared to the KB.
I tried installing bags.pem through the /admin page, it accepted it, installed, and made no difference. Same errors.
Some more searching on the web gave me some other things to try. I ran the following:
From the VCENTER CLI:
echo | openssl s_client -connect localhost:443 2>/dev/null | openssl x509 -noout -purpose | grep 'SSL client :'
SSL client : YES
From the Aria Ops CLI:
SSL client : No
Is this the issue? Or part of the issue? Is it normal? I have no idea!
Then I tried
openssl s_client -host oppositehost -port 443
from vc cli to aria ops fqdn (they both hang) if I hit enter:
read R BLOCK
HTTP/1.1 400 Bad Request
Date: Tue, 09 Dec 2025 20:40:24 GMT
Server: Apache
Content-Length: 226
Connection: close
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
</p>
</body></html>
closed
from aria ops cli to vc fqdn I get a similar msg
HTTP/1.1 400 Bad Request
content-length: 11
content-type: text/plain
date: Tue, 09 Dec 2025 20:38:52 GMT
connection: close
Bad Requestclosed
The last thing I will add as I have to run for the day. Is when I looked at the certs via a browser under "extended key usage" for Aria ops I get:
Not critical TLS WWW Server Authentication (OID.1.3.6.1.5.5.7.3.1)
When I look at the same field in my VC cert presented in the browser I get:
Not critical TLS WWW Server Authentication (OID.1.3.6.1.5.5.7.3.1) TLS WWW Client Authentication (OID.1.3.6.1.5.5.7.3.2)
So I'm at a loss on how to troubleshoot this. I am no cert expert!
I have the ability to replace the cert in Aria Ops and mint a new one if need be. I can't do the same for VC as that's production.
Any clues?! Sorry the post is long, but details are important and it may give one of you that 'ah ha!' moment that I am not seeing.
Thanks in advance!!!
-------------------------------------------