aethercert
Documentation

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

  1. 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
  2. Identify the farm's binding mode before choosing a cmdlet. Inspect current AD FS bindings and whether a certauth hostname is configured:

    Get-AdfsSslCertificate
    Get-AdfsProperties | Format-List HostName,CertificateAuthenticationBinding
  3. On a Windows Server 2016-or-newer primary federation server at 2016 farm behavior level, update default binding mode once:

    Set-AdfsSslCertificate -Thumbprint $thumbprint

    This 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-AdfsSslCertificate on each federation server instead.

  4. If the farm uses alternate TLS client binding mode, use the corresponding farm cmdlet rather than the default-mode command:

    Set-AdfsAlternateTlsClientBinding -Thumbprint $thumbprint
  5. On each WAP server, run:

    Set-WebApplicationProxySslCertificate -Thumbprint $thumbprint

    If an already expired trust prevents this, Microsoft documents rebuilding the WAP trust with Install-WebApplicationProxy and the federation service name.

  6. Verify private-key access. On Server 2016+ the AD FS TLS cmdlets grant the adfssrv service 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,State

    In 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.

  7. 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 adfssrv

    Drain 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-AdfsSslCertificate

Older 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 adfssrv

From 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.xml

Test 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 certauth name 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 netsh binding 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.

Sources

On this page