- 12 minutes to read

IIS Binding and SAN Monitoring

Comprehensive monitoring of IIS HTTPS bindings and Subject Alternative Names (SANs) to detect orphaned bindings, hostname mismatches, wildcard certificates, and multi-level wildcard security risks.

:new: Introduced IIS certificate binding monitoring with wildcard support and SAN parsing, including multi-level wildcard detection.

For configuration options, see Certificate Configuration - IIS Binding & SAN Monitoring.

The Problem: When IIS Bindings and Certificates Go Out of Sync

Scenario: E-Commerce Site Outage After Certificate Renewal

A financial services company renewed their wildcard SSL certificate for *.payments.example.com covering their payment gateway. The new certificate was successfully installed in the Windows certificate store and validated. However, the IIS binding for the main payment site (secure.payments.example.com:443) was not updated to reference the new certificate thumbprint.

Monday 9:00 AM - Production Outage:

Old certificate expires at midnight Sunday
IIS binding still references expired certificate thumbprint
All payment transactions fail with SSL/TLS handshake errors
Customers cannot complete purchases or access account information
Call center flooded with complaints

Business Impact:

$420,000 in lost revenue (4.5 hours × $93K/hour average transaction volume)
1,200+ failed payment attempts during outage window
67 customer escalations to executive support
PCI DSS compliance violation triggered due to expired certificate in production
Regulatory reporting required to payment card processors

Root Cause: Certificate was renewed in certificate store, but IIS binding was not updated to point to new certificate. IIS continued serving expired certificate, causing complete service outage. Orphaned binding detection would have prevented this by alerting that binding referenced a certificate nearing expiration while a newer valid certificate existed.

Additional Common Scenarios:

Orphaned Bindings: Certificate deleted from store during cleanup, but IIS binding still references the deleted thumbprint (binding breaks silently until next IIS restart)
Hostname Mismatches: Wrong certificate assigned to binding (e.g., api.example.com binding uses certificate for www.example.com - works initially but triggers browser warnings)
Multi-Level Wildcard Security Risk: Using *.*.example.com certificates that violate CA/Browser Forum requirements and will be rejected during next renewal
Excessive SANs: Certificate with 150+ SAN entries causing TLS handshake performance degradation and management complexity

Monitoring States Summary

Comprehensive testing scenarios covering all IIS binding and SAN monitoring states:

#	Test Scenario	Detection Type	State	Test Script
1	Healthy Binding - Exact Match	Certificate matches hostname exactly	✅ OK	Test
2	Healthy Binding - Wildcard Match	Wildcard certificate covers subdomain	✅ OK	Test
3	Orphaned Binding	Certificate deleted but binding remains	❌ ERROR	Test
4	Hostname Mismatch	Certificate doesn't match binding hostname	⚠️ WARNING	Test
5	Expiring Certificate	Certificate within warning threshold	⚠️ WARNING	Test
6	Multi-Level Wildcard	`..example.com` security risk	⚠️ WARNING	Test
7	Excessive SANs	Certificate with 100+ SAN entries	⚠️ WARNING	Test
8	SNI Enabled Binding	Multiple certificates on same IP	✅ OK	Test

Testing Guide: See FAQ: IIS Binding and SAN Monitoring for comprehensive PowerShell test scenarios for all states.

Overview

IIS Binding and SAN monitoring provides four critical capabilities:

IIS Binding Health: Monitors HTTPS bindings for hostname mismatches, orphaned bindings, and expiration
Subject Alternative Name (SAN) Display: Parses and displays all SAN entries as badges for easy identification
Wildcard Certificate Detection: Identifies single-level and multi-level wildcard certificates
Excessive SAN Monitoring: Optional alerts for certificates with unusually high SAN counts

IIS Certificate Bindings

For the certificate category IIS Certificate Bindings, resources are named %Binding-Hostname% - IIS Site: %Site% representing HTTPS bindings in Internet Information Services.

IIS Binding States

A binding resource can have one of the following states:

