How to change Certificate on Microsoft AD FS
Learn how to manually replace an AD FS SSL/TLS certificate, update farm and WAP bindings, handle private-key access, inspect HTTP.sys, and verify federation endpoints.
AD FS uses HTTP.sys rather than an IIS website for its TLS endpoints. Modern AD FS versions manage those bindings through AD FS PowerShell cmdlets. The TLS certificate is also distinct from token-signing and token-decrypting certificates; replacing one does not imply replacing the others.
Before you begin
- Obtain a PFX with its private key, Server Authentication EKU, and the federation
service name in the SAN. Include
certauth.<federation-service-name>when the farm uses alternate TLS client binding mode. - Record
Get-AdfsProperties,Get-AdfsFarmInformation,Get-AdfsSslCertificate, the old thumbprint, and WAP servers. - Have local administrative access to every federation and Web Application Proxy node.
- Back up AD FS configuration and schedule a rolling maintenance window. Keep at least one healthy node in the load-balancer pool.
Understand AD FS certificate roles
The TLS/SSL certificate protects HTTPS endpoints and is changed with
Set-AdfsSslCertificate or, for alternate client TLS binding mode,
Set-AdfsAlternateTlsClientBinding. The service communications certificate shown
in AD FS Management is metadata for service communications and is not the HTTP.sys
binding. Token-signing and token-decrypting certificates protect tokens and
require a federation-partner rollover plan; they should not be changed during an
ordinary TLS renewal.
AD FS commonly binds the federation service name on 443, localhost on 443, device
registration names, and a client-certificate authentication endpoint. Default binding
mode uses a non-443 client-authentication port such as 49443. Alternate mode uses
certauth.<name> on 443 with SNI.
Step-by-step certificate replacement
-
On every AD FS and WAP server, import the PFX into
Cert:\LocalMachine\My:$password = Read-Host "PFX password" -AsSecureString $cert = Import-PfxCertificate -FilePath C:\secure\adfs.pfx ` -CertStoreLocation Cert:\LocalMachine\My -Password $password $thumbprint = $cert.Thumbprint Get-Item "Cert:\LocalMachine\My\$thumbprint" | Format-List Subject,DnsNameList,EnhancedKeyUsageList,HasPrivateKey,NotAfter -
Identify the farm's binding mode before choosing a cmdlet. Inspect current AD FS bindings and whether a
certauthhostname is configured:Get-AdfsSslCertificate Get-AdfsProperties | Format-List HostName,CertificateAuthenticationBinding -
On a Windows Server 2016-or-newer primary federation server at 2016 farm behavior level, update default binding mode once:
Set-AdfsSslCertificate -Thumbprint $thumbprintThis is a multi-node cmdlet and uses PowerShell remoting to update the farm. TCP 5985 must be reachable from the primary to the other nodes. On Windows Server 2012 R2, run
Set-AdfsSslCertificateon each federation server instead. -
If the farm uses alternate TLS client binding mode, use the corresponding farm cmdlet rather than the default-mode command:
Set-AdfsAlternateTlsClientBinding -Thumbprint $thumbprint -
On each WAP server, run:
Set-WebApplicationProxySslCertificate -Thumbprint $thumbprintIf an already expired trust prevents this, Microsoft documents rebuilding the WAP trust with
Install-WebApplicationProxyand the federation service name. -
Verify private-key access. On Server 2016+ the AD FS TLS cmdlets grant the
adfssrvservice principal read access to the key, so an additional ACL for the configured domain service account is not normally needed for the TLS binding. On older builds, custom certificate roles, or after a manual import/binding workflow, confirm the running identity can read the key. Find it with:Get-CimInstance Win32_Service -Filter "Name='adfssrv'" | Select-Object Name,StartName,StateIn
certlm.msc, use All Tasks > Manage Private Keys and grant only Read if the documented version and role require it. A certificate can appear bound yet fail when AD FS tries to use an inaccessible private key. -
Restart AD FS one node at a time only if the version's cmdlet did not activate the new binding cleanly or vendor guidance for the specific change requires it:
Restart-Service adfssrvDrain the node first. Do not reboot the entire farm together.
HTTP.sys and legacy procedures
Use HTTP.sys commands to inspect, not routinely replace, bindings on current AD FS:
netsh http show sslcert
Get-AdfsSslCertificateOlder AD FS documentation sometimes instructs administrators to delete and add
netsh http bindings with an AppID. Direct editing is appropriate only for the AD FS
version and binding mode whose Microsoft procedure explicitly calls for it. On modern
farms, bypassing Set-AdfsSslCertificate can miss localhost, device registration,
client-authentication, SNI, or other farm bindings and may not propagate to peers.
Product-specific considerations
For Server 2016+ multi-node updates, the primary federation server must itself be Server 2016 or newer and the farm behavior level must support the feature. Verify every node, even though the command runs once. Server 2012 R2 remains a per-node operation.
WAP certificates are local and require the WAP cmdlet on each proxy. Use the same certificate across AD FS and WAP unless the design and Microsoft requirements support separate names. Do not replace token-signing/decrypting certificates as a side effect; their rollover affects relying parties and claims providers.
Verify the new certificate
Get-AdfsSslCertificate | Format-Table HostName,PortNumber,CertificateHash
netsh http show sslcert
Get-Service adfssrvFrom outside the farm, verify both the TLS endpoint and application response:
openssl s_client -connect fs.example.com:443 -servername fs.example.com -showcerts
curl -fsS https://fs.example.com/FederationMetadata/2007-06/FederationMetadata.xmlTest sign-in, device/client certificate authentication when used, the WAP-published endpoint, and every node directly. Confirm the federation metadata still contains the expected token certificates; the TLS change should not silently alter them.
Rollback
Run the same binding-mode cmdlet with the old thumbprint and restore each WAP server. If needed, restart nodes one at a time and re-test metadata and sign-in. Keep the old certificate installed until all farm and proxy endpoints are confirmed.
Common problems
- The certificate is in Current User rather than Local Computer, or lacks a private key.
- The federation service or
certauthname is missing from SANs. - A Server 2016+ farm command cannot reach peers over PowerShell remoting.
- WAP nodes were not updated after the AD FS farm.
- An administrator changes only one
netshbinding and leaves other AD FS bindings stale. - A TLS renewal is confused with service-communications or token-certificate rollover.
Automating certificate replacement with aethercert
The aethercert AD FS target imports the certificate, can grant a configured service
identity read access to its private key, and invokes Set-AdfsSslCertificate for its
service-communications selection or Set-AdfsCertificate for token signing and token
decrypting. Microsoft distinguishes the farm's TLS/SSL binding from the service
communications certificate shown in AD FS Management, so confirm that the selected
mode matches the certificate you intend to replace. Farm mode, WAP scope, and
token-certificate rollover impact still require deliberate administrative planning.
See Deploy targets for the fields this preset takes, what it needs on the host, and how far it has been verified.