You add a second website to an IIS server bound to port 443 and it will not start; the System event log says the WWW Publishing Service could not register the URL prefix. What does an IIS binding consist of, and how would you diagnose and resolve the conflict?

## What a binding is An IIS site does not "listen" on anything itself. It declares one or more bindings, and IIS translates each into a URL prefix registration with HTTP.sys, the kernel driver that actually owns the port. A binding has four parts, written in configuration as a colon-separated `bindingInformation` string of `IP:port:hostname`: ```xml <site name="Contoso" id="2"> <bindings> <binding protocol="https" bindingInformation="*:443:www.contoso.com" sslFlags="1" /> <binding protocol="http" bindingInformation="*:80:www.contoso.com" /> </bindings> </site> ``` `*` in the IP position means all addresses. An empty host name means "any host name" — the catch-all — and that is the source of a second, quieter failure mode discussed below. `sslFlags="1"` is the SNI flag. ## Why the second site will not start HTTP.sys enforces exclusivity per prefix. When W3SVC tries to register `https://*:443:` for a new site and something already owns that exact prefix, registration fails and the site stays stopped. The event log text is the generic Win32 message `0x80070020 — The process cannot access the file because it is being used by another process`, which sends people hunting for a locked file that does not exist. Three different situations produce it, and they need different fixes: 1. **Another IIS site holds the identical tuple.** Most common when both bindings were left with a blank host name. 2. **A non-IIS process owns the port.** A self-hosted service that called `HttpListener`, a Windows service, or another web server. It may hold a *urlacl* reservation even when it is not currently running. 3. **The port is held by an ordinary socket listener** that has nothing to do with HTTP.sys at all. ## Diagnosing in the right order ``` netsh http show servicestate view=requestq netsh http show urlacl netstat -ano | findstr :443 ``` The first dumps every request queue HTTP.sys knows about with the registered URLs and the owning process IDs — this is the definitive answer to "who has my prefix". The second lists standing URL ACL reservations, which persist across reboots and are how a non-IIS application claims a prefix in advance. The third catches a plain socket listener; map the PID with `tasklist /fi "pid eq <id>"`. Only after that is it worth looking at IIS Manager's binding list. ## Making the tuples distinct For HTTP the fix is usually just a host name. `*:80:www.contoso.com` and `*:80:www.fabrikam.com` coexist happily, because HTTP.sys reads the `Host` header and routes to the matching queue, preferring the most specific match: an exact host name beats a wildcard host name beats the blank catch-all. A site left with a blank host name will silently answer for every name that has no better match, which is why a newly added site sometimes "works" but serves the wrong content — no error anywhere, just the catch-all winning. For HTTPS there is a chicken-and-egg problem: the server has to present a certificate during the TLS handshake, before any HTTP request — and therefore any `Host` header — exists. That is why, historically, one IP and port could carry only one HTTPS certificate. Since IIS 8.0 you can tick **Require Server Name Indication**, which makes IIS select the certificate from the SNI value the client sends in the handshake, allowing many HTTPS sites on `*:443` with different host names. The alternatives when SNI is not viable — very old clients that send no SNI — are a dedicated IP per site, a non-standard port, one certificate covering all the names (a SAN or wildcard certificate bound once at the endpoint), or the Central Certificate Store, which selects a certificate file by requested host name from a shared folder rather than from the machine store. ## The trap that makes this feel non-deterministic Certificate bindings for HTTPS live in HTTP.sys, not only in IIS configuration, and they are keyed by IP:port (or by host:port for SNI bindings). Removing a site in IIS Manager does not always clear the underlying `sslcert` binding, so the prefix can stay claimed by a site that no longer exists. `netsh http show sslcert` shows what is actually bound, and it is the place to look when IIS Manager insists nothing is using the port. Equally, changing the certificate on one non-SNI binding changes it for every site sharing that IP and port, because there is only one certificate at that endpoint — a surprise that shows up as an unrelated site suddenly serving the wrong name.