State	Status	Description	Actions
Unavailable	Service not available	Server unreachable due to network or security issues Bad configuration (invalid/non-existing source/provider) IIS not installed or not accessible	Review Prerequisites
Error	Error state raised	Certificate assigned to binding is invalid, expired, or not found Binding hostname does not match certificate subject or SANs (hostname mismatch) Certificate deleted from store but binding still references it (orphaned binding) Binding certificate has expired	Manage Details
Warning	Warning state raised	Certificate in binding is about to expire (within warning threshold) Binding uses older certificate and newer version available for same hostname Certificate chain has validation issues affecting the binding	Manage Details
OK	Online	Binding is valid with current, non-expiring certificate Certificate subject or SANs match binding hostname (or wildcard match) Certificate is properly installed and accessible	Manage Details

IIS Binding State Examples

OK State - Exact Match

IIS Site: WebServer | Hostname: www.example.com | Port: 443
Certificate Subject: www.example.com
Expiration: 2025-12-20 (31 days remaining)
Match: ✅ Exact Match
SNI: Enabled
State: ✅ OK

OK State - Wildcard Match

IIS Site: WebServer | Hostname: api.example.com | Port: 443
Certificate Subject: *.example.com
Expiration: 2025-12-20 (31 days remaining)
Match: ✅ Wildcard Match
SNI: Enabled
State: ✅ OK

WARNING State - Expiring Certificate

IIS Site: WebServer | Hostname: www.example.com | Port: 443
Certificate Subject: www.example.com
Expiration: 2025-11-15 (17 days remaining, warning threshold: 30 days)
Match: ✅ Exact Match
SNI: Enabled
State: ⚠️ WARNING (Renew certificate)

ERROR State - Hostname Mismatch

IIS Site: APIServer | Hostname: api.example.com | Port: 443
Certificate Subject: www.example.com
Expiration: 2025-12-20 (31 days remaining)
Match: ❌ Mismatch
SNI: Enabled
State: ❌ ERROR (Certificate does not match binding hostname)

ERROR State - Orphaned Binding

IIS Site: LegacyApp | Hostname: old.example.com | Port: 443
Certificate Subject: [Certificate Not Found]
Certificate Thumbprint: 1A2B3C4D5E6F7G8H9I0J...
Match: ❌ Not Found
SNI: Unknown
State: ❌ ERROR (Certificate no longer exists in certificate store)

ERROR State - Expired Certificate

IIS Site: WebServer | Hostname: www.example.com | Port: 443
Certificate Subject: www.example.com
Expiration: 2025-09-15 (Expired 45 days ago)
Match: ✅ Exact Match
SNI: Enabled
State: ❌ ERROR (Certificate has expired)

IIS Binding Monitoring Features

IIS Certificate Binding monitoring provides the following capabilities:

Opt-In Configuration: Disabled by default via MonitorIISCertificateBindings setting - no impact if not enabled
Graceful Degradation: Binding data shown only when IIS is available; empty results with no errors if IIS is not installed
Wildcard Support: Correctly matches binding hostnames against wildcard certificates (e.g., *.example.com matches api.example.com)
SNI Detection: Identifies Server Name Indication (SNI) enabled bindings for multi-certificate configurations
Hostname Mismatch Detection: Alerts when binding hostname does not match certificate subject or alternate names
Single Category Integration: IIS binding resources integrated into existing certificate monitoring workflow without creating separate categories

Subject Alternative Names (SAN) Display

All certificates display their Subject Alternative Names in the Details view with comprehensive parsing:

SAN Display Features

SAN Count: Total number of SAN entries displayed prominently at the top
SAN List: All SANs shown as color-coded badges for easy scanning and identification
Wildcard Detection: Wildcard SANs automatically highlighted with appropriate icons
Excessive SAN Warning: Optional alert when SAN count exceeds configured threshold (default: 100)

Example SAN Display

Subject Alternative Names (8)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[www.example.com] [api.example.com] [mail.example.com] [*.example.com]
[app.example.com] [portal.example.com] [admin.example.com] [dev.example.com]

