How to Replace the SSL Certificate on ADFS (Windows Server 2025)

Before touching any binding, capture everything you need to restore the current state. A wrong thumbprint or a certificate whose private key the service account cannot read will break sign-in for the entire farm, so treat this step as mandatory.

1. On the primary ADFS server, record the current SSL binding and its thumbprint:

Get-AdfsSslCertificate

Note the PortNumber and CertificateHash values from the output.

1. Export the current SSL certificate with its private key to a .pfx so you can re-import it if you need to roll back. Open mmc.exe, add the Certificates snap-in for Computer account > Local computer, then go to Certificates (Local Computer) > Personal > Certificates. Right-click the current certificate and choose All Tasks > Export, selecting Yes, export the private key and a strong password.

1. On each Web Application Proxy (WAP) server, record the current binding with Get-WebApplicationProxySslCertificate so you know exactly which certificate to restore there too.

The account exporting the private key must have permission to do so, and the certificate must have been imported as exportable. Store the .pfx and its password somewhere secure and off the server. Keep this backup until you have confirmed the new certificate works end to end.

Import the new certificate (with its private key) into the Local Machine Personal store on every ADFS and WAP server in the farm. Using the same .pfx file on all servers avoids subtle mismatches.

1. On each server, open mmc.exe and add the Certificates snap-in: File > Add/Remove Snap-in > Certificates > Add > Computer account > Local computer > Finish > OK.
2. Navigate to Certificates (Local Computer) > Personal > Certificates. Right-click in the empty pane and choose All Tasks > Import.
3. In the Certificate Import Wizard, select your .pfx/.p12 file, enter the private key password, keep the store location as Local Machine, and confirm the certificate store is Personal.
4. Verify with PowerShell that the certificate is present and carries its private key.

Replace your-domain.com with your ADFS federation service name. If HasPrivateKey is False, the .pfx was imported without its key — re-import from the original file that contains the private key. Repeat the import on every node before moving on.

The ADFS service account must have read access to the new certificate's private key, or the service cannot bind the certificate and authentication will fail.

1. In the Certificates MMC (Local Computer > Personal > Certificates), right-click the new certificate and choose All Tasks > Manage Private Keys.
2. Click Add to open the object picker.
3. If ADFS runs under a Group Managed Service Account (gMSA), click Object Types and enable Service Accounts, then enter the account name (it ends with $), for example DOMAIN\ADFS-Service$.
4. Grant Read (Full Control is optional and useful during troubleshooting), then click OK.
5. Repeat on every ADFS server. Confirm the account name with (Get-WmiObject Win32_Service -Filter "Name='adfssrv'").StartName if you are unsure which account the service uses.

Without this permission the Set-AdfsSslCertificate step may appear to succeed but the service will fail to serve the certificate after restart. For gMSA accounts you must enable the Service Accounts object type or the picker will not resolve the $-suffixed name. WAP servers do not use the ADFS service account, so this step applies to ADFS nodes only.

This step is optional but recommended for consistency — many deployments use the same certificate for both the SSL binding and service communications.

UI method: 1. Open Server Manager > Tools > AD FS Management. 2. In the left pane, expand Service > Certificates. 3. Right-click Service Communications and choose Set Service Communications Certificate, then pick the new certificate and click OK.

PowerShell method (equivalent):

Set-AdfsCertificate -CertificateType Service-Communications -Thumbprint "YOUR_CERT_THUMBPRINT"

After setting it, verify the change.

Replace YOUR_CERT_THUMBPRINT with the thumbprint captured in the next step (or copy it now). Skip this step entirely if your token-signing/service-communications lifecycle is managed separately. The SSL certificate and the Service Communications certificate can be the same certificate.

You need the exact thumbprint of the new certificate for the SSL commands. Copy it cleanly — stray spaces or hidden characters are the most common cause of Set-AdfsSslCertificate failing.

1. List certificates in the Personal store with their thumbprints and expiry:

