Secure LDAP configuration fails with no error detail — tried both public CA and self-signed certs, all documented requirements verified

Blaine 0 Reputation points
2026-08-26T06:39:16.4633333+00:00

Environment

Microsoft Entra Domain Services managed domain, custom DNS name (not *.onmicrosoft.com)

Cloud-only Microsoft Entra ID tenant (no on-prem AD sync)

Goal: enable Secure LDAP (LDAPS) for an internal application binding over LDAP

Problem

Every attempt to save a certificate on the Secure LDAP blade fails with only:

Secure LDAP configuration failed. Please check Activity log for more detail.

The Activity Log shows no failure entry at all — only a "Write Domain Service" operation that goes Accepted (HTTP 202) → Started, and never resolves to a visible Failed or Succeeded state in the log itself. I pulled the full JSON for the entry and it only contains the "EndRequest" acceptance event, no error payload.

What I've tried (4 attempts, all failed identically)

Attempt 1 — Public CA cert (Let's Encrypt), non-wildcard

CN = exact managed domain name (no wildcard)

RSA 2048, valid ~90 days

Result: failed

Attempt 2 — Public CA cert (Let's Encrypt), same but PFX re-exported with legacy TripleDES-SHA1 (-keypbe PBE-SHA1-3DES -certpbe PBE-SHA1-3DES -macalg SHA1 -iter 1)

Verified with openssl pkcs12 -info that MAC/encryption were correctly TripleDES-SHA1

Result: failed (same generic message)

Attempt 3 — Public CA cert (Let's Encrypt), reissued as wildcard

After finding Microsoft's documented requirement that the subject/SAN must be a wildcard (*.<managed-domain>) plus the bare domain as a second SAN

Verified via openssl x509 -noout -text:

Subject: CN=*.<managed-domain>

  SAN: `DNS:*.<managed-domain>, DNS:<managed-domain>`
  
     Key Usage: Digital Signature, Key Encipherment (critical)
     
        Extended Key Usage: TLS Web Server Authentication
        
           RSA 2048
           
              Full chain present (leaf → intermediate → cross-sign → root), 4 certs total
              
                 Valid ~90 days (well within "not expired," but only just inside the low end of the documented "3-6 months" window)
                 
                    PFX confirmed TripleDES-SHA1 / SHA1 MAC / iteration 1
                    
                    Result: failed (same generic message)

Attempt 4 — Self-signed cert, wildcard, 1-year validity

Generated via OpenSSL, subject/SAN identical shape to Attempt 3, RSA 2048, correct key usage/EKU, correct PFX cipher

Validity: full 1 year (comfortably clears any "expires soon" threshold, ruling out cert lifetime as a variable)

Result: failed (same generic message)

Additional things ruled out

DNS domain name match: confirmed the cert's CN exactly matches the managed domain's DNS name shown on the Properties blade, including exact case.

Azure Policy interference: checked Policy → Compliance scoped to the resource group. Only the default Defender for Cloud "ASC Default" initiative is assigned, and every relevant policy there uses an Audit effect, not Deny/deployIfNotExists — so nothing there should be capable of blocking the write. No deployIfNotExists policy actions appear in the Activity Log (unlike a similar thread I found where a policy action was visibly part of the failure).

Tried the save from a fresh browser session / re-authenticated, in case of a stale portal state — same result.

Question

Since the certificate appears to satisfy every documented requirement (trusted issuer path, wildcard subject+SAN, correct key usage/EKU, TripleDES-SHA1 PFX encryption, valid dates, correct CN) across two structurally different certificates, and Activity Log gives no actionable detail — is there a backend log or diagnostic Microsoft support could check on this managed domain? I don't currently have an Azure support plan that allows a formal technical ticket, so posting here first.

Happy to provide the exact openssl x509 -text output (with domain name redacted) if useful for troubleshooting.

Azure Cloud Services
Azure Cloud Services

An Azure platform as a service offer that is used to deploy web and cloud applications.

0 comments

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Blaine 0 Reputation points
    2026-09-01T16:52:19.6666667+00:00

    Thank you for the feedback and suggestions. I figured I'd give this a last attempt directly on one of the domain joined systems. I created a self-signed cert on the server using the mmc and the certificate snap-in, exported it and then uploaded it to the Entra Domain site. It worked as expected. I then exported the server side .cer file and deployed that using a GPO to all AD joined systems. Everything is functioning as expected.

    I created the original certs on my Mac. There should be no differences in the end product but, obviously, something was amiss. We can mark this as resolved.

    Thanks

    Was this answer helpful?

    0 comments
  2. Allan Solomon Mejia 8,500 Reputation points
    2026-08-27T20:15:32.52+00:00

    Hello @Blaine

    Based on what you’ve already tested, this no longer looks like a normal certificate-format problem. Your wildcard subject/SAN, RSA key, Server Authentication EKU, key usage, private key, PFX encryption, and certificate lifetime all line up with Microsoft’s documented LDAPS requirements.

    One thing I would still verify is that the certificate matches the Microsoft Entra Domain Services managed-domain DNS name, not another Entra tenant/custom-domain name. Microsoft specifically notes that the domain controller uses the Domain Services domain name when selecting the LDAPS certificate.

    Since the Azure operation returns HTTP 202 but never exposes a useful failure payload, and both a public CA certificate and a self-signed certificate fail identically, this points more to a backend Domain Services provisioning/validation issue than client-side LDAPS connectivity. The normal connectivity checks such as port 636, DNS resolution, and CA trust become relevant after LDAPS is successfully enabled; they would not normally explain why the certificate cannot be applied to the managed domain in the first place.

    At this stage, you may:

    • Check Microsoft Entra Domain Services > Health for any active alerts or degraded state.
    • Confirm that no other Domain Services operation is still pending, since Microsoft states that managed-domain settings cannot be modified while an LDAPS configuration operation is in progress.
    • Wait for any current operation to fully settle, then retry once with the known-good self-signed PFX.
    • If it still fails, open an Azure support request for Microsoft Entra Domain Services and provide the managed-domain resource ID, operation/correlation ID, timestamp, and the Write Domain Service Activity Log entry.

    Microsoft’s troubleshooting guidance recommends opening an Azure support request when the documented LDAPS checks don't resolve the issue.

    So yes, Microsoft support should be able to investigate service-side telemetry that isn’t surfaced in the Activity Log. Given how much certificate validation you’ve already done, I wouldn’t keep regenerating certificates unless Microsoft identifies a specific validation failure.

    Sharing these references with you:

    Configure Secure LDAP for Microsoft Entra Domain Services

    Troubleshoot Secure LDAP connectivity

    Resolve Secure LDAP alerts

    Please "Accept the Answer" if this information helped you. This will help us and others in the community.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.