- 11 minutes to read
Certificate Monitoring Configuration
Configure comprehensive X509 certificate monitoring for Windows Server, including traditional expiration tracking, IIS HTTPS binding validation, private key health monitoring, and service account access.
Configuration Overview
Certificate monitoring configuration provides granular control over:
- ✅ Certificate store selection (LocalMachine, CurrentUser, service accounts)
- ✅ Expiration thresholds (global and certificate-specific)
- ✅ Private key health monitoring (Phase 1)
- ✅ Weak cryptography detection (Phase 2)
- ✅ Chain validation options (Phase 3)
- ✅ Certificate purpose validation (Phase 4)
- ✅ IIS HTTPS binding monitoring (Phase 5)
Configuration Sections
Expiration Thresholds
Configure when certificates should trigger warning and error alerts based on days until expiration.
Global Thresholds
Set default thresholds that apply to all certificates without specific overrides:
| Configuration | Default | Range | Purpose |
|---|---|---|---|
| Warning Days Before Expiration | 30 days | 1–365 days | Generate WARNING alert when certificate expires within this timeframe |
| Error Days Before Expiration | 7 days | 1–365 days | Generate ERROR alert when certificate expires within this timeframe |
Certificate-Specific Thresholds
Override global settings for individual certificates with different criticality levels:
- High-Impact Certificates (load balancers, API gateways): Set Warning to 60 days, Error to 14 days
- Standard Certificates (web servers, services): Use global defaults (30/7 days)
- Development Certificates (test/staging): Set Warning to 5 days, Error to 1 day
Certificate Store Selection
Choose which certificate stores to monitor on the target Windows Server:
| Store | Scope | Access | Use Cases |
|---|---|---|---|
| LocalMachine\My (Personal) | System-wide, all users | Direct access | IIS bindings, service certificates, RDP certificates |
| LocalMachine\Root | Trusted root CAs | Read-only | Monitor trusted CA certificate expiration |
| LocalMachine\Intermediate | Intermediate CAs | Read-only | Chain validation, missing intermediate detection |
| CurrentUser\My | Current user only | User context | User certificates, smart cards |
| Service Account\My | Specific service account | Credential required | Application-specific certificates (SQL, etc.) |
Service Account Credentials
Monitor certificates in service account personal stores by providing encrypted credentials:
How It Works
- Provide Credentials: Enter service account username and password
- Encryption: Credentials are encrypted and stored securely once saved
- Monitoring: Agent uses credentials to access service account's certificate store
- Verification: Test credentials with "Verify" button before saving
Security Best Practices
- ✅ Use dedicated service accounts with minimal permissions
- ✅ Credentials encrypted at rest in agent configuration
- ✅ Credentials transmitted securely to monitoring agent
- ✅ Regularly rotate service account passwords
- ✅ Audit service account access logs
- ❌ Do NOT use production admin credentials
- ❌ Do NOT use interactive user credentials
Group Managed Service Accounts (gMSA)
Monitoring gMSA account certificates requires special configuration:
- gMSAs use passwordless authentication (cannot use traditional credentials)
- Requires dedicated agent instance on gMSA member server
- Agent runs under gMSA context to access certificate store
- See FAQ: Certificates for gMSA Accounts for detailed setup
Private Key Health Monitoring
Monitor certificate private keys for presence, accessibility, and security risks (Phase 1 feature):
| Configuration | Default | Purpose |
|---|---|---|
| Monitor Private Key Health | Enabled | Enable/disable private key monitoring |
| Alert on Missing Private Key | Enabled | ERROR when personal/My store cert has no private key |
| Alert on Exportable Private Key | Enabled | WARNING when private key is exportable (security risk) |
| Minimum Private Key Length | 2048 bits | WARNING if RSA key < this length (recommendations: 2048 RSA, 256 ECDSA) |
Private Key Scenarios
- ✅ OK: Certificate has non-exportable private key, key length ≥ 2048 bits
- ⚠️ Warning: Certificate has exportable private key OR key length below minimum
- ❌ Error: Certificate in Personal store lacks private key (rendering it unusable)
Weak Cryptography Detection
Detect certificates using deprecated or weak cryptographic algorithms (Phase 2 feature):
| Configuration | Alert Level | Purpose |
|---|---|---|
| Alert on Weak Signature Algorithms | WARNING | SHA-1, MD5 signatures are deprecated |
| Alert on Weak Hash Algorithms | WARNING | MD5, SHA-1 hashes require replacement |
| Alert on Weak Public Key Length | WARNING | RSA < 2048 bits, ECDSA < 256 bits |
| Alert on Deprecated Algorithms | INFO | Algorithms approaching end-of-life |
Algorithm Security Assessment
- ✅ Secure: SHA-256 or better, RSA ≥2048 or ECDSA ≥256
- ⚠️ Weak: SHA-1, MD5, or key lengths below minimum
- ❌ Dangerous: MD5 signatures, RSA < 1024, or deprecated algorithms
Certificate Chain Validation
Enable detailed chain validation with 20+ specific error types (Phase 3 feature):
| Configuration | Alert Level | Purpose |
|---|---|---|
| Enhanced Chain Validation | Master toggle | Enable/disable comprehensive chain validation |
| Alert on Untrusted Root | ERROR | Root certificate not in trusted store |
| Alert on Partial Chain | ERROR | Missing intermediate certificates in chain |
| Alert on Revocation Check Failures | WARNING | Cannot verify revocation status (CRL/OCSP) |
| Alert on Expired Intermediates | ERROR | Intermediate CA certificate has expired |
| Allow Self-Signed Certificates | Toggle | Reduce severity for dev/test self-signed certs |
Chain Validation Errors
- ✅ OK: Complete chain from leaf to trusted root, no revoked certificates
- ⚠️ Warning: Partial chain or revocation check issues
- ❌ Error: Untrusted root, expired intermediates, or revoked certificates
Certificate Purpose & EKU Validation
Validate that certificates match their intended purposes (Phase 4 feature):
| Configuration | Alert Level | Purpose |
|---|---|---|
| Validate Certificate Purpose | Master toggle | Enable/disable purpose validation |
| Alert on Multi-Purpose Certificates | WARNING | Certificate with multiple EKU extensions |
| Alert on Any Purpose EKU | CRITICAL | Overly permissive "Any Purpose" certificates |
| Alert on Missing Key Usage | WARNING | Certificate without proper Key Usage flags |
Purpose Validation Results
- ✅ OK: Certificate purpose matches intended usage, single EKU
- ⚠️ Warning: Multi-purpose or missing usage definitions
- ❌ Critical: "Any Purpose" certificates detected
Duplicate Certificate Detection
Detect multiple certificates with identical Subject and SAN combinations to prevent renewal confusion and application selection errors (Phase 6 feature):
What Are Duplicate Certificates?
Duplicate certificates are multiple X.509 certificates with:
- Same Subject DN (Distinguished Name)
- Same SAN (Subject Alternative Name) extensions
- Different Thumbprints (different key material or signature)
Why Do Duplicates Occur?
- Certificate renewal before old cert expiration (both remain valid)
- Manual backup and restore operations
- Test certificate deployment leaving dev certs in production stores
- Application using wrong certificate from personal store
- Cross-store duplication (same cert in LocalMachine and CurrentUser)
Why Is This a Problem?
- ⚠️ Application Confusion: Apps may select wrong certificate (old vs new, wrong store)
- ⚠️ Private Key Risk: Multiple certs with private keys create ambiguity
- ⚠️ Stale Certificates: Old certificates remain even after successful renewal
- ⚠️ Manual Cleanup: Requires deliberate action to identify and remove duplicates
Duplicate Detection Configuration
| Configuration | Default | Options | Purpose |
|---|---|---|---|
| Detect Duplicate Certificates | Enabled | Toggle | Master switch for duplicate certificate detection |
| Alert on Duplicates with Private Keys | Enabled | Toggle | ERROR when multiple duplicates have private keys (ambiguous selection) |
| Alert on Cross-Store Duplicates | Enabled | Toggle | WARNING when same certificate exists in different stores (LocalMachine vs CurrentUser) |
| Maximum Allowed Duplicates | 1 | 1–10 | WARNING/ERROR when duplicate count exceeds this threshold |
Duplicate Detection Scenarios
Scenario 1: Successful Renewal (OK)
- Old certificate expires 2025-01-15
- New certificate obtained 2025-01-10
- Both valid simultaneously (overlap period)
- Only 1 cert has private key (new one)
- Alert: ℹ️ Info - "Certificate has 1 duplicate (expires 2025-01-15)"
- Action: Manual removal of old cert after expiration
Scenario 2: Private Key Ambiguity (ERROR)
- Certificate1 (Thumbprint: ABC123) - private key, expires 2026-01-15
- Certificate2 (Thumbprint: DEF456) - private key, expires 2026-01-15
- Both have identical Subject/SAN
- Alert: ❌ Error - "Certificate has 2 duplicates with private keys (ambiguous selection)"
- Action: Identify correct cert, remove private key from unused certs
Scenario 3: Cross-Store Duplication (WARNING)
- LocalMachine\My\Certificate (private key)
- CurrentUser\My\Certificate (same thumbprint via import)
- Alert: ⚠️ Warning - "Certificate duplicated across stores (LocalMachine + CurrentUser)"
- Action: Verify intentional cross-store placement or consolidate
Scenario 4: Threshold Exceeded (WARNING)
- Certificate has 3 copies with identical Subject/SAN
- Maximum Allowed Duplicates = 1 (default)
- Alert: ⚠️ Warning - "Certificate has 3 duplicates (exceeds maximum of 1)"
- Action: Investigate and clean up unnecessary duplicates
Duplicate Information Display
When duplicates detected, certificate display includes:
- Duplicate Count: How many certificates share same Subject/SAN
- Duplicate List: Thumbprints of all duplicate certificates
- Private Key Status: Which duplicates have private keys
- Store Location: Where each duplicate is stored
- Expiration Dates: Validity period for each duplicate
How to Remediate Duplicates
Step 1: Identify Duplicates
Run remote action to list duplicate certificates:
# View all certificates with duplicates
Get-ChildItem -Path 'Cert:\LocalMachine\My' | Group-Object -Property Subject | Where-Object { $_.Count -gt 1 }
Step 2: Verify Which Cert Is Current
- Compare thumbprints against application configuration
- Check IIS bindings for active certificate
- Review certificate properties (issuance date, key size)
Step 3: Clean Up Old Duplicates
- For renewal overlaps: wait for old cert expiration, then delete
- For mistakes: delete incorrect/dev certificates immediately
- For cross-store: decide if consolidation needed or intentional
Step 4: Remove Private Key from Unused Copies
- If old cert no longer needed but in stores: remove private key
- Leaves certificate for chain validation, removes selection ambiguity
- Use Certificate Manager or PowerShell:
Remove-Item -Path Cert:\LocalMachine\My\THUMBPRINT -DeleteKey
Best Practices for Duplicate Prevention
- ✅ Renewal Timeline: Start renewal 30+ days before expiration (reduce overlap)
- ✅ Automated Cleanup: Delete old certificate immediately after renewal verifies
- ✅ Single Source of Truth: Maintain certificate in one store location (LocalMachine vs CurrentUser)
- ✅ Documentation: Document which certificates belong where and why
- ✅ Regular Audits: Quarterly review of personal stores for duplicates
- ✅ Testing Isolation: Use separate test environments, not production stores
- ✅ Remove Private Keys: For duplicate certs no longer needed, remove private key before deletion
IIS HTTPS Binding Monitoring
Monitor IIS certificate bindings and detect mismatches, missing certificates, and other binding issues (Phase 5 feature):
Feature Availability
- Opt-In: Feature is disabled by default (
MonitorIISCertificateBindings = false) - Graceful Degradation: If IIS not installed, monitoring returns empty results (no errors)
- IIS Requirement: Only functions when IIS is installed on the monitored server
IIS Binding Configuration
| Configuration | Default | Purpose |
|---|---|---|
| Monitor IIS Certificate Bindings | Disabled (false) | Enable/disable IIS binding monitoring |
| IIS Binding Warning Days | 30 days | WARNING when bound certificate expires within timeframe |
| Alert on Missing IIS Certificate | Enabled | ERROR when IIS binding references non-existent certificate |
| Alert on Hostname Mismatch | Enabled | WARNING when binding hostname doesn't match certificate |
| Alert on Stale IIS Bindings | Enabled | WARNING when old certificate still in use after renewal |
IIS Binding Features
- ✅ Wildcard Support:
*.example.comcertificate matcheswww.example.combinding - ✅ SNI Detection: Shows which bindings use Server Name Indication
- ✅ Mismatch Detection: Alerts when hostname doesn't match certificate Subject/SAN
- ✅ Single Category: IIS binding info shown in existing certificate display (no duplicate category)
IIS Binding State Evaluation
| Scenario | State | Example Alert |
|---|---|---|
| Valid binding, matching cert, not expiring | ✅ OK | None |
| Binding references missing certificate | ❌ ERROR | IIS site 'WebServer' binding references missing certificate (Thumbprint: ABC123...) |
| Binding hostname doesn't match certificate | ⚠️ WARNING | IIS site 'WebServer' hostname 'www.example.com' doesn't match certificate 'api.example.com' |
| Bound certificate expires in 5 days | ⚠️ WARNING | IIS site 'WebServer' certificate expires in 5 days (expires 2025-12-20) |
| Old certificate still bound after renewal | ⚠️ WARNING | IIS site 'WebServer' using stale certificate (newer cert available) |
Why Disabled by Default?
- IIS Requirement: Only works if IIS is installed (not all servers have IIS)
- Feature Server Role: Monitoring IIS is a specific use case, not universal
- Graceful Handling: If enabled but IIS not installed, reports as empty (no crash)
When to Enable
Enable IIS binding monitoring when:
- ✅ Server is running IIS (local or remote)
- ✅ You want to monitor HTTPS binding certificate validity
- ✅ You need to detect hostname mismatches
- ✅ You want early warning before binding certificates expire
- ❌ Server is NOT running IIS (monitoring would be wasted)
Accessing Configuration
Configuration Methods
- Remote Configuration - Configure via Nodinite web interface
- Agent Configuration Files - Edit XML configuration on agent machine
- PowerShell Remoting - Configure remotely via PowerShell cmdlets
Configuration Storage
- Agent Machine:
C:\Program Files\Nodinite\Agent\Config\AgentConfig.xml - Web Interface: Settings → Agents → [Agent Name] → Certificate Monitoring
- Backup: Configuration automatically backed up before changes
Configuration Checklist
Before deploying certificate monitoring:
- ☐ Identify which certificate stores to monitor (LocalMachine, CurrentUser, service accounts)
- ☐ Set appropriate warning/error thresholds for your environment
- ☐ For service accounts: prepare credentials and test connectivity
- ☐ Enable/disable specific monitoring phases based on requirements:
- Phase 1 (Private Key Health) - Recommended for all
- Phase 2 (Weak Crypto) - Recommended for compliance
- Phase 3 (Chain Validation) - Recommended for trust verification
- Phase 4 (Purpose Validation) - Optional, depends on certificate purpose tracking needs
- Phase 5 (IIS Binding) - Enable only if server runs IIS
- ☐ Configure alert thresholds and notification channels
- ☐ Test configuration with sample certificates
- ☐ Document certificate-specific thresholds
- ☐ Plan for certificate renewal automation
Best Practices
Threshold Strategy
- Production Systems: Warning 60 days, Error 14 days (aggressive)
- Standard Services: Warning 30 days, Error 7 days (recommended)
- Development: Warning 7 days, Error 1 day (relaxed)
Service Account Security
- Use dedicated low-privilege service accounts
- Rotate passwords quarterly
- Monitor service account login attempts
- Test credential access before saving
- Never use interactive admin credentials
IIS-Specific Recommendations
- Enable IIS binding monitoring on all IIS servers
- Set warning threshold to 30+ days to catch renewal delays
- Regularly audit bindings for stale certificates
- Ensure renewal automation updates bindings
- Test wildcard certificate matching with specific hostnames
Compliance & Auditing
- Document all certificate-specific threshold overrides
- Maintain audit log of configuration changes
- Review expired certificates quarterly
- Plan upgrades for weak cryptography detection compliance
- Validate chain validation settings for regulatory requirements