Get-ChildItem -Path Cert:\LocalMachine\My | Select-Object Subject, Thumbprint, NotAfter | Format-Table -AutoSize

1. Capture the new certificate's thumbprint into a variable so you never have to paste it by hand. Filtering on a subject match and a future NotAfter avoids grabbing the old certificate:

$newCert = Get-ChildItem -Path Cert:\LocalMachine\My | Where-Object {$_.Subject -like "*your-domain.com*" -and $_.NotAfter -gt (Get-Date)} $thumbprint = $newCert.Thumbprint Write-Host "Certificate Thumbprint: $thumbprint"

If the filter returns more than one certificate, tighten it (for example add a NotAfter comparison or match a more specific subject) so $thumbprint is a single value and not an array. If you copy the thumbprint from the MMC Details tab instead, delete any leading invisible character and all spaces before using it.

Run the SSL update on the primary ADFS server. On Windows Server 2016 and later this cmdlet propagates the binding to every farm member automatically.

1. Set the new certificate (reuse the $thumbprint variable from the previous step, or paste the cleaned value):

Set-AdfsSslCertificate -Thumbprint $thumbprint

1. Restart the ADFS service so the new binding is loaded:

Restart-Service adfssrv

1. Confirm the service is running and the binding shows the new certificate hash.

Run this on the primary node only; running it on secondaries is unnecessary and can cause confusion. If the cmdlet errors with an invalid or empty thumbprint, re-check that $thumbprint is a single clean 40-character string. Automatic propagation applies to Server 2016+, but you still restart secondary nodes explicitly in a later step.

WAP servers do not inherit the SSL certificate from ADFS — you must update each WAP node individually after importing the new certificate there (done earlier).

1. On each WAP server, set the new binding:

Set-WebApplicationProxySslCertificate -Thumbprint "YOUR_CERT_THUMBPRINT"

1. If that command fails (for example after certificate changes on the ADFS side), reconfigure the proxy with the trust credential and the new thumbprint:

$cred = Get-Credential Install-WebApplicationProxy -FederationServiceName "adfs.yourdomain.com" -FederationServiceTrustCredential $cred -CertificateThumbprint "YOUR_CERT_THUMBPRINT"

1. Update the IIS HTTPS binding manually if needed: open IIS Manager, go to Sites > Default Web Site > Bindings, edit the https (port 443) binding, and select the new certificate.
2. Verify the WAP binding.

Replace YOUR_CERT_THUMBPRINT and adfs.yourdomain.com with your values. The Install-WebApplicationProxy credential must be an account authorized to establish the proxy trust with ADFS. Repeat for every WAP server — a missed node will serve the old (soon-to-expire) certificate to external users.

Although Set-AdfsSslCertificate propagates the configuration to farm members, restart the service on each secondary ADFS node so it actually loads the new binding.

1. On each secondary ADFS server, restart the service:

Restart-Service adfssrv

1. Wait until the service reports Running before moving on:

1. Check the AD FS admin log for certificate-related errors, and confirm each node reports the new certificate hash.

If you use Microsoft Entra Connect (formerly Azure AD Connect), it can assist with farm-wide certificate updates, but restarting the service on each node is still the reliable way to guarantee the new binding is loaded. If a node's CertificateHash still shows the old value, re-check that the certificate and its private key permissions are present on that node.

Test every path end to end before considering the change complete.

1. Open the ADFS sign-in test page in a browser and confirm there are no certificate warnings and the served certificate is the new one:

https://adfs.yourdomain.com/adfs/ls/IdpInitiatedSignOn.aspx

1. Test the metadata endpoint from PowerShell:

1. Inspect the certificate that is actually served:

1. Sign in with a real test user through a relying-party application to confirm the full authentication flow works.

Replace adfs.yourdomain.com with your federation service name. You can also run an external SSL test (for example ssllabs.com/ssltest) to confirm the served chain and rating. Keep monitoring the AD FS/Admin event log over the next 24 hours — some certificate/binding issues only surface under real authentication load. Keep your rollback .pfx until you are confident everything is stable.