- 10 minutes to read

IIS Binding and SAN Monitoring

Tags: IIS certificate bindings, HTTPS bindings, IIS monitoring, Subject Alternative Names (SAN), wildcard certificates, multi-level wildcards, orphaned bindings, hostname mismatch, SNI, Server Name Indication

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.

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 and SAN Monitoring.

Security Best Practices

IIS Binding Management

Remove Orphaned Bindings: Regularly audit IIS bindings and remove entries for deleted certificates
Hostname Validation: Ensure binding hostnames match certificate subject or SANs
SNI Configuration: Enable SNI for multi-certificate IIS sites hosting multiple domains
Certificate Renewal: Plan IIS binding updates before certificate expiration
Binding Documentation: Maintain inventory of IIS sites and their certificate bindings

SAN and Wildcard Management

Use Single-Level Wildcards Only: Avoid *.*.example.com patterns (CAs will refuse issuance)
Minimize SAN Count: Only include domains actively in use (remove legacy/unused domains)
Separate Environments: Use different certificates for dev/staging/production
Include Apex Domain: Add example.com as SAN alongside *.example.com wildcard
Review SANs Regularly: Audit SAN lists during renewal and remove unused entries

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

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

IIS Binding Management

SAN and Wildcard Management

Next Step

Related Topics

...