Automated SSL certificate renewal for AD FS

AD FS binds its SSL certificate in two places. CertKit updates both.

An AD FS server pins its certificate twice: the SSL certificate on the HTTPS binding and the service communications certificate in the federation service configuration, both by thumbprint. When the certificate renews, neither updates until someone sets both and restarts the service, on every node in the farm. Every 47 days. And when it expires instead, every federated sign-in, Microsoft 365 included, fails at once.

CertKit centralizes certificate issuance and renewal, then pushes the renewed certificate to your AD FS servers via the CertKit Agent, sets both bindings, and restarts the service in a window you choose.

Start free trial Watch demo

Built for AD FS

The pre-built AD FS deployment template ships in your CertKit account. No scripting required.

The CertKit Agent imports the renewed PFX, runs Set-AdfsSslCertificate and Set-AdfsCertificate for the service communications certificate, and restarts the AD FS service so sign-ins resume on the current certificate. Both bindings, one deployment, no thumbprint copying between consoles.

The pre-built AD FS template ships with your CertKit account. Run the agent on each farm node and every node stays current. CertKit handles every renewal after that.

How to update the AD FS SSL certificate

The manual process, if you want to do it yourself:

Get a certificate for the federation service name. The name in your sign-in URL, like sts.yourdomain.com. A wildcard certificate is common here because it also covers enterpriseregistration and friends.
Import the PFX into the computer store. Local Machine → Personal on every node in the farm, and grant the AD FS service account read access to the private key.
Set the SSL certificate. Set-AdfsSslCertificate -Thumbprint with the new thumbprint updates the HTTPS bindings.
Set the service communications certificate too. Set-AdfsCertificate -CertificateType Service-Communications with the same thumbprint. This is the one renewals forget, and it fails separately.
Restart and verify. Restart the AD FS service, test a federated sign-in, and repeat on every node in the farm before the old certificate expires.

Every one of these steps is manual, and AD FS won't repeat any of them for you when the certificate renews. With lifetimes shrinking to 47 days, the update stops being an annual chore and becomes a recurring task: eight times a year, twice per node, on every node. Miss it and nobody logs in to anything federated.

At 47 days, automation is the only sustainable way to run AD FS certificates. Here's how CertKit does it.

How it works

 Your AD FS server         CertKit                 ACME CA
┌───────────────────┐     ┌──────────────────┐    ┌─────────────┐
│                   │     │                  │    │             │
│     ┌───────────────┐   │  Issue & Renew   │◄──►│             │
│     │ CertKit Agent │◄──┤   Certificates   │    │             │
│     └─────────┬─┬───┘   │                ┌───┐  └─────────────┘
│               │ │ │     └───────────┬────│DNS│
│ Cert store  ◄─┘ │ │                 │    └───┘
│ [x] Updated     │ │                 │
│                 │ │                 │
│ SSL + SvcComm ◄─┘ │ ◄───────────────┘
│ [x] Rebound       │       Verify
└───────────────────┘

CertKit manages issuance and renewal centrally using delegated DNS validation. You create a one-time CNAME record and CertKit handles every ACME challenge after that. Your AD FS servers never run an ACME client and never hold DNS credentials. The agent imports the certificate and sets both bindings locally.

CertKit is an invaluable tool for administrators managing public TLS certificates in Microsoft environments like Always On VPN (SSTP) and DirectAccess (IP-HTTPS), as it simplifies and fully automates Let's Encrypt certificate issuance and renewal. CertKit eliminates the security risks and complexities of manual DNS challenges or API key exposure.

Richard Hicks, Consultant and Microsoft MVP

This is the SSL certificate, not token signing

AD FS holds three kinds of certificates. The token signing and token decrypting certificates are self-signed, internal, and roll over automatically each year unless you've disabled it. The SSL and service communications certificate is different: it comes from a public CA, browsers and federation partners validate it, and nothing renews it for you. This page, and CertKit, are about that one.

What CertKit handles

Issue certificates via ACME, centrally. A publicly trusted certificate for the federation service name. Your AD FS servers have no ACME configuration, no open ports, no credentials to manage.
Renew automatically before expiry. That one-time CNAME covers every renewal challenge going forward. No intervention required on any node.
Import the PFX into the Windows Certificate Store. The CertKit Agent imports the renewed certificate with its private key on every renewal.
Set both certificate bindings in one pass. The agent runs Set-AdfsSslCertificate and Set-AdfsCertificate for service communications, so neither binding is left pointing at the old thumbprint.
Restart the AD FS service. The bindings take effect on restart, and sign-ins resume on the renewed certificate.
Cover every farm node with the same template. Run the agent on each node and each one imports, rebinds, and restarts on the same renewal. No node left on the old certificate.
Deploy in a window you control. The service restart briefly interrupts sign-ins, so it shouldn't fire mid-workday. Schedule a deployment window per server and CertKit applies the change at 2am Sunday instead of whenever the certificate renews.
Verify the deployment, not just the script. After each renewal, CertKit connects to the federation endpoint and confirms the new certificate is actually being served. It checks the serial number, SANs, and expiry. If something is wrong, you find out before your users do.
Alert on failure. Import failures, binding errors, restart failures, verification mismatches, and upcoming expirations all generate alerts before they become incidents.
Audit every change. Every issuance, renewal, and deployment is logged with timestamp, certificate, and server. With certificate lifetimes heading to 47 days, that log is your compliance record.

Setup takes about ten minutes

Connect your domain. Add a one-time CNAME record to delegate DNS validation to CertKit. Every renewal challenge after that is automatic.
Install the CertKit Agent on each AD FS node. One command on each server in the farm. The agent runs as a Windows service and needs no inbound firewall rules.
Add the AD FS deployment script. The pre-built template is in your account. Confirm the AD FS service account can read the certificate's private key, and CertKit sets both bindings and restarts the service on every renewal.

See the full architecture →

Why importing the certificate isn't enough

AD FS doesn't watch the certificate store. Both bindings pin the old thumbprint until they're explicitly set, and because there are two of them, the common failure is updating the SSL binding and leaving service communications behind, which breaks in ways that don't show up until a partner federation call fails. Farm drift is the other trap: one node updated, three nodes stale, and the failure appears only when the load balancer lands a request on the wrong one.

CertKit issues the certificate via delegated DNS validation, then the agent on each node handles the import, both bindings, and the restart as one verified step, with no ACME client on the server and no thumbprint copying between consoles.

AD FS is just one part of your Windows stack

Most Windows environments have more than one place where certificates live: IIS, Exchange, Network Policy Server, and Remote Desktop. CertKit automates all of it from one account.

See all integrations

Start automating AD FS certificates today

Free 90-day trial. No credit card required. Direct access to our engineering team to get you set up.

Start free trial See pricing