Error: "Could not read certificate from <stdin>" when retrieving LDAPS certificate from Active Directory domain controller
search cancel

Error: "Could not read certificate from <stdin>" when retrieving LDAPS certificate from Active Directory domain controller

book

Article ID: 441900

calendar_today

Updated On:

Products

VMware vCenter Server

Issue/Introduction

When following step 1 of Configuring a vCenter Single Sign-On Identity Source using LDAP with SSL (LDAPS) to extract the LDAPS certificate from an Active Directory domain controller, the openssl command returns no certificate and fails with an error similar to:

root@VCSA-01 [ ~ ]# openssl s_client -showcerts -connect dc.domain.com:636 </dev/null 2>/dev/null | openssl x509 -outform PEM
Could not read certificate from <stdin>
C0A11793CA7F0000:error:1608010C:STORE routines:ossl_store_handle_load_result:unsupported:crypto/store/store_result.c:151:
Unable to load certificate

Because no certificate is returned, the LDAPS identity source cannot be configured in vCenter SSO.

Environment

  • VMware vCenter Server 7.x
  • VMware vCenter Server 8.x
  • VMware vCenter Server 9.x

Cause

The openssl command on the VCSA piped no parseable certificate to openssl x509, so the second openssl call failed. This means the target domain controller did not present a usable server certificate during the TLS handshake on port 636.

The domain controller is expected to present its own SSL/TLS server certificate when a client connects on 636. That certificate must:

  • Have the Server Authentication Enhanced Key Usage (EKU)
  • List the FQDN being connected to in the Subject Alternative Name (SAN)
  • Chain to a Certificate Authority whose root vCenter will trust
  • Be valid (not expired) and have a usable private key on the domain controller

The domain controller does not need to be a Certificate Authority itself. It only needs a server certificate that meets the above requirements. The issuing CA can be an Enterprise CA, a standalone internal CA, or a third-party CA.

Common reasons the domain controller does not present a usable certificate on 636:

  • LDAPS is not enabled on the domain controller because no Server Authentication certificate is installed in its local computer certificate store
  • Port 636 is not reachable from the VCSA due to a firewall or routing issue
  • The certificate the domain controller is presenting is expired, has the wrong SAN, or is missing the Server Authentication EKU
  • A TLS protocol or cipher mismatch is preventing the handshake from completing

Resolution

  1. From the VCSA, confirm port 636 is reachable on the domain controller:

    nc -zv dc.domain.com 636

    Replace dc.domain.com with the FQDN of your domain controller. If this fails, resolve network reachability before continuing.

  2. From a Windows administrative workstation, confirm LDAPS is actually being served by the domain controller using ldp.exe:

    1. Run ldp.exe.
    2. Select Connection > Connect.
    3. Enter the domain controller FQDN in Server.
    4. Set Port to 636.
    5. Check SSL.
    6. Click OK. A successful connection confirms the domain controller is serving LDAPS. A failure here means the problem is on the domain controller side, not on the VCSA side.

  3. If ldp.exe fails to connect, confirm the domain controller has a valid server certificate. On the domain controller, in an elevated PowerShell session:

    Get-ChildItem Cert:\LocalMachine\My | Where-Object { $_.EnhancedKeyUsageList -match "Server Authentication" } | Format-List Subject, DnsNameList, NotAfter, Issuer

    Confirm that at least one returned certificate:

    • Lists the domain controller FQDN in DnsNameList (the SAN)
    • Has a NotAfter date in the future
    • Is issued by a CA whose root is trusted by the clients that will use LDAPS

    If no certificate matches, work with the directory or PKI administrators to issue and install one. Microsoft's LDAP over SSL (LDAPS) Certificate documentation describes the certificate requirements.

  4. Once ldp.exe connects successfully over SSL, return to the VCSA and re-run the openssl command from step 1 of KB 316596:

    openssl s_client -showcerts -connect dc.domain.com:636 </dev/null 2>/dev/null | openssl x509 -outform PEM

    The certificate output should now be returned and can be saved to a .cer file for use in the SSO identity source configuration.

    If your environment uses more than one domain controller for LDAPS (for example, a primary and a secondary), repeat this command against each domain controller FQDN and save each certificate to its own .cer file. All applicable certificates can be uploaded to the same identity source.

  5. Continue with step 2 of KB 316596 to add the identity source.

Additional Information

Powered by Wolken Software