✅ Wildcard certificate detected: *.example.com (single-level, secure)

Wildcard Certificate Detection

Certificates containing wildcard domains are automatically identified and classified by security risk level:

Single-Level Wildcard (✅ Recommended)

Pattern: *.example.com

Matches:

✅ www.example.com
✅ api.example.com
✅ mail.example.com

Does NOT Match:

❌ example.com (base domain - wildcard does not cover apex domain)
❌ app.dev.example.com (multi-level subdomain - wildcard covers one level only)

Security Assessment: ✅ OK (industry standard best practice)

Use Cases:

Single organization with multiple subdomains
Standard HTTPS deployment for web applications
Cost-effective alternative to multiple single-domain certificates

Multi-Level Wildcard (⚠️ Security Risk)

Pattern: *.*.example.com

Matches:

⚠️ anything.anythingelse.example.com (overly permissive)
⚠️ api.dev.example.com
⚠️ www.staging.example.com
⚠️ app.test.example.com

Security Concerns:

❌ Most certificate authorities refuse to issue multi-level wildcards (violates CA/Browser Forum Baseline Requirements)
❌ Overly permissive scope creates security audit violations
❌ Modern browsers may reject or show warnings for multi-level wildcards
❌ Creates ambiguous certificate selection scenarios in multi-certificate environments
❌ Difficult to revoke without affecting many services

Security Assessment: ⚠️ WARNING (security/best practice violation)

Alert Message:

⚠️ WARNING: Multi-level wildcard detected (*.*.example.com)

Security Risk: Multi-level wildcards are overly permissive and violate industry best practices.

Recommended Actions:
1. Replace with single-level wildcard (*.example.com) for first-level subdomains
2. Use specific SAN entries for known multi-level subdomains (e.g., api.dev.example.com)
3. Consider separate certificates for different environments (dev, staging, prod)

Impact: Certificate authorities may refuse issuance during next renewal

Wildcard Best Practices

Use Single-Level Wildcards Only: *.example.com is industry standard and universally accepted
Combine with Specific SANs: Include apex domain example.com as SAN entry alongside *.example.com
Separate Environments: Use different certificates for dev/staging/production environments
Monitor Expiration: Wildcard certificates often cover many services - plan renewals carefully
Document Usage: Maintain inventory of services using wildcard certificates for renewal planning

Excessive SAN Monitoring

Certificates with unusually high SAN counts trigger optional warnings to identify potential configuration issues:

Configuration

Setting	Default	Description
AlertOnExcessiveSANs	`false`	Enable/disable excessive SAN warning (disabled by default - cosmetic warning only)
MaximumSANCount	`100`	Threshold for excessive SAN alert

Why Monitor Excessive SANs?

Excessive SANs (100+ domains) may indicate:

Configuration Errors: Accidentally added too many domains during certificate request
Poor Certificate Hygiene: Legacy certificates repeatedly appended to during renewals without cleanup
Multi-Tenant Issues: Poorly managed multi-tenant certificates with all customer domains
Performance Impact: TLS handshake performance degradation with very large SAN lists
Management Complexity: Difficult to audit which services/domains are actually using the certificate

Example Excessive SAN Alert

Subject Alternative Names (127)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[domain1.com] [domain2.com] [domain3.com] [domain4.com] [domain5.com]
[domain6.com] [domain7.com] [domain8.com] [domain9.com] [domain10.com]
... (117 more SANs not shown)

⚠️ WARNING: Certificate has 127 SANs (threshold: 100)

Potential Issues:
• Excessive SAN entries may indicate configuration errors
• Large SAN lists can impact TLS handshake performance
• Certificate management complexity increases with SAN count

Recommended Actions:
1. Review SAN list and remove unused domains
2. Consider splitting into multiple certificates by service/environment
3. Verify all listed domains are actively in use

Configuration

Control IIS binding and SAN monitoring behavior:

