IIS, SNI, and Multi-SAN Certificates: Where ADCS Auto-Enrollment Runs Out of Runway

Search for "ADCS auto-renew IIS SNI" and you will find versions of the same question appearing across Microsoft Q&A, Spiceworks, and Reddit threads going back years. The phrasing varies. The underlying situation is always the same: an administrator has ADCS auto-enrollment working well for domain-joined machines, wants to apply the same automation to IIS websites — particularly those using Server Name Indication — and has discovered that the path from "this works for workstations" to "this works for web servers" is neither direct nor native.

The short answer buried in those threads is that you can't, not natively. And the reason is architectural, not a configuration mistake.

Why Web Server Certificate Renewal is Different from Machine Certificate Renewal

Windows auto-enrollment handles machine and user certificates. It operates through the Certificate Services client, picks up Group Policy, and interacts with the certificate stores that Windows manages for domain-joined objects. It is built for Active Directory domain members, and it does that job well.

An IIS website certificate is different in two important ways.

First, it lives in the machine's personal certificate store but is bound to a specific website configuration. IIS needs to know not just that the certificate exists, but which site it belongs to — and in SNI configurations, which hostname it serves. Renewal of the underlying certificate does not automatically update that binding. What happens in practice is this: auto-enrollment renews the certificate, the CA issues a new one, the old certificate is replaced in the store — but the IIS binding continues to reference the old certificate thumbprint until something updates it. The site continues to serve the old, now-expired certificate until an administrator notices, or until users start seeing browser SSL warnings.

Second, when a single server hosts multiple sites using SNI — each presenting its own certificate based on the requested hostname — you have multiple certificates to manage, each tied to a different FQDN, each needing renewal on its own schedule, and each requiring its own binding update when renewal occurs. Auto-enrollment has no concept of this relationship. It renews certificates; it does not know about hostnames, bindings, or which renewed certificate belongs to which site.

The Microsoft documentation acknowledges this behaviour. The community solutions range from PowerShell scripts that detect recently renewed certificates and update IIS bindings automatically, to scheduled tasks that run certreq and then call the IIS administration API, to third-party tools built specifically to fill this gap.

The Binding Drift Problem

Binding drift is the operational name for what happens when certificate renewal and binding updates become decoupled — which is the default state when auto-enrollment handles the renewal but nothing handles the binding.

The failure mode is asymmetric. The CA renews the certificate on schedule. The machine's certificate store is updated correctly. From the perspective of ADCS and the Group Policy enrollment client, everything has worked as designed. The site, however, is still presenting the previous certificate — the one whose thumbprint was recorded in the IIS binding configuration — until an administrator runs a manual check or a monitoring alert fires. In environments where IIS server monitoring focuses on service availability rather than certificate validity, that alert may not fire until the certificate has already expired and users are reporting errors.

For a server hosting a single intranet site, this is an inconvenience. For a server hosting a customer-facing application under an SLA, it is an outage. For a server hosting thirty SNI-bound sites with thirty independent renewal cycles, it is a recurring source of unplanned work.

The Multi-SAN Certificate Question

A related challenge arises when organisations want to consolidate web server certificates — issuing a single certificate with multiple Subject Alternative Names covering several hostnames, rather than one certificate per site. The motivation is understandable: fewer certificates to track, simpler renewal cycles, and less exposure to missing an individual expiry.

ADCS can issue multi-SAN certificates, but the request process is more involved than standard machine enrollment. Web server templates in ADCS are typically configured to populate the subject from the request, which means the requester has to supply the SANs explicitly. In an automated enrollment scenario, this requires either a custom template configured to allow SAN override — which carries its own policy and governance implications — or an external process that constructs the CSR with the correct SAN list before submitting it to the CA.

What you end up with, in practice, is a script: something that knows which hostnames a given server or load balancer needs to cover, constructs a CSR with the appropriate SAN list, submits it to ADCS, receives the signed certificate, and handles the binding update. It works. It works reliably when it is well-maintained. The operational risk is the same as any business-critical script: if the IIS configuration changes in a way the script didn't anticipate, or if the person who wrote it is no longer available, the next renewal cycle may fail silently — and binding drift picks up where it left off.

Load Balancers, Reverse Proxies, and the Edge of the Windows World

The IIS problem is a subset of a broader challenge that becomes visible once organisations have been running ADCS as their internal root of trust for long enough to accumulate infrastructure around it. Organisations that use ADCS to secure internal systems increasingly want to use that same trusted CA to secure everything that terminates TLS: not just IIS, but F5 load balancers, NGINX reverse proxies, HAProxy instances, and API gateways sitting in front of internal services. These systems need certificates. Some of them have built-in SCEP support. Some can be integrated with ACME clients. None of them participate in Windows auto-enrollment, and none of them have a native mechanism for picking up a renewed certificate and applying it to the right listener or virtual server.

The result is an extension of the same pattern: a separate enrollment process for each device type, often written and maintained by different people, each with its own credential management, its own renewal logic, and its own potential to go quietly wrong.

What This Looks Like When It's Running in Production

An IT Operations Manager we spoke with described the state of their web server certificate estate after several years of growth: "Auto-enrollment handles the machine certificates, mostly. IIS certificates get renewed by a PowerShell script one of my team wrote three years ago. We've patched it twice when IIS changes broke it. The load balancers have a separate SCEP configuration set up by a contractor who hasn't worked here since 2022. When something expires unexpectedly, we usually find out from a user, not from a monitoring alert."

That is not an unusual description. It is what certificate management looks like at the edge of the auto-enrollment model: the native tooling handles what it was designed for, and a collection of scripts and manual processes handles the rest. Each piece was the right decision when it was made. The problem is the gap between them — and the absence of any unified view that covers IIS bindings, multi-SAN renewals, load balancer certificates, and Windows auto-enrollment in the same place.

The risks that surface reliably in this configuration:

   
• Binding drift. Auto-enrollment renews the certificate, but the IIS binding continues to reference the old thumbprint. Sites serve expired certificates until someone notices — usually not through a proactive alert.
   
• Silent renewal failures at the boundary. Scripts that handle IIS binding updates or load balancer certificate deployments fail without announcing themselves. The next indication is an expiry event.
   
• SAN list maintenance. Multi-SAN certificates require someone to maintain the list of hostnames each certificate covers. As infrastructure changes, that list drifts from the actual configuration — certificates cover hostnames that no longer exist, and miss hostnames that do.
   
• Script fragility. The IIS renewal script, the load balancer SCEP configuration, the binding update task — each is a dependency on whoever wrote it. When the person leaves or the underlying system changes, the dependency doesn't announce itself until something expires.
   
• No unified view. IIS certificates, load balancer certificates, and machine certificates issued through auto-enrollment are three separate pools of information, in three separate places, with no native mechanism for seeing all of them together.

Where This Leaves You

If your web server certificate management relies on a mix of auto-enrollment, binding update scripts, and per-device SCEP configurations, you have built a rational system from the tools that were available to you. The question worth asking is not whether the individual pieces work — they probably do, most of the time. It is whether you have visibility across all of them simultaneously, whether a binding drift failure will be caught before users see it, and whether the scripts handling your IIS renewals and load balancer deployments would survive the departure of whoever wrote them.

This is the gap that CEMA Certificate Lifecycle Management is built to close: a governed lifecycle and enrollment layer that handles certificate deployment and binding updates for IIS and other web servers, supports multi-SAN certificate issuance through standard workflows rather than bespoke scripts, and provides a unified view of certificate state across auto-enrollment, web server bindings, and network appliances — maintained, supported, and accountable in a way that a collection of PowerShell scripts was never designed to be.

‍