How to Configure Wildcard or SAN SSL Certificate on IIS6 and 7.x

— ny_wk

Hosting several HTTPS sites on a single IP and port in IIS fails with a certificate mismatch unless you use a wildcard or SAN SSL certificate. This guide explains why that limitation exists and gives the exact, corrected steps to install and bind a wildcard or SAN certificate on IIS 6 and IIS 7.x using host headers.

Heads-up on versions: IIS 6 (Windows Server 2003) and IIS 7/7.5 (Windows Server 2008/2008 R2) are all past Microsoft's extended support and should not run on the public internet. The mechanics below are accurate for those legacy releases. If you are on IIS 8 or later (Windows Server 2012+), the metabase/manual-XML editing in this guide is no longer necessary because IIS natively supports Server Name Indication (SNI) in the binding dialog. Skip to the SNI section at the end for the modern equivalent.

The problem: why one IP and port allows only one HTTPS site

IIS uniquely identifies a website using three values. Understanding all three is the key to the wildcard/SAN certificate workaround.

• IP address — operates at OSI Layer 3/4.
• TCP port — operates at Layer 3/4 (default 80 for HTTP, 443 for HTTPS).
• Host header — the hostname the browser requested, carried inside the HTTP request at Layer 7.

For plain HTTP, the host header lets many sites share one IP and one port. The web server reads the requested hostname from the request and routes to the matching site:

HTTPS breaks this convenience, and the reason is a genuine chicken-and-egg ordering problem in the TLS/SSL handshake.

The SSL handshake happens before the host header is readable

A simplified TLS handshake looks like this:

1. Client → Server (handshake): "Hello, here are the cipher suites I support."
2. Server → Client (handshake): "Here is my public certificate; let's use this cipher."
3. Client → Server (handshake): key exchange completes and an encrypted channel is established.
4. Client → Server (encrypted): the actual HTTP request — and this is the first time the host header travels.
5. Server → Client (encrypted): the HTTP response.

The server must present a certificate at step 2, but the requested hostname is not known until step 4, after encryption is already negotiated. Without an extension that exposes the hostname during the handshake, the server simply hands over the certificate bound to that IP:port and hopes it matches.

Walk through a server holding three separate single-name certificates on the same 192.168.0.1:443:

• A client asking for mysite1.example.com receives that cert, encrypts with its public key, and the server decrypts with the matching private key. This site works.
• A client asking for mysite2.example.com still receives mysite1's certificate, because the server cannot yet see which host was requested. The browser either throws a name-mismatch warning or the connection negotiates against the wrong key pair, and the request fails.

The net result: only one of the three sites works under HTTPS. This is not an IIS bug — it affects Apache, Nginx, and every classic TLS stack on releases that predate SNI. That historical constraint is exactly why the wildcard or SAN SSL certificate approach exists.

The solution: one shared wildcard or SAN SSL certificate

If every host-header site on that IP:port presents the same certificate, the mismatch disappears. The server returns one cert that is valid for all the hostnames, the handshake completes, and only then does IIS read the encrypted host header and route to the correct site.

Wildcard certificate

A wildcard certificate uses a subject like *.example.com and covers any single-label subdomain of that base domain. All three sites below share one cert:

Important wildcard limits: *.example.com matches mysite1.example.com but not the bare example.com and not a deeper level like app.dev.example.com. A wildcard covers exactly one label in one position.

SAN (Subject Alternative Name) certificate

A SAN certificate, also called a UCC or multi-domain certificate, lists each exact hostname explicitly in the Subject Alternative Name field. It is the right choice when the hostnames span different domains or you want to enumerate specific names:

Modern browsers and clients rely only on the SAN field for hostname validation; the legacy Common Name (CN) is ignored. Make sure every hostname you intend to serve is present as a SAN entry, not just in the CN.

Prerequisites before you install

• Wildcard: confirm with the project owner exactly which sites will share the *.domain certificate.
• SAN: confirm which sites share the certificate and verify every required hostname is listed in the Subject Alternative Name field of the issued certificate (or in the CSR you submit to the CA).
• Renewals: before importing a renewed cert, inspect the current SSL bindings in IIS Manager and note every site that already shares the wildcard/SAN cert so none are missed.
• Private key: import the certificate with its private key (a PFX/.p12 file). A certificate without its key cannot be bound to a site.
• Trust chain: install any intermediate/CA certificates into the appropriate store so clients receive a complete chain.

Step 1: Bind the wildcard/SAN certificate in IIS Manager

This GUI step is the same idea on IIS 6 and IIS 7.x, though the dialogs differ slightly. After importing the PFX into the server's certificate store, bind it to each site.

1. Launch Internet Information Services Manager by running inetmgr.exe on the target web server.
2. Select the first site that needs the certificate (for example, your BHC site), then click Bindings… in the Actions pane on the right.
3. Highlight the https (443) binding and click Edit….
4. From the SSL certificate drop-down, choose the newly imported wildcard or SAN certificate.
5. Click OK. Caution: on IIS 7.x the host header field on an HTTPS binding may be greyed out or reset at this point — that is expected. Accept the prompts (click Yes) and continue; you will restore the host header by editing the config file in the next step.
6. Repeat for every site that should share the certificate.

At this stage every site presents the same certificate, but IIS 6/7.x will not yet route by host header over HTTPS until you add the hostname to the secure binding manually.

Step 2a: Update the metabase — IIS 6 only

On IIS 6 the secure bindings live in the metabase. You attach the FQDN to the 443 binding so the host header is honored.

