SSL Domain Monitoring

Monitor the HTTPS certificate presented by a hostname without taking over its certificate issuance, DNS or deployment. This feature accompanies the forthcoming Client Server 1.0.10 release.

Separate Monitoring Allowances

Monitor-only registrations do not consume automated certificate capacity or managed parent-domain slots. Each concrete hostname is a monitoring entry; SANs are observations and do not automatically create additional manual registrations. Monitoring capacity is shared across the installation’s customer estates, while results remain scoped to the selected estate. Paid effective allowances may be adjusted through your licence; Free remains fixed.

Add A Hostname And Its Rules

1. Open SSL Monitoring in the Client Server menu.
2. Enter a DNS hostname or HTTPS URL on port 443, such as service.example.org. Monitoring does not require you to move the domain’s certificate management to SSLNexus.
3. Set an expiry warning from 1 to 365 days and a check interval from 15 to 1,440 minutes. Defaults are 30 days and hourly checks.
4. Enable themed alerts and configure recipients, mail transport and optional routing in Notifications. The event type is certificate.monitor.
5. Save the rules. The background worker checks eligible entries and retains results across restarts.

Operators and organisation administrators can manage monitor rules; read-only staff can inspect their estate’s results. Monitoring uses outbound HTTPS probes with bounded timeouts and concurrency. Private-network destinations must fall within the configured network-discovery CIDRs. Loopback, link-local and metadata destinations remain blocked. No inbound monitoring listener is required.

Automatic And Manual Entries

Concrete hostnames on current, issued or managed SSLNexus certificates are added automatically. This includes certificate requests handled through Vendor Portal. They use no monitor-only slots, including when you also choose to retain that hostname manually. Wildcard names are not probeable endpoints and are not expanded into guessed hosts.

Automatic-only entries leave the active monitoring list after expiry or confirmed revocation. Configured final alerts are attempted before retirement. Renewal or a newly managed certificate can register the hostname again. An unreachable endpoint, DNS failure or unknown revocation status alone does not remove it. Removing a still-valid certificate from inventory does not stop its monitoring early: the persisted source expiry retains coverage until expiry or confirmed revocation.

Manual registrations remain after expiry or revocation. They continue checking and alerting according to their rules until you remove them. When valid automatic coverage for a manually retained hostname ends, it uses a monitoring slot again. Downgrading does not delete registrations: entries beyond the new allowance are retained but checks pause until capacity becomes available. The dashboard shows installation usage.

What The Checks Mean

• Temporal validity: NotBefore, NotAfter and expiry warning windows.
• SANs and hostname: names presented by the server and whether the requested hostname matches the certificate. Certificates relying only on an obsolete CN do not pass modern hostname validation.
• Chain trust: verifies the presented leaf and intermediates against the Client Server’s system roots. A root normally does not need to be sent by the server. An incomplete or untrusted chain is flagged; private CA roots must be trusted by the monitoring host.
• Revocation: verifies a fresh stapled OCSP response, otherwise tries the certificate’s OCSP responder and CRL distribution points. Missing, stale, unreachable, unsupported or unverifiable evidence is unknown, not “good” or “revoked.” SHA-256 OCSP requests preserve strict-FIPS operation; responders that do not accept them may remain unknown.
• TLS and cipher strength: records the negotiated protocol and cipher using a TLS 1.2 minimum, and probes for observable older TLS versions and weak cipher suites. “Not observed by runtime” does not certify that every weak suite is disabled: FIPS restrictions, network errors and handshake limitations can prevent a probe.

Monitoring flags problems; it cannot block or change encryption on a remote server. It is an HTTPS certificate check, not an exhaustive vulnerability scan, HTTP uptime service or guarantee that every load-balanced backend presents the same certificate. No private keys or CA credentials are needed.

Themed Alerts And Delivery

Expiry warnings, invalid hostname/trust, endpoint failure, confirmed revocation and observed weak TLS can generate themed SSLNexus alerts through the existing notification system. A daily deduplication key limits repeated messages for the same hostname, certificate and condition. Configure delivery before relying on alerts and check transport/routing failures in logs. A final-alert delivery failure is retried before automatic retirement. Certificate history remains available independently of the active monitor list.