AD FS SSL certificate expired

AD FS stops trusting its own federation endpoints when adfs certificate expired material still sits on the Web Application Proxy or the federation TLS listener—users see generic sign-in errors before Entra ID ever returns a code.

Hybrid workers notice Microsoft 365 sign-in loops while on-prem apps using WS-Federation fail with certificate validation errors. Remote users hitting the WAP published URL get TLS warnings in the browser before the AD FS login page loads.

Operations teams sometimes confuse token-signing certificate rollover with the SSL certificate on the public federation HTTPS URL. Both are X.509, but only the TLS listener certificate affects HTTPS handshakes to federation metadata and the interactive login page.

First response

Capture the failing URL (metadata, login, or MEX endpoint), the thumbprint AD FS reports in Event ID 120, and an external openssl s_client trace against the same hostname users type. Note whether failure is at the WAP edge or on the AD FS farm members directly.

Export federation metadata from a machine outside corporate DNS split-brain:

Get-AdfsCertificate -CertificateType Token-Signing,Token-Decrypting,Service-Communication | Format-Table Thumbprint,NotAfter,StoreLocation,StoreName

Paste NotAfter for Service-Communication next to the openssl notAfter from port 443. Token-signing certs have different renewal workflows; do not replace them when only TLS expired.

See also How to fix an expired SSL certificate and RADIUS EAP-TLS certificate expired.

What this error means

Browsers and SDKs validate PKIX dates on the HTTPS certificate presented at the federation DNS name. AD FS still signs SAML and OIDC tokens with valid token-signing keys, but clients cannot download metadata or POST credentials over TLS when the service-communication or WAP certificate is past its notAfter date.

Entra ID federation checks reach your STS over HTTPS. If the leaf expired, Microsoft's validation of your metadata URL fails and cloud sign-in may degrade even when LAN users reach AD FS through an internal load balancer with a different certificate.

Clock skew on domain controllers rarely causes this symptom; expired server certificates do. Trust the external openssl dates over screenshots from a laptop that trusts an internal enterprise CA for the same hostname.

The Web Application Proxy layer terminates TLS for Internet users before traffic reaches the AD FS farm. An expired cert on WAP never touches token issuance logic, yet it blocks every external login attempt. Internal testers who bypass WAP and hit farm members over HTTPS can falsely conclude the farm is fine while customers only use the published URL.

Common causes

Certbot or a commercial reissue updated PEM files on one farm member while NLB still pins an old thumbprint on another node. Web Application Proxy still references the previous service-communication thumbprint after Set-AdfsCertificate on the farm only.

Federation DNS points at WAP, but operators renewed the certificate bound on AD FS servers behind the proxy, never updating WAP's Set-WebApplicationProxySslCertificate binding. Metadata URL and user login URL then disagree on which cert is live.

Wildcard reissues dropped the exact SAN for enterpriseregistration or device-enrollment companion hostnames still referenced in MDM docs. Internal CA-issued service certs expired because GPO auto-enrollment stalled on the AD FS service account.

Active Directory Federation Services high availability farms that use shared IIS bindings sometimes fail to replicate LocalMachine certificate updates when one node was down during import. When that node rejoins the farm, health probes succeed on TCP while the revived node still serves the previous serial to a fraction of users behind round-robin.

Reverse proxies in front of WAP that terminate TLS at an older layer can present a different certificate than Set-WebApplicationProxySslCertificate expects on the inner hop. openssl from the Internet shows the outer expired leaf even after inner farm work completed.

Confirm from the outside

Start every triage from the same hostname Entra and partners configure in federation trust—not from an internal-only DNS label that bypasses WAP. Record serial number, issuer, and notAfter before you touch stores so rollback is evidence-based.

OpenSSL

echo | openssl s_client -connect adfs.example.com:443 -servername adfs.example.com 2>/dev/null | openssl x509 -noout -dates -subject -issuer

Run from the public Internet, not only from a domain-joined admin workstation.

How to read the output

Compare notAfter to Service-Communication from Get-AdfsCertificate. Subject SANs must include the federation DNS name Entra ID and partners call. Issuer change without attaching the full chain causes trust errors that mimic expiry—record serial numbers before and after renewal.

Repeat the handshake against the exact metadata path and login path URLs listed in your federation trust XML. If dates differ between paths, you are dealing with multiple bindings or load balancing inconsistencies rather than a single global fix.

curl

curl -vI --connect-timeout 10 https://adfs.example.com/FederationMetadata/2007-06/FederationMetadata.xml 2>&1 | grep -Ei 'expire|SSL certificate|subject:|issuer:'

Metadata fetch must succeed without -k for partner federation to stay healthy.

PowerShell smoke test

Test-NetConnection adfs.example.com -Port 443
Invoke-WebRequest -Uri https://adfs.example.com/FederationMetadata/2007-06/FederationMetadata.xml -UseBasicParsing | Select-Object StatusCode

Invoke-WebRequest fails with certificate errors when the live listener still serves expired material.

When you have WAP access, compare external openssl output with Get-WebApplicationProxySslCertificate on each proxy node. Matching thumbprints across proxies and farm nodes closes the loop before you request a new reissue from the CA.

Fix checklist

1. Identify which certificate role failed: TLS (service-communication / WAP) vs token-signing (different cmdlet path).
2. Request or reissue a publicly trusted cert whose SAN lists every federation and WAP published name.
3. On each AD FS node: import PFX, run Set-AdfsCertificate -CertificateType Service-Communication with the new thumbprint.
4. On WAP servers: Set-WebApplicationProxySslCertificate with the new thumbprint and confirm Set-AdfsWebApplicationProxyApplication bindings.
5. Restart AD FS service or run farm consistency checks; verify NLB health probes hit nodes presenting the new cert.
6. Re-fetch federation metadata; update Entra ID federation trust if thumbprint or endpoint URLs changed (document in change record).
7. Validate Microsoft 365 hybrid sign-in and a sample relying-party SAML app.
8. Archive openssl and Get-AdfsCertificate output in the ticket.

After step four, run external metadata and login probes from a non-domain machine. Internal success with external failure almost always means WAP or edge binding work remains.

Schedule enough time for Entra federation trust refresh and partner notification when your metadata URL exposes new certificate material. Some partners poll hourly; others cache longer, so communicate maintenance windows even when your side shows green immediately.

When to use automation

Federation URLs are easy to forget because token-signing rollover gets calendar reminders while TLS listener certs do not. Monitor the live HTTPS certificate on federation DNS and WAP-published hostnames—the files in LocalMachine store on one node are not proof users see new dates.

Run a free live check at /check against federation DNS from outside your network, then schedule threshold alerts at 30, 14, 7, and 1 day before notAfter. Pair TLS watches with RDAP domain expiry on the registration for the federation name so revalidation is not blocked by registrar lapses.