↓Skip to main content
  1. Posts/

Download Domain Controller Certificates using PowerShell for AD over LDAPS

·599 words·3 mins

If you need to integrate vSphere, VMware Identity Manager, or any other appliance directly with an Active Directory domain, (i.e. not through a dedicated identity provider) AD over LDAPS should be the only option you consider. AD over LDAP (no “S”) isn’t secure and Integrated Windows Authentication (IWA) is deprecated and will be removed in vSphere 9.

Configuring AD over LDAPS requires you to have the public certificates for your domain controllers on-hand. If you don’t already have them saved, it’s actually fairly easy to retrieve them yourself. Remember that a server sends its public certificate as part of the TLS handshake, so anyone with network access to a server can also retrieve its public certificate. Admin access to that server isn’t required.

With openssl, retrieving these certificates is pretty trivial. (For example, openssl s_client -connect dc01.sddc.lab:636 -showcerts) But, if you’re in a Windows-heavy environment that doesn’t allow you to install whatever binaries you want, (cough cough, federal government) then you often don’t have openssl readily available.

I recently figured out it’s also possible to do this with PowerShell, which is available in most Windows environments. I found this PowerShell script on GitHub from @jstangroome that retrieves the public certificate from any TLS-enabled endpoint. All you need to do is download the script and run it from a PowerShell terminal with your domain controller’s FQDN and LDAPS port. You may also need to run the Set-ExecutionPolicy command to allow the script to successfully run.

PS > Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope Process
PS > $certificate = .\Get-RemoteSSLCertificate.ps1 "dc01.sddc.lab" 636
PS > # Output certificate in base64 format
PS > $certificate.ExportCertificatePem()
-----BEGIN CERTIFICATE-----
MIIFxzCCBK+gAwIBAgITJAAAAAI7Z5ojDX/3cwAAAAAAAjANBgkqhkiG9w0BAQsF
ADBCMRMwEQYKCZImiZPyLGQBGRYDbGFiMRQwEgYKCZImiZPyLGQBGRYEc2RkYzEV
[...snip...]
m1Oari7BWdvMWY/nzTFIOeb7CeuSpkzXgKywAIWevRYy1m/EYf0frA7wv2zvZ1Yo
neYaTOsob4dlv6oda1/IkWz0jIMJiYzyiL/lnj/3XXVjRLcIg2rfmVIPow==
-----END CERTIFICATE-----
PS > # Write certificate to file 'dc01.cer' in base64 format
PS > $certificate.ExportCertificatePem() > dc01.cer

And if you want something short that you can paste into a terminal, give this a shot.

function Get-RemoteTLSCertificate {
  param($ComputerName, $Port)
  $tcpClient = New-Object System.Net.Sockets.TcpClient
  $tcpClient.Connect($ComputerName, $Port)
  $sslStream = New-Object System.Net.Security.SslStream($tcpClient.GetStream(), $true, {$true})
  $sslStream.AuthenticateAsClient('')
  $sslStream.RemoteCertificate
  $sslStream.Close()
  $tcpClient.Close()
}

PS > $certificate = Get-RemoteTLSCertificate "dc01.sddc.lab" 636
PS > # Output certificate in base64 format
PS > $certificate.ExportCertificatePem()
-----BEGIN CERTIFICATE-----
MIIFxzCCBK+gAwIBAgITJAAAAAI7Z5ojDX/3cwAAAAAAAjANBgkqhkiG9w0BAQsF
ADBCMRMwEQYKCZImiZPyLGQBGRYDbGFiMRQwEgYKCZImiZPyLGQBGRYEc2RkYzEV
[...snip...]
m1Oari7BWdvMWY/nzTFIOeb7CeuSpkzXgKywAIWevRYy1m/EYf0frA7wv2zvZ1Yo
neYaTOsob4dlv6oda1/IkWz0jIMJiYzyiL/lnj/3XXVjRLcIg2rfmVIPow==
-----END CERTIFICATE-----
PS > # Write certificate to file 'dc01.cer' in base64 format
PS > $certificate.ExportCertificatePem() > dc01.cer

This is also useful for troubleshooting purposes. For example, if AD over LDAPS authentication suddenly starts failing, it might be worthwhile to check if the domain controller is still presenting the correct certificate. Or any certificate for that matter. For example, an error at the AuthenticateAsClient method could occur if the server doesn’t present a public certificate.

PS > $certificate = Get-RemoteTLSCertificate "dc01.sddc.lab" 389
MethodInvocationException: 
Line |
   6 |    $sslStream.AuthenticateAsClient('')
     |    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Exception calling "AuthenticateAsClient" with "1" argument(s): "Unable to read data from the transport connection: Connection reset by peer."

You can view the certificate’s data to see if it’s changed from the certificate you previously configured. If the certificate suddenly has very recent NotBefore date, it could indicate that the domain controller has a new certificate.

PS > $certificate.Subject  
CN=dc01.sddc.lab
PS > $certificate.Issuer   
CN=sddc-DC01-CA, DC=sddc, DC=lab
PS > $certificate.NotBefore

Sunday, March 9, 2025 11:00:46 PM

PS > $certificate.NotAfter  

Monday, March 9, 2026 11:00:46 PM

PS > $certificate.Thumbprint
497098B4E5881C591E900C7C01978DDCD9EF13B0

Of course if this happens to you, do not reconfigure AD over LDAPS with this new certificate WITHOUT verifying its information with your Windows server admins. AD over LDAPS uses the certificate to validate that it’s talking to the correct domain controller. You want to make sure this new certificate is expected and not from an rouge domain controller setup by an attacker.