Too Many Certificates! - Misconfiguring LDAPS in vSphere

If you’ve used Active Directory over LDAP in vSphere, there’s a chance you’ve seen this alarm message before. While this is one of the more self-explanatory alarms you could get, there is a strange quirk to be aware of that may occur if you upload the wrong LDAPS certificates.

Let’s start by pinpointing which LDAP certificate is about to expire. vSphere Client doesn’t offer a way to view the LDAP certificates from the web UI, so we’ll have to use this command in the CLI: /opt/vmware/bin/sso-config.sh -get_identity_sources

root@sfo-m01-vc01 [ ~ ]# /opt/vmware/bin/sso-config.sh -get_identity_sources

Total number of identitysources retrieved for tenant:vsphere.local : 3
(If the value is undefined against a param, then you might notice "UndefinedConfig" against it.)

********** IDENTITY SOURCE INFORMATION **********
IdentitySourceName        :  vsphere.local
DomainType                :  SYSTEM_DOMAIN

********** IDENTITY SOURCE INFORMATION **********
IdentitySourceName        :  localos
DomainType                :  LOCAL_OS_DOMAIN

********** IDENTITY SOURCE INFORMATION **********
IdentitySourceName        :  rainpole.io
DomainType                :  EXTERNAL_DOMAIN
Identity Settings:
  alias                   :  UndefinedConfig
  authenticationType      :  PASSWORD
  userBaseDN              :  CN=Users,DC=rainpole,DC=io
  groupBaseDN             :  CN=Users,DC=rainpole,DC=io
  username                :  [email protected]
  providerType            :  IDENTITY_STORE_TYPE_LDAP_WITH_AD_MAPPING
  servicePrincipalName    :  placeholder
  useMachineAccount       :  false
  FriendlyName            :  rainpole.io
  SearchTimeoutInSeconds  :  0
Connection Settings:
URLs:
    0:  ldaps://dc1.rainpole.io
Certificates:
    0:    subject:  CN=sfo-m01-vc01.rainpole.io, O=VMware, L=Palo Alto, ST=CA, C=US
           issuer:  CN=rainpole-DC1-CA, DC=rainpole, DC=io
        NotBefore:  Tue Nov 29 17:19:41 EST 2022
         NotAfter:  Thu Nov 30 17:19:41 EST 2023
           Serial:  624420865640669802289276412127527138635022351
    1:    subject:  CN=dc1.rainpole.io, O=VMware, L=Palo Alto, ST=CA, C=US
           issuer:  CN=rainpole-DC1-CA, DC=rainpole, DC=io
        NotBefore:  Tue Nov 14 17:36:41 EST 2022
         NotAfter:  Thu Nov 13 17:36:41 EST 2025
           Serial:  624420865647515184491977903144204285606101009
Attributes:
  http://schemas.xmlsoap.org/claims/UPN                           :  userPrincipalName
  http://rsa.com/schemas/attr-names/2009/01/GroupIdentity         :  memberof
  http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname :  givenName
  http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname   :  sn
  http://vmware.com/schemas/attr-names/2011/07/isSolution         :  subjectType
Flags::
  Flags=0; [Default: recursively computing nested groups, no site affinity is enabled for AD over Ldap identity providers.]

Under the rainpole.io identity source, we can see two certificates. One for the vCenter server itself (sfo-m01-vc01.rainpole.io) and another for the domain controller (dc1.rainpole.io). The vCenter certificate is about to expire, so that is clearly the culprit for the expiration alarm. If this is the first time you’re looking at this output, you might think this is something like a certificate trust chain with the domain controller as the root. However, this is actually nothing more than a list of individual certificates we told vCenter to use when validating the domain controller’s certificate. If dc1.rainpole.io presents the same certificate we have in the certificate store, or if the store contains the CA certificate that signed dc1.rainpole.io’s certificate, then vCenter determines it can trust dc1.rainpole.io and establishes the LDAPS connection.

Of course, this configuration doesn’t make sense because why would vCenter want its own SSL certificate to validate another entity? The answer is that it doesn’t. Even though it’s in the identity source configuration, vCenter will never be able to use that certificate for LDAPS. So why is it there and why is vCenter throwing an expiration alarm for it?

Let’s consider an infrastructure administrator configuring Active Directory over LDAP for the first time. In their first attempt, they mistakenly uploaded the SSL certificate for vCenter. Possibly thinking that this is the certificate vCenter will use to validate its own identity. Since vCenter is unable to use that certificate to validate the public certificate for dc1.rainpole.io, it refuses to save the configuration.

The admin realizes they were supposed to upload the domain controller’s certificate, not vCenter’s. Since vSphere client doesn’t allow them to delete the other certificate without canceling the attempt, they decide to just leave it in there. The admin adds the domain controller’s certificate and is now able to successfully save the configuration. All is good now, right?

The issue is that both of those certificates are now included in the identity source configuration. If vCenter can use any of those certificates to validate the domain controller, it will consider the entire configuration to be valid. As long as you include just one working certificate, you can upload whatever other certificates you like. Even a random self-signed certificate.

This is important to know because vSphere will throw the LDAP certificate expiration alarm if any of the certificates in the list are about to expire. Even if those certificates are completely unusable for LDAPS. So if you mistakenly upload extra certificates, you could give yourself unnecessary alerts down the road. Thankfully, LDAPS login will still work even if you let the extra certificate expire. But if you let that happen, vCenter won’t let you edit the LDAPS configuration anymore, even to upload new certificates. You’ll have to delete and re-add the entire configuration. Although doing that is technically what VMware documentation recommends anyway whenever you have to replace LDAPS certificates. ¹

So when configuring LDAPS for vSphere, make sure you’re only including the correct certificates. Aside from giving you annoying alerts, there are also theoretical security implications from having extraneous certificates. For example, if you include an unnecessary certificate and an attacker obtains its private key, they could intercept vCenter’s authentication traffic to the domain controller. While I wouldn’t consider this to be a very likely attack vector, it is still an additional and unnecessary risk to assume.

VMware documentation recommends only using the certificates for the domain controllers themselves. ² You can use a CA certificate instead, which will reduce your certificate requirement to just that one CA certificate. But providing the domain controller’s certificate is theoretically more secure since it locks the configuration down to just those specific domain controllers, not all other servers in the domain with CA-signed certificates. In any case, both of these options are much better than including random certificates.