Setting	Default	Description
MonitorIISCertificateBindings	`false`	Enable/disable IIS binding monitoring (opt-in feature)
AlertOnMultiLevelWildcard	`true`	Warn when multi-level wildcards detected (e.g., `..example.com`)
AlertOnExcessiveSANs	`false`	Warn when SAN count exceeds `MaximumSANCount`
MaximumSANCount	`100`	Threshold for excessive SAN warning
ValidateIISBindingHostnames	`true`	Check that binding hostnames match certificate subject/SANs

For detailed configuration, see Certificate Configuration.

Testing IIS Binding and SAN Monitoring

Test Scenario 1: Create IIS Binding with Matching Certificate

# Prerequisites: IIS installed with HTTPS binding support
Import-Module WebAdministration

# Create self-signed certificate for testing
$cert = New-SelfSignedCertificate `
    -Subject "CN=www.test.local" `
    -DnsName "www.test.local" `
    -CertStoreLocation "Cert:\LocalMachine\My"

# Create IIS site with HTTPS binding
New-Website -Name "TestSite" -PhysicalPath "C:\inetpub\wwwroot" `
    -Port 443 -Ssl -HostHeader "www.test.local"

# Bind certificate to site
$binding = Get-WebBinding -Name "TestSite" -Protocol "https"
$binding.AddSslCertificate($cert.Thumbprint, "my")

# Expected: OK state - exact match between binding hostname and certificate

Test Scenario 2: Create IIS Binding with Wildcard Certificate

# Create wildcard certificate
$wildcardCert = New-SelfSignedCertificate `
    -Subject "CN=*.test.local" `
    -DnsName "*.test.local" `
    -CertStoreLocation "Cert:\LocalMachine\My"

# Create IIS site with subdomain binding
New-Website -Name "APISite" -PhysicalPath "C:\inetpub\wwwroot" `
    -Port 443 -Ssl -HostHeader "api.test.local"

# Bind wildcard certificate to site
$apiBinding = Get-WebBinding -Name "APISite" -Protocol "https"
$apiBinding.AddSslCertificate($wildcardCert.Thumbprint, "my")

# Expected: OK state - wildcard match (*.test.local covers api.test.local)

Test Scenario 3: Create Orphaned Binding (ERROR)

# Create certificate and binding
$tempCert = New-SelfSignedCertificate `
    -Subject "CN=temp.test.local" `
    -DnsName "temp.test.local" `
    -CertStoreLocation "Cert:\LocalMachine\My"

New-Website -Name "TempSite" -PhysicalPath "C:\inetpub\wwwroot" `
    -Port 443 -Ssl -HostHeader "temp.test.local"

$tempBinding = Get-WebBinding -Name "TempSite" -Protocol "https"
$tempBinding.AddSslCertificate($tempCert.Thumbprint, "my")

# Delete certificate while binding remains (simulate orphaned binding)
Remove-Item -Path "Cert:\LocalMachine\My\$($tempCert.Thumbprint)" -Force

# Expected: ERROR state - certificate not found (orphaned binding)

Test Scenario 4: Certificate with Multi-Level Wildcard (WARNING)

# Note: Most CAs won't issue multi-level wildcards, so create with OpenSSL
# Create OpenSSL config file for multi-level wildcard
$opensslConfig = @"
[req]
distinguished_name = req_distinguished_name
req_extensions = v3_req

[req_distinguished_name]

[v3_req]
subjectAltName = @alt_names

[alt_names]
DNS.1 = *.*.test.local
DNS.2 = test.local
"@

Set-Content -Path "multilevel.cnf" -Value $opensslConfig

# Create private key
openssl genrsa -out multilevel.key 2048

# Create CSR with multi-level wildcard
openssl req -new -key multilevel.key -out multilevel.csr -config multilevel.cnf -subj "/CN=*.*.test.local"

# Self-sign certificate
openssl x509 -req -in multilevel.csr -signkey multilevel.key -out multilevel.crt -days 365 -extensions v3_req -extfile multilevel.cnf

# Convert to PFX and import
openssl pkcs12 -export -out multilevel.pfx -inkey multilevel.key -in multilevel.crt -passout pass:test123