1. Open Windows Explorer and go to C:\Windows\System32\Inetsrv\config. Back up MetaBase.xml first — copy it elsewhere, or use the backup feature in IIS Manager.
2. Allow the metabase to be edited while IIS runs (or stop IIS before editing): in IIS Manager, right-click the server, choose Properties, and tick Enable Direct Metabase Edit.
3. Open MetaBase.xml in Notepad and search for SecureBindings.
4. For each site, change the value from :443: to :443:<FQDN> — for example :443:mysite2.example.com — so the secure binding includes the hostname.
5. Repeat for every site that shares the certificate.
6. Save the file and run iisreset from an elevated command prompt to restart IIS.

Step 2b: Update applicationHost.config — IIS 7.x and above

On IIS 7 and later the bindings live in applicationHost.config. The HTTPS binding string has the form IP:port:hostname, and you add the hostname after the port.

1. Open Windows Explorer and go to C:\Windows\System32\Inetsrv\config. Back up applicationHost.config before changing anything.
2. Open applicationHost.config in Notepad as Administrator (the folder is protected).
3. Search for protocol="https" to find each secure binding, and locate the <binding> element for each site you need to update.
4. Edit bindingInformation so the host header follows the port. Change *:443: to *:443:<FQDN> — for example bindingInformation="*:443:mysite2.example.com".
5. Repeat for every site sharing the certificate.
6. Save the file and run iisreset from an elevated command prompt.

Note on IIS 8+ (the modern equivalent): you do not edit XML by hand. In the Edit Site Binding dialog, simply tick Require Server Name Indication and type the hostname directly. SNI sends the requested hostname during the TLS handshake (the ClientHello), so IIS can pick the right certificate per host even with different certs per site. Use SNI on any supported, in-support Windows Server; reserve the shared wildcard/SAN approach for older clients that cannot send SNI.

Common pitfalls

• Host header silently dropped. Binding the cert in the GUI resets the HTTPS host header on IIS 6/7.x. If you skip the config-file edit, all secure traffic lands on the first site. Always complete Step 2a or 2b.
• Editing applicationHost.config without elevation. Notepad will appear to save but the write fails. Launch Notepad as Administrator.
• Forgetting the private key. If the certificate does not appear in the SSL drop-down, it was imported without its key. Re-import the PFX and include the key.
• Missing intermediate chain. The site may work in one browser and fail in another. Install the CA's intermediate certificate.
• Wildcard depth mismatch. *.example.com does not cover example.com or a.b.example.com. Use a SAN cert (or add the apex as a SAN) when you need those names.
• No backup. A typo in MetaBase.xml or applicationHost.config can take down every site on the server. Back up first, every time.
• Relying on the Common Name. Current clients validate against SAN only; an old cert with the name solely in the CN will be rejected.

Verification: confirm every HTTPS site works

1. From a client machine (not the server, to avoid loopback quirks), browse to each https://hostname and confirm the page loads with a padlock and no certificate warning.
2. Click the padlock and verify the served certificate is the shared wildcard/SAN cert and that the requested hostname is covered by the subject or a SAN entry.
3. From the command line, inspect the live certificate and SAN list:
   openssl s_client -connect mysite2.example.com:443 -servername mysite2.example.com
   or on Windows PowerShell against each name to confirm a successful TLS connection.
4. Confirm the secure bindings include the hostnames: run netsh http show sslcert and review the IP:port-to-cert mapping, and check appcmd list sites (IIS 7+) for the expected https/*:443:hostname bindings.
5. Review the IIS logs and the Event Viewer System/Application logs after iisreset to ensure no binding or certificate errors were recorded.

Key Takeaways

• Classic SSL/TLS exposes the host header only after the handshake, so one IP:port can normally serve only one HTTPS site — this affects every legacy web server, not just IIS.
• A wildcard or SAN SSL certificate shared by all host-header sites removes the mismatch because every site presents the same valid certificate.
• On IIS 6 edit SecureBindings in MetaBase.xml; on IIS 7.x add the FQDN after :443: in applicationHost.config, then run iisreset.
• Always back up the metabase/config, import the cert with its private key, and validate against the SAN field, not the Common Name.
• On IIS 8+ use built-in SNI instead of manual XML edits — and never run EOL IIS 6/7.x on the public internet.

Frequently Asked Questions

What is the difference between a wildcard and a SAN certificate?

A wildcard certificate (*.example.com) secures unlimited single-label subdomains of one base domain. A SAN certificate lists specific, explicit hostnames in its Subject Alternative Name field and can span multiple different domains. Choose wildcard for many subdomains of one domain, and SAN when you need exact or cross-domain names.

Why can't I host multiple HTTPS sites on one IP without it?

On servers that predate SNI, the certificate is sent during the TLS handshake before the requested hostname is known, so the server always returns the cert bound to that IP:port. A second hostname gets the wrong certificate and fails. A shared wildcard/SAN cert (or SNI on modern IIS) solves this.

Does IIS still need manual config edits for this today?

No. From IIS 8 (Windows Server 2012) onward, you tick Require Server Name Indication and enter the hostname directly in the binding dialog, with no metabase or applicationHost.config editing. Manual edits are only relevant to the legacy IIS 6 and 7.x releases covered here.

Where is the SSL binding actually stored in IIS?

IIS 6 keeps secure bindings in MetaBase.xml; IIS 7.x and later keep them in applicationHost.config under each site's <bindings>. The certificate-to-port mapping itself is held by HTTP.sys and can be inspected with netsh http show sslcert.

For more Windows Server and IIS walkthroughs, subscribe on YouTube @explorenystream.