Certificate Renewal Automation for IIS, Exchange, RDS and AD FS

Public TLS certificates are about to get much shorter, and every Windows server that terminates TLS will feel it: IIS sites, Exchange, Remote Desktop Gateway and Web Access, AD FS and Web Application Proxy, and the load balancers in front of them. A calendar reminder that worked for a once-a-year renewal does not work when the certificate lasts weeks. This certificate renewal automation guide says what changes and when, which platforms can renew themselves, what to script by hand, and which renewals quietly break services.

Verdict

Verdict: Automate before the March 2027 step.

The first reduction already applies to certificates issued from 15 March 2026. The next, on 15 March 2027, halves the maximum again. Anything still renewed by hand needs an owner, a script or a managed service before then.

Not every certificate is covered. The schedule applies to publicly trusted TLS certificates, not to private or internal certificates, so a certificate from your own certification authority is outside it. Most of the outage risk still sits in the public ones: the names customers and Microsoft 365 reach from the internet.

What changes and when

CA/Browser Forum ballot SC081v3 introduced a schedule of reducing validity and data reuse periods. This is the validity schedule for publicly trusted TLS Subscriber Certificates, in the same words our certificate expiry planner uses:

The requirements measure a day as 86,400 seconds and say certificates should not normally be issued for the full maximum period, so plan against the shorter figure. The table is keyed to the issue date of each certificate.

The same ballot shortens how long a CA may reuse validation evidence. The Baseline Requirements summary table lists the domain name and IP address validation reuse period as 200 days from 15 March 2026, 100 days from 15 March 2027 and 10 days from 15 March 2029, with subject identity reuse at 398 days from 15 March 2026. In practice this means a one-off, manual domain validation will not carry a renewal for long, so renewals need a validation method that a script can repeat, usually DNS.

Per-platform view

Steps, with commands

1. Inventory every certificate and where it is bound. On each server list the machine store and bindings:

Get-ChildItem Cert:\LocalMachine\My | Sort-Object NotAfter | Format-Table Subject, NotAfter, Thumbprint then Get-WebBinding -Protocol https for IIS, Get-ExchangeCertificate | Format-List Subject, Thumbprint, Services, NotAfter on Exchange, and Get-AdfsProperties and Get-AdfsCertificate on AD FS. Record which certificates come from a public CA and which from an internal one.

1. Project the dates. Enter an issue date in the certificate expiry planner to see the renewal calendar under each step of the schedule, and export reminders as a local .ics file.
2. Choose a validation method you can script. The Posh-ACME documentation says the default Manual DNS plugin needs you to create TXT records yourself, which is not automation. Pick a DNS plugin for your provider or an HTTP challenge. Posh-ACME also says DNS validation is the only one that can request a wildcard certificate.
3. Install an ACME client where it fits. For IIS, run wacs.exe as administrator and follow the prompts to create the first certificate; win-acme creates a scheduled task to renew it and reapplies your choices at each renewal. For Posh-ACME, request and install with an elevated session:

New-PACertificate 'www.example.com' -AcceptTOS -Contact 'admin@example.com' -Plugin <your-dns-plugin> -PluginArgs $pArgs -Install Then schedule Submit-Renewal -AllOrders with Task Scheduler; the documentation suggests running it once or twice a day at randomized times, as the same user who created the order.

1. Exchange: renew, import, enable. Create the request in the EAC (Servers, Certificates, Renew) or with New-ExchangeCertificate, complete it with Import-ExchangeCertificate, then assign services:

Enable-ExchangeCertificate -Thumbprint <thumbprint> -Services IIS,SMTP The cmdlet is Enable-ExchangeCertificate; there is no Set-ExchangeCertificate in Microsoft's cmdlet reference. Service assignments are additive, and Microsoft recommends restarting IIS in environments that use layer 4 load balancing.

1. RDS: set each role. Import the PFX and apply it to every role that uses it:

Set-RDCertificate -Role RDGateway -ImportPath C:\certs\rdgw.pfx -Password $pfxPassword -ConnectionBroker rdcb.contoso.com -Force Repeat for RDWebAccess, RDPublishing and RDRedirector. The -Thumbprint parameter is available on Windows Server 2019 and later, so a Windows Server 2016 deployment uses the PFX path.

