LDAPS certificate expired

ldaps certificate expired blocks StartTLS and LDAPS binds when the directory’s TLS leaf is past notAfter—renew on the LDAP listener, not the VPN portal cert.

Identity engineers notice SSO failures, failed ldapsearch sessions, and application logs citing certificate has expired or TLS handshake failure. The directory still answers plain LDAP on 389 while 636 or StartTLS paths break.

Applications often cache successful binds for hours, so expiry surfaces suddenly at peak login traffic. Verify the certificate the LDAP service presents, not only the corporate web gateway.

First response

Record the failing bind DN, target hostname, port (636 versus 389 StartTLS), and client library (OpenLDAP, ADSI, Java JNDI). Attach ldapsearch or ldp.exe error text, openssl output for HOST:636 with correct SNI, and for Active Directory whether LDAPS shares the same cert as IIS or a dedicated template.

Capture whether failures are cluster-wide or isolated to one domain controller replica—stale cert on one DC breaks round-robin LDAP VIPs.

Before editing GPO trust or application connection strings, save openssl notAfter and serial in the ticket. Incidents titled ldaps certificate expired usually need directory listener renewal, not client-side cache clears alone.

Link email TLS certificate expired when mail and directory share a Microsoft PKI template workflow, and openssl s_client show certs expiry for chain depth checks after renewal.

What this error means

LDAPS wraps LDAP in TLS from the first byte on port 636. StartTLS upgrades cleartext LDAP on 389 after an extended operation. In both cases the TLS stack validates notAfter before any bind succeeds.

Expired server certificates fail closed: clients refuse to send credentials across the tunnel. PKIX does not grant grace periods because the directory still answers on plain LDAP—security policies should block that fallback during incidents.

Name mismatches produce different errors than expiry. Confirm dates first; only then chase hostname or enterprise CA trust issues. Intermediate expiry can surface as handshake failure even when the leaf portal screenshot looks valid—read the full served chain.

Common causes

AD LDAPS cert lagging DC promotion. A new domain controller serves the default machine cert with an old validity while others were renewed via auto-enrollment.

OpenLDAP cert files updated without slapd reload. PEM paths in slapd.conf or cn=config changed on disk while the daemon still served previous material.

Load-balanced LDAPS without synchronized PEM deploys. One backend directory still mounts yesterday’s fullchain.

StartTLS pointing at wrong cert name. Slapd selects cert by configured TLSCertificateFile only; SNI-style routing does not apply on many builds.

Intermediate CA expired. Leaf looks valid in a portal screenshot, but served chain still includes an expired issuer.

Forgotten admin bind URLs. Monitoring tools hit ldaps://ldap-internal while operators renewed only the public-facing hostname.

Confirm from the outside

OpenSSL on LDAPS

HOST=ldap.example.com
echo | openssl s_client -connect "${HOST}:636" -servername "${HOST}" 2>/dev/null \
  | openssl x509 -noout -dates -subject -issuer

StartTLS probe

openssl s_client -connect "${HOST}:389" -starttls ldap </dev/null 2>/dev/null \
  | openssl x509 -noout -dates

ldapsearch probe

ldapsearch -H ldaps://${HOST}:636 -x -b '' -s base '(objectClass=*)' 2>&1 | head -20

Without disabling TLS, a failed handshake surfaces Can't contact LDAP server or explicit certificate verify failed.

How to read the output

Past notAfter on the leaf served during the handshake explains LDAPS failures for trusted clients. Read Subject Alternative Name for the FQDN your applications use in ldaps URLs. Compare serial numbers across DCs when VIPs front multiple directories.

Fix checklist

1. Prove expiry with openssl on 636 and StartTLS separately.
2. Issue a renewal that includes every FQDN clients use in LDAP URLs.
3. Install full chain per vendor docs (AD bind cert in ntds personal; OpenLDAP TLSCertificateFile plus TLSCACertificateFile).
4. Reload slapd or restart AD DS SSL services after cert import per vendor runbook.
5. Deploy the same PEM set to every replica behind the load balancer.
6. Re-run ldapsearch without LDAPTLS_REQCERT=never.
7. Test application binds that failed in production (SSO, JNDI, ldap_sync).
8. Add live TLS monitoring on the LDAPS VIP.

Document before and after serial numbers for auditors. If auto-enrollment is the long-term fix, verify GPO scope includes every OU that hosts directory replicas.

Rollout for ldaps certificate expired should hit every DC that terminates ldaps:// for the VIP, not only the PDC emulator. Staged maintenance windows help when thousands of laptops rebind simultaneously—communicate that brief retry loops are expected while replicas reload TLS material. After reload, sample binds from each data center before lifting change freezes.

Triage myths: clearing local credential caches does not extend server notAfter. Disabling certificate validation in application YAML is not a production fix. Registrar or DNS lapses rarely cause handshake expiry unless they blocked reissue weeks earlier—openssl still proves the immediate failure mode.

When to use automation

Directory teams track cert files in spreadsheets, but live LDAPS on 636 is the customer experience. Use /check for HTTPS origins your IdP calls; additionally probe 636 with openssl or LDAP synthetics from outside the DC VLAN.

Combine TLS notAfter with RDAP on the domain in LDAP URLs so DNS renewal does not block the next enrollment. Schedule alerts at 30, 14, 7, and 1 days—annual AD templates still expire when auto-enrollment pauses.