$pwd = ConvertTo-SecureString -String "test123" -Force -AsPlainText
$multiLevelCert = Import-PfxCertificate -FilePath "multilevel.pfx" -CertStoreLocation "Cert:\LocalMachine\My" -Password $pwd

# Expected: WARNING state - multi-level wildcard detected (security risk)

Test Scenario 5: Certificate with Excessive SANs (WARNING)

# Create certificate with 110 SANs (above default threshold of 100)
$sanList = 1..110 | ForEach-Object { "domain$_.test.local" }

$excessiveSANCert = New-SelfSignedCertificate `
    -Subject "CN=multidomain.test.local" `
    -DnsName $sanList `
    -CertStoreLocation "Cert:\LocalMachine\My"

# Expected: WARNING state - excessive SANs (110 > 100 threshold)
# Note: Requires AlertOnExcessiveSANs=true in configuration

For comprehensive testing scripts and additional scenarios, see FAQ: IIS Binding Test Scripts.

Security Best Practices

DO - Recommended Practices

Practice	Why It Matters	Implementation
Remove orphaned bindings promptly	Prevents silent failures after certificate deletion	Audit IIS bindings monthly and remove entries for deleted certificates
Validate hostname matches	Ensures users don't see certificate mismatch warnings	Certificate Subject or SAN must match IIS binding hostname
Enable SNI for multi-domain sites	Allows multiple certificates on same IP address	Configure SNI in IIS binding settings for each hostname
Use single-level wildcards only	Universally accepted by CAs and browsers	Use `.example.com` instead of `.*.example.com`
Keep SAN counts reasonable	Improves performance and manageability	Limit to 50 SANs per certificate (remove unused domains)
Update bindings before expiration	Prevents production outages	Plan IIS binding updates 30 days before certificate expiration

DON'T - Practices to Avoid

Anti-Pattern	Risk	Correct Approach
Leave orphaned bindings indefinitely	IIS site fails silently until restart	Remove binding or update certificate reference immediately
Assign wrong certificate to binding	Browser warnings and user trust issues	Verify certificate Subject/SAN matches binding hostname
Use multi-level wildcards	CAs refuse issuance; security violations	Use single-level wildcard + specific SAN entries
Accumulate excessive SANs	TLS handshake degradation; management complexity	Remove unused SANs during renewal; split into multiple certs
Skip binding update after renewal	Service outage when old certificate expires	Update IIS bindings immediately after certificate renewal

Next Step

Duplicate Certificate Detection

Explore Nodinite for 30 days – completely free

See how Nodinite resolves your technical issues, in a

LIVE Demo!

IIS Binding and SAN Monitoring

The Problem: When IIS Bindings and Certificates Go Out of Sync

Scenario: E-Commerce Site Outage After Certificate Renewal

Monitoring States Summary

Overview

IIS Certificate Bindings

IIS Binding States

IIS Binding State Examples

OK State - Exact Match

OK State - Wildcard Match

WARNING State - Expiring Certificate

ERROR State - Hostname Mismatch

ERROR State - Orphaned Binding

ERROR State - Expired Certificate

IIS Binding Monitoring Features

Subject Alternative Names (SAN) Display

SAN Display Features

Example SAN Display

Wildcard Certificate Detection

Single-Level Wildcard (✅ Recommended)

Multi-Level Wildcard (⚠️ Security Risk)

Wildcard Best Practices

Excessive SAN Monitoring

Configuration

Why Monitor Excessive SANs?

Example Excessive SAN Alert

Configuration

Testing IIS Binding and SAN Monitoring

Test Scenario 1: Create IIS Binding with Matching Certificate

Test Scenario 2: Create IIS Binding with Wildcard Certificate

Test Scenario 3: Create Orphaned Binding (ERROR)

Test Scenario 4: Certificate with Multi-Level Wildcard (WARNING)

Test Scenario 5: Certificate with Excessive SANs (WARNING)

Security Best Practices

DO - Recommended Practices

DON'T - Practices to Avoid

Next Step

Related Topics

...