1. AD FS: SSL certificate and token certificates are different jobs. On the primary run Set-AdfsSslCertificate -Thumbprint '<thumbprint>', which updates every node over PowerShell remoting on TCP 5985. On each Web Application Proxy run Set-WebApplicationProxySslCertificate -Thumbprint '<thumbprint>'. Separately, check Get-AdfsProperties for AutoCertificateRollover, CertificateGenerationThreshold and CertificatePromotionThreshold.
2. Load balancers: use the platform's own store. For Application Gateway v2, store the certificate in Key Vault and reference the secret without a version so the gateway picks up renewed versions on its own.
3. Verify from outside. After each renewal check what clients see, for example openssl s_client -connect www.example.com:443 -servername www.example.com, and compare the thumbprint and expiry with the inventory.
4. Alert on failure, not only on expiry. A renewal job that fails silently looks fine until the certificate expires. Alert when the scheduled task fails and when any certificate is inside your planning window.

Platform notes that decide the design

IIS. win-acme's README describes an ACMEv2 client for Windows with a simple interface for IIS and an advanced one for other uses, and says it is maintained by ZeroSSL. Posh-ACME needs Windows PowerShell 5.1 with .NET Framework 4.7.1 or later, or PowerShell 6.2 or later.

Exchange. Exchange needs the certificate enabled per service, and a certificate that is imported but not enabled changes nothing. Microsoft's certificate guidance recommends the Exchange certificate wizard in the EAC so that required names are not forgotten, and suggests few certificates and few host names. I found no Microsoft page that documents ACME for Exchange; the win-acme README says its advanced interface covers Exchange, so treat that as a third-party option to test, not a supported path.

RDS. Microsoft states that the certificate name must match the FQDN clients use to reach RD Gateway or RD Web Access, and that a released service needs a certificate from a trusted certification authority. Broker certificates must match on server and client for single sign-on.

AD FS. By default AD FS generates token-signing and token-decrypting certificates automatically, and with AutoCertificateRollover set to True you must still make sure every federation partner picks up the new certificate. Microsoft says to plan that at least 60 days ahead. These are self-signed by default and are not public TLS certificates, so the schedule above does not govern them. Microsoft also notes the recommended way to replace the AD FS TLS/SSL certificate going forward is Microsoft Entra Connect.

Azure. Key Vault handles end-to-end renewal for certificates from the integrated CAs DigiCert and GlobalSign. For other CAs it can only send near-expiry email notifications, and you create a new version and merge the signed request yourself. Each renewal creates a new secret version.

Outage mistakes

• Renewing the certificate but not the binding. The new certificate sits in the store while IIS, Exchange or the gateway keeps serving the old one.
• Forgetting a role. RDS uses separate certificates per role; updating RD Web Access alone leaves RD Gateway to expire.
• Wrong cmdlet or wrong service list. On Exchange, a certificate not enabled for the services you use is ignored.
• Manual DNS validation in an automated job. The job waits for a TXT record nobody creates.
• Task runs as the wrong user. Posh-ACME keeps its configuration in the profile of the account that created it.
• Pinned thumbprints. Scripts, load balancer rules and application configs that name a thumbprint break at every renewal.
• Not telling federation partners. Relying parties that cannot read your federation metadata need the new public key sent to them.
• Replacing the private key without a plan. Generating a new key on each renewal is fine, but a CSR made on one server and a certificate installed on another will not match; see our CSR and encrypted private key generator for how request and key pair up.
• Treating Windows Server 2016 as out of scope. The same servers reach end of support in January 2027; see the Windows Server 2016 end-of-support guide before building automation on a host you are about to replace.

Checklist

• Every public TLS certificate listed with owner, server, binding and expiry
• Public and internal certificates marked separately
• Renewal calendar projected for the 2026, 2027 and 2029 steps
• Validation method that runs unattended, with credentials kept out of scripts
• Scheduled renewal task or managed service in place for each platform
• Binding, service assignment or listener updated automatically after renewal
• Federation partners and Microsoft Entra updated for AD FS token certificate changes
• Alert on renewal failure and on any certificate inside its planning window
• Renewal tested on a non-production name first
• Old thumbprints removed from scripts and load balancer rules

Related tools and reading

Use the certificate expiry planner to build the renewal calendar, the CSR and encrypted private key generator when a CA still needs a manual request, and the Windows Server 2016 end-of-support guide for the hosts these certificates sit on.

Sources

Checked 6 November 2026.

• CA/Browser Forum Ballot SC081v3
• CA/Browser Forum TLS Baseline Requirements (summary table, sections 4.2.1 and 6.3.2)
• Certificate procedures in Exchange Server
• Digital certificates and encryption in Exchange Server
• Enable-ExchangeCertificate
• Set-RDCertificate
• Remote Desktop Services roles
• Manage TLS/SSL certificates in AD FS and WAP
• Obtain and configure token signing and token decryption certificates for AD FS
• TLS termination with Azure Key Vault certificates
• About Azure Key Vault certificate renewal
• Get-WebBinding
• win-acme on GitHub and win-acme manual
• Posh-ACME documentation and Posh-ACME tutorial