VCP-DCV vSphere Security Practice Question

Exhibit

Refer to the exhibit.
```
~ # openssl x509 -in /etc/vmware/ssl/rui.crt -noout -fingerprint -sha256
SHA256 Fingerprint: AB:CD:EF:12:34:56:78:90:AB:CD:EF:12:34:56:78:90:AB:CD:EF:12:34:56:78:90:AB:CD:EF:12:34:56:78:90
```

An administrator is adding an ESXi host to vCenter Server and is prompted to verify the host's certificate thumbprint. The administrator compares it to the output above and it matches. However, the add operation fails with a certificate verification error. What else could be the issue?

⚠ Common exam trap

A common mix-up: candidates assume thumbprint verification alone guarantees certificate validity, overlooking that vCenter Server also performs hostname matching as part of TLS certificate validation.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

The certificate common name does not match the hostname

When adding an ESXi host to vCenter Server, the thumbprint verification ensures the host's certificate fingerprint matches what is expected, but it does not validate the certificate's subject attributes. If the certificate's Common Name (CN) does not match the ESXi host's FQDN or IP address used during the add operation, vCenter Server will reject the connection with a certificate verification error, even if the thumbprint is correct. This is because vCenter Server performs hostname verification as part of TLS/SSL certificate validation to prevent man-in-the-middle attacks.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
The vCenter Server's certificate is invalid
Why it's wrong here
The vCenter certificate's validity is irrelevant here: the prompt compares the ESXi host's thumbprint, which already matched. The failure typically stems from the host's certificate not being trusted or the thumbprint verification step being rejected, so the vCenter certificate is not the axis being checked.
✗
The certificate has expired
Why it's wrong here
Thumbprint matching only confirms the certificate's hash; an expired certificate still presents the same thumbprint but fails validity-period checks during the TLS handshake, so vCenter rejects it. It is tempting because expiry is a common certificate fault, and renewing the certificate would be the correct fix when the validity dates have genuinely lapsed.
✗
The certificate is not signed by a trusted Certificate Authority
Why it's wrong here
A matching thumbprint does not imply trust; if the ESXi certificate is self-signed or issued by an untrusted CA, vCenter's trust store rejects it regardless of the hash match. It is tempting because untrusted CA chains are a frequent cause of verification failures, and importing the CA into vCenter's trust store is the correct remedy in that scenario.
✓
The certificate common name does not match the hostname
Why this is correct
Thumbprint matching only proves the certificate's authenticity, not its identity. vCenter also validates that the certificate's common name or subject alternative name matches the hostname or IP used to add the host, so a mismatch there still triggers verification failure despite the correct thumbprint.

Go deeper

VCP-DCV vSphere Security Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question