- 11 minutes to read

FAQ - IIS Binding and SAN Monitoring Testing Scenarios

Validate IIS Binding and SAN Monitoring with automated PowerShell test scripts covering all detection scenarios - from healthy bindings and wildcard matches to orphaned bindings, hostname mismatches, multi-level wildcard security risks, and excessive SAN counts.

What's on This Page:

  • 8 Test Scenarios - Configuration tables for Healthy Bindings, Wildcard Matches, Orphaned Bindings, Hostname Mismatches, Expiring Certificates, Multi-Level Wildcards, Excessive SANs, and SNI Configuration
  • Automated Test Scripts - Batch and cleanup PowerShell scripts for all scenarios
  • Configuration Guide - Enable IIS binding monitoring and configure alert thresholds
  • Troubleshooting - Resolve binding-specific issues (orphaned bindings, hostname mismatches, wildcard validation)

Why Test IIS Binding and SAN Monitoring?

IIS binding testing prevents production incidents caused by certificate-binding mismatches and configuration drift. Testing ensures monitoring correctly identifies:

  • ✅ Healthy bindings (OK) - Certificate matches hostname exactly or via wildcard
  • ❌ Orphaned bindings (ERROR) - Certificate deleted but IIS binding still references thumbprint
  • ⚠️ Hostname mismatches (WARNING) - Certificate doesn't match binding hostname
  • ⚠️ Expiring certificates (WARNING) - Certificate within warning threshold
  • ⚠️ Multi-level wildcards (WARNING) - Security risk with *.*.example.com patterns
  • ⚠️ Excessive SANs (WARNING) - Certificate with 100+ SAN entries

Related Documentation: See IIS Binding and SAN Monitoring for complete feature documentation, configuration options, and security best practices.

Note

These scripts require PowerShell 7+ with Administrator privileges for IIS configuration access.

Warning

Never deploy test IIS sites to production environments. Always clean up after validation testing.

Testing Scenarios Overview

# Scenario Purpose Expected State Key Focus
1 Healthy IIS Binding Certificate matches hostname exactly ✅ OK Exact hostname match validation
2 Orphaned Binding Certificate deleted but binding remains ❌ ERROR Binding references missing certificate
3 Expired Certificate Binding Binding uses expiring certificate ⚠️ WARNING Certificate within warning threshold
4 Hostname Mismatch Wrong certificate assigned to binding ⚠️ WARNING Certificate doesn't match hostname
5 Wildcard Certificate Binding Wildcard certificate covers subdomain ✅ OK Single-level wildcard matching
6 IIS Not Installed Monitoring enabled without IIS ⚠️ WARNING Graceful degradation
7 Multi-Level Wildcard *.*.example.com security risk ⚠️ WARNING Security best practice violation
8 Excessive SANs Certificate with 100+ SAN entries ⚠️ WARNING SAN count threshold enforcement

Test Scenario Workflow

graph TD Start[" Start Testing"] --> Config[" Configure Scenarios"] Config --> S1{" Scenario 1<br/>Healthy Binding"} Config --> S2{" Scenario 2<br/>Orphaned"} Config --> S3{" Scenario 3<br/>Expiring"} Config --> S4{" Scenario 4<br/>Mismatch"} Config --> S5{" Scenario 5<br/>Wildcard"} Config --> S6{" Scenario 6<br/>No IIS"} Config --> S7{" Scenario 7<br/>Multi-Level"} Config --> S8{" Scenario 8<br/>Excessive SANs"} S1 --> V1[" OK"] S2 --> V2[" Error"] S3 --> V3[" Warning"] S4 --> V4[" Warning"] S5 --> V5[" OK"] S6 --> V6[" Info/Warning"] S7 --> V7[" Warning"] S8 --> V8[" Warning"] V1 --> Monitor[" Monitor Results"] V2 --> Monitor V3 --> Monitor V4 --> Monitor V5 --> Monitor V6 --> Monitor V7 --> Monitor V8 --> Monitor Monitor --> Validate[" Validate Alerts"] Validate --> Cleanup[" Cleanup Test Sites"] Cleanup --> End[" Testing Complete"] style S1 fill:#e8f5e9 style S2 fill:#ffebee style S3 fill:#fff3e0 style S4 fill:#fff3e0 style S5 fill:#e8f5e9 style S6 fill:#e3f2fd style S7 fill:#fff3e0 style S8 fill:#fff3e0 style V1 fill:#c8e6c9 style V2 fill:#ffcdd2 style V3 fill:#ffe0b2 style V4 fill:#ffe0b2 style V5 fill:#c8e6c9 style V6 fill:#bbdefb style V7 fill:#ffe0b2 style V8 fill:#ffe0b2

Diagram: IIS binding and SAN monitoring test workflow showing scenario configuration, expected states, and validation process with color-coded severity levels.

Test Scenarios

Scenario 1: Healthy IIS Binding

Purpose: Validate OK state when certificate matches binding hostname exactly.

Configuration:

Setting Value Rationale
Certificate Type Self-signed (test certificate) Creates controlled valid binding
Certificate Subject CN=www.testsite.local Exact match to binding hostname
Certificate SANs www.testsite.local, testsite.local Additional domain coverage
IIS Site Name TestSite Identifiable test site
Binding Hostname www.testsite.local Matches certificate subject exactly
Port 443 Standard HTTPS port
Certificate Validity 1 year Non-expiring certificate

Expected Results:

Aspect Value
State ✅ OK
Validation Certificate matches binding hostname
Certificate Status Present in store, not expired
Hostname Match Exact match between binding and certificate
Alert None (healthy configuration)

Scenario 2: Orphaned Binding (Missing Certificate)

Purpose: Validate ERROR state when certificate is deleted but IIS binding still references it.

Configuration:

Setting Value Rationale
Certificate Type Self-signed (test certificate) Creates controlled orphaned scenario
Certificate Subject CN=orphaned.testsite.local Identifies orphaned test
IIS Site Name NodiniteOrphanedSite Identifiable test site
Binding Hostname orphaned.testsite.local Initially valid binding
Port 8443 Non-standard port to avoid conflicts
Certificate Action Delete certificate after binding creation Simulates orphaned binding

Expected Results:

Aspect Value
State ❌ ERROR
Detection IIS binding references missing certificate
Alert Message "IIS site 'NodiniteOrphanedSite' binding references missing certificate (Thumbprint: ABC123...)"
Impact Website fails with SSL error; binding unresolvable
Recommendation Remove orphaned binding or reinstall certificate

Scenario 3: Expired Certificate Binding

Purpose: Validate WARNING state when certificate expires within warning threshold.

Configuration:

Setting Value Rationale
Certificate Type Self-signed (test certificate) Creates controlled expiring scenario
Certificate Subject CN=expiring.testsite.local Identifies expiring test
Certificate Validity 1 day Expires within warning threshold
IIS Site Name NodiniteExpiringSite Identifiable test site
Binding Hostname expiring.testsite.local Matches certificate subject
Port 9443 Non-standard port to avoid conflicts
Warning Threshold IISBindingWarningDays = 7 Default warning threshold

Expected Results:

Aspect Value
State ⚠️ WARNING
Detection Certificate expires within warning threshold
Alert Message "IIS site 'NodiniteExpiringSite' certificate expires in 1 day"
Timing Alert triggers before actual expiration
Recommendation Renew certificate and update binding

Scenario 4: Hostname Mismatch

Purpose: Validate WARNING state when certificate doesn't match binding hostname.

Configuration:

Setting Value Rationale
Certificate Type Self-signed (test certificate) Creates controlled mismatch scenario
Certificate Subject CN=site-a.local Certificate for wrong hostname
IIS Site Name NodiniteMismatchSite Identifiable test site
Binding Hostname site-b.local Doesn't match certificate subject
Port 443 Standard HTTPS port
Certificate Validity 1 year Valid, non-expiring certificate

Expected Results:

Aspect Value
State ⚠️ WARNING
Detection Hostname mismatch between binding and certificate
Alert Message "IIS site 'NodiniteMismatchSite' hostname 'site-b.local' does not match certificate 'site-a.local'"
Impact Clients see SSL certificate mismatch warnings
Recommendation Use correct certificate or update binding hostname

Scenario 5: Wildcard Certificate Binding

Purpose: Validate OK state when wildcard certificate correctly matches subdomain binding.

Configuration:

Setting Value Rationale
Certificate Type Self-signed wildcard certificate Creates controlled wildcard scenario
Certificate Subject CN=*.example.com Single-level wildcard
Certificate SANs *.example.com, example.com Wildcard + apex domain
IIS Site Name NodiniteWildcardSite Identifiable test site
Binding Hostname www.example.com Subdomain covered by wildcard
Port 443 Standard HTTPS port
Certificate Validity 1 year Non-expiring certificate

Expected Results:

Aspect Value
State ✅ OK
Validation Wildcard certificate *.example.com matches hostname www.example.com
Match Type Wildcard match (single-level, secure)
Details Page Emphasizes wildcard usage for administrator clarity
Alert None (valid wildcard configuration)

Scenario 6: IIS Not Installed

Purpose: Validate graceful degradation when IIS binding monitoring is enabled but IIS is not installed.

Configuration:

Setting Value Rationale
IIS Installation NOT installed Tests graceful handling of missing IIS
Monitoring Setting MonitorIISCertificateBindings = true Feature enabled
Server Role Non-IIS server (e.g., database server) Typical scenario for feature check

Expected Results:

Aspect Value
State ⚠️ WARNING
Behavior Graceful degradation (does NOT show ERROR)
Message "IIS binding monitoring enabled but IIS is not installed on server "
Impact No false errors; monitoring continues on other servers
Reason IIS is optional - not all servers have web server role

Scenario 7: Multi-Level Wildcard Certificate (Security Risk)

Purpose: Validate WARNING state when multi-level wildcard certificate is detected.

Configuration:

Setting Value Rationale
Certificate Type Self-signed multi-level wildcard Creates security risk scenario
Certificate Pattern *.*.example.com Multi-level wildcard (security violation)
Certificate SANs *.*.example.com, example.com Overly permissive pattern
IIS Site Name NodiniteMultiLevelWildcardSite Identifiable test site
Binding Hostname api.dev.example.com Multi-level subdomain
Port 443 Standard HTTPS port
Alert Setting AlertOnMultiLevelWildcard = true Default setting

Expected Results:

Aspect Value
State ⚠️ WARNING
Detection Multi-level wildcard pattern detected
Alert Message "Certificate contains multi-level wildcard (..example.com) which is overly permissive"
Security Risk CAs refuse issuance; violates best practices
Recommendation Replace with single-level wildcard or specific SAN entries

Why This Is Flagged:

  • Most certificate authorities refuse to issue multi-level wildcards
  • Overly permissive scope violates security best practices
  • Modern browsers may reject or warn about multi-level wildcards
  • Creates ambiguous certificate selection scenarios

Scenario 8: Certificate with Excessive SANs

Purpose: Validate WARNING state when certificate has excessive SAN entries (100+ SANs).

Configuration:

Setting Value Rationale
Certificate Type Certificate with 120+ SANs Creates excessive SAN scenario
SAN Count 120 SAN entries Exceeds threshold of 100
SAN Pattern subdomain1.example.com through subdomain120.example.com Simulates multi-tenant or legacy certificate
IIS Site Name NodiniteExcessiveSANSite Identifiable test site
Binding Hostname subdomain1.example.com One of many SANs
Port 443 Standard HTTPS port
Alert Setting AlertOnExcessiveSANs = true, MaximumSANCount = 100 Threshold enforcement

Expected Results:

Aspect Value
State ⚠️ WARNING (if AlertOnExcessiveSANs enabled)
Detection SAN count exceeds configured threshold
Alert Message "Certificate has 120 SANs (threshold: 100)"
Details Page All SAN entries displayed as badges
Impact Informational alert about potential configuration issues

Why Monitor Excessive SANs?

  • Indicates possible configuration errors
  • Performance issues in TLS handshakes with 100+ SANs
  • May indicate poorly managed multi-tenant certificates
  • Legacy certificates repeatedly appended to during renewals

Note: Creating test certificates with 100+ SANs requires OpenSSL or a certificate authority. The batch script example is simplified for demonstration purposes.

Implementation Details

Data Collection Method

Nodinite uses the Microsoft.Web.Administration assembly (part of IIS) to:

  1. Check if IIS management APIs are available
  2. Enumerate all IIS sites and HTTPS bindings
  3. Extract certificate thumbprints from bindings
  4. Lookup certificates in the certificate store by thumbprint
  5. Cross-reference hostname in binding against certificate Subject and Subject Alternative Names (SAN)
  6. Parse and display all Subject Alternative Names from certificate extensions
  7. Detect wildcard patterns including single-level (*.example.com) and multi-level (*.*.example.com) wildcards
  8. Evaluate certificate expiration dates
  9. Count SAN entries and alert on excessive SANs (if configured)

Wildcard Certificate Matching

Nodinite implements proper wildcard matching logic:

  • *.example.com matches www.example.com ✅
  • *.example.com matches api.example.com ✅
  • *.example.com does NOT match example.com (base domain) ✅
  • Multi-level wildcards like *.*.example.com are detected and flagged as security risks ⚠️

Subject Alternative Names (SAN) Parsing

Nodinite parses X.509 certificate SAN extensions:

  • Extracts all SAN entries: DNS names, IP addresses, URIs from certificate extensions
  • Counts SAN entries: Displays total SAN count in certificate details
  • Detects wildcards: Identifies single-level and multi-level wildcard patterns
  • Excessive SAN alerts: Optional warnings when SAN count exceeds threshold (default: 100)
  • Badge display: All SANs shown as visual badges in details view for easy scanning

SNI Support

Modern IIS configurations use Server Name Indication (SNI) to host multiple HTTPS sites on the same IP address. Nodinite collects and displays SNI information in diagnostic views for troubleshooting purposes.

Per-Server Monitoring

In a group scenario, each server is monitored independently:

  • One resource per IIS site per server
  • Each site shows its certificate binding status
  • Group-level view summarizes bindings across all servers

Troubleshooting

Feature Is Enabled But No IIS Bindings Appear

Check:

  1. Is IIS actually installed? (Get-WindowsFeature Web-Server)
  2. Are there any HTTPS bindings configured? (Get-IISSite | Select-Object -ExpandProperty Bindings)
  3. Does Nodinite have permissions to read IIS configuration?

False Positive: "Expired Certificate" Warning

Check:

  1. Verify the warning threshold setting (IISBindingWarningDays)
  2. Confirm certificate expiration date: Get-Item Cert:\LocalMachine\My\{Thumbprint} | Select-Object NotAfter
  3. Check server system time is correct

Wildcard Certificate Shows as Mismatch

Check:

  1. Wildcard certificate must be formatted as *.domain.com, not domain.com
  2. Certificate SAN must include the wildcard entry
  3. Verify binding hostname falls under wildcard scope

Best Practices

  1. Monitor Early: Enable IIS binding monitoring to catch issues before they impact users
  2. Set Appropriate Warnings: Configure warning threshold (typically 30-60 days before expiration)
  3. Track Wildcard Usage: Note which sites use wildcard certificates in your inventory
  4. Avoid Multi-Level Wildcards: Never use *.*.example.com patterns - they're security risks
  5. Manage SANs Carefully: Keep SAN counts reasonable (under 50 for most use cases)
  6. Automate Renewals: Integrate certificate renewal with IIS binding updates
  7. Regular Audits: Periodically review bindings to ensure no stale certificates remain in use
  8. SAN Hygiene: Remove unused SAN entries during certificate renewal to prevent SAN bloat

Frequently Asked Questions

Q1: Why does IIS binding monitoring show WARNING instead of ERROR when IIS is not installed?

A: This is intentional graceful degradation. The feature detects the absence of IIS and shows a WARNING state instead of ERROR to prevent false alerts on servers not running web services (e.g., database servers, file servers). The reasoning:

  • ERROR state would trigger alerts for servers that will never have IIS installed
  • WARNING state acknowledges the situation without creating alert noise
  • If IIS is expected on the server, the administrator can investigate why it's missing
  • Reduces false positive alerts in heterogeneous server environments

Q2: What happens when I renew a certificate - do I need to update IIS bindings manually?

A: Yes, you must manually update IIS bindings after certificate renewal. Here's why:

  • IIS bindings reference certificates by thumbprint (SHA-1 hash of certificate)
  • Certificate renewal creates a new certificate with a different thumbprint
  • The old IIS binding still references the expired certificate's thumbprint
  • Orphaned binding detection triggers an ERROR state when the old certificate is deleted
  • Manual remediation: Update IIS binding to reference the new certificate thumbprint via IIS Manager or PowerShell

Example scenario: You renew *.example.com on Sunday. The new certificate has thumbprint ABC123.... On Monday, the old certificate expires. IIS bindings still reference the old thumbprint DEF456.... Result: HTTPS sites fail until bindings updated.

Q3: Why are multi-level wildcards (*.*.example.com) flagged as security risks?

A: Multi-level wildcards violate CA/Browser Forum Baseline Requirements and create security vulnerabilities:

  • CA Refusal: Most Certificate Authorities refuse to issue multi-level wildcard certificates (violates industry standards)
  • Over-Permissive: *.*.example.com would match anything.anythingelse.example.com - excessive scope increases attack surface
  • Security Best Practice: Use single-level wildcards (*.example.com) combined with specific SAN entries for subdomains requiring certificates
  • Detection: The monitor flags these as WARNING to alert administrators to replace with compliant alternatives

Alternative approach: Issue *.example.com with SAN entries for specific subdomains like api.services.example.com, portal.services.example.com.

Next Step