Proactive SSL Monitoring

Know when your SSL Certificate Expiration is due, across every endpoint you configure to watch.

How do you stay on top of SSL/TLS certificate expiration across your entire infrastructure?

SSL certificate monitoring covers more than just expiration dates. A complete expiration monitoring and HTTPS monitoring setup tracks certificate validity, protocol health, revocation status, and name validation across web servers, internal services, APIs, and any TCP/IP endpoint you add to PRTG. PRTG watches all of this on a scheduled basis and alerts your team before certificate issues reach users. It works across external and internal environments, including connections on non-standard ports, and complements broader website monitoring and uptime monitoring without requiring a separate tool for each use case.

Download PRTG Trial

PRTG is compatible with all major vendors, products, and systems

What PRTG's SSL Monitoring Covers For You

Always Know What Is Expiring and When

Systematic SSL certificate expiry tracking keeps your services running and your users unaffected. Automated monitoring replaces spreadsheets and calendar reminders with configurable thresholds that alert the right person at the right time. Consistent certificate visibility protects user experience directly. PRTG's alerting means your team knows weeks ahead, not after the fact. Alerts are based on thresholds you define: warn at 30 days, escalate at 7, or whatever fits your renewal process, with all monitored certificates visible in one dashboard covering external sites, internal services, APIs, and non-standard ports.

Configurable alert thresholds: warn at 30 days, escalate at 7, or set whatever fits your renewal cycle
Notifications via email, SMS, push, and webhooks (Slack and Microsoft Teams work via HTTP action)
Coverage across external sites, internal services, APIs, and non-standard ports
One dashboard for all monitored endpoints: current status and days remaining
Works for annual, 90-day, or shorter cert validity windows

Certificate Health Goes Beyond Expiry Dates

Expiration gets most of the attention, but it's not the only way a certificate causes problems. Catching a revoked cert, a name mismatch after a server rename, or a self-signed certificate on an internal service early gives you a specific signal to act on rather than a generic connection failure to trace back. PRTG checks multiple health dimensions per endpoint simultaneously: revocation status, name validation, signing authority, and public key strength. That level of detail speeds up troubleshooting and catches problems that would slip through if you're only watching expiration.

Revocation status: know if a certificate has been revoked before it breaks a service
Name validation: detects mismatches between certificate names and the actual host address
Signed By: shows whether the certificate is self-signed or trusted as a root Certificate Authority
Public key strength: monitors key length as part of overall certificate posture

Check Which TLS Versions Are Active Per Port

A clean TLS migration means confirming that only the protocol versions you want are still active across every port. Scheduled checks across your environment show you exactly which devices accept SSLv3, TLS 1.0, or TLS 1.1, so you can verify compliance proactively. PRTG runs scheduled protocol checks per device, per port, and shows you exactly which SSL/TLS versions are accepted or denied across your environment. You define the policy and PRTG alerts you when something drifts from it on the next scheduled check. No separate scanner needed for that.

Per-port protocol status: see which SSL/TLS versions are accepted or denied on each device
Set your own compliance baseline: define what "acceptable" means for your environment
Alerts when a port drifts from your defined protocol policy, detected on the next scheduled scan
Automated checks at regular intervals, not a one-off audit you schedule when you remember to

See Why IT Professionals Trust PRTG

Start monitoring your infrastructure in minutes. No professional services, no complex configuration, no risk.

Free download

PRODUCT OVERVIEW

Adapt Your Alert Thresholds as Lifetimes Shrink

Certificate validity periods are getting shorter. Google is moving toward 90-day maximums for public TLS certificates, and proposals currently in progress would reduce that further to 47 days by 2029. A monitoring setup built around annual renewals doesn't translate directly to that cadence, but adjusting alert thresholds in PRTG is a one-setting change. The actual renewal happens in whatever workflow you already use (manual, ACME-based, or a dedicated CLM tool). Nothing in that process needs to change.

Fully configurable thresholds: adjust lead time as cert lifetimes get shorter
No manual tracking to maintain: monitoring runs on a schedule, independent of renewal cycles
PRTG handles visibility and alerting; renewal happens in your existing workflow (ACME, manual, CLM)
One threshold setting change when validity windows shift, no infrastructure rework

How PRTG Monitors SSL/TLS Certificates

PRTG uses two dedicated sensor types for SSL/TLS monitoring, each serving a distinct purpose. Both connect to specified endpoints via TCP/IP at configurable scan intervals.

SSL Certificate Sensor

The SSL Certificate sensor connects to a specified host and port (443 by default, configurable for any TCP/IP port) and performs an SSL/TLS handshake to retrieve and inspect the certificate. It exposes monitoring channels for Days to Expiration, Public Key Length, Public Key Strength, Revocation Status, Signed By, and Certificate Name Validation. The Days to Expiration channel supports upper and lower limit thresholds, so you define exactly when PRTG transitions to Warning or Error status. For environments where multiple domains share a single endpoint, the Virtual Host field enables SNI-based targeting so PRTG retrieves the correct certificate.

NOTE: The SSL/TLS Certificate Sensor is currently available as a BETA variant alongside the stable sensor. It covers the same core functionality with an updated monitoring engine and some differences in how it handles the TLS handshake. As a BETA sensor, settings and behavior are still subject to change, and not all functions may work as expected in every environment.

SSL Security Check Sensor

The SSL Security Check sensor probes a specified TCP/IP port by attempting connections using each SSL/TLS protocol version in sequence: SSLv3, TLS 1.0, TLS 1.1, TLS 1.2, and TLS 1.3. For each version, it reports whether the connection was accepted or denied. PRTG's lookup system then assigns a sensor state: Up, Warning, or Error. Both this sensor and its BETA variant cover protocol acceptance checks only. Cipher-suite inspection requires a separate scanner.

NOTE: The SSL/TLS Security Check Sensor (BETA) provides an updated version of this functionality with a revised monitoring engine and adds configurable per-protocol expectations. You can mark TLS 1.0 as Warning rather than Error during a phased deprecation, for example, until you're ready to enforce the change. Both the stable and BETA variants are scoped to protocol acceptance checks only. As a BETA sensor, settings and behavior are still subject to change, and not all functions may work as expected in every environment.

Alert & Notification Delivery

When a sensor crosses a configured threshold (a cert approaching expiry, a revocation, or a protocol version that shouldn't be active), PRTG sends a notification via your configured method: email, SMS, push, or HTTP action. Slack and Microsoft Teams alerts work via webhook-based HTTP actions: configure an incoming webhook URL in the respective platform, then set up an HTTP action in PRTG to post to it. Escalation policies and notification delays are configurable to control alert timing and avoid unnecessary noise for transient sensor states. For teams routing alerts into external systems, HTTP action notifications support JSON payloads. That means you can connect to most ticketing systems or custom tools without much wiring.

Reportings

Certificate status and protocol health from all configured SSL sensors appear in standard PRTG sensor views and can be included in custom dashboard widgets. The Days to Expiration channel produces a numeric value that trends over time. Teams get a running view of which certificates are approaching renewal across the monitored environment. Scheduled reports can include SSL sensor data alongside uptime checks and other infrastructure metrics, and PRTG's device and group structure lets you organize sensors by site, environment, or service type. For teams tracking website performance and broader service health, SSL monitoring data sits alongside network and server metrics in the same platform.

free downLoad

SSL Certificate Monitoring: With and Without PRTG

Area	Without a monitoring tool Without a monitoring tool	With PRTG With PRTG
Certificate expiration	Without a monitoring tool Spreadsheet or calendar reminders, maintained manually	With PRTG Threshold-based alerts, automatically checked per endpoint on a set schedule
TLS protocol status per port	Without a monitoring tool Periodic manual checks or one-off scanner runs	With PRTG Automated per-port monitoring on a schedule, SSLv3 through TLS 1.3
Revocation, name match, Signed By	Without a monitoring tool No visibility until something breaks	With PRTG Monitored across multiple health channels simultaneously
Alert delivery	Without a monitoring tool Reactive: discovered by users or helpdesk	With PRTG Proactive via email, SMS, push, and webhooks (Slack/Teams via HTTP action) before expiry
Uptime checks	Without a monitoring tool No structured endpoint availability tracking	With PRTG SSL sensors run on a defined schedule, providing regular uptime checks per endpoint
Environment coverage	Without a monitoring tool Hard to maintain consistently across internal and external	With PRTG Deployable across public sites, internal services, and non-standard ports

free downLoad

“We strive to equip our systems with state-of-the-art technology to safeguard our educational practices for the future. Part of this includes ensuring that all our systems run smoothly at all times. On any given day, we rarely have time to keep an eye on all our systems. We therefore decided to monitor our school’s IT environment with a centralized network monitoring tool.”

Stefan Roschewitz, IT administrator

BBS Holzminden

With PRTG, we are now more proactive and have improved the quality of our services. Now, we have everything measured: power, air conditioning, tanks, surveillance cameras (CCTV), processors, memories, disks, switches, bandwidth, and network traffic. We can see what is happening and act before any problem arises.

Esbin Saúl Lázaro García, IT Infrastructure and Security Engineer

Hospital El Pilar

The reactivity, know-how, and technical solutions of Paessler support are outstanding in every situation. For me, no monitoring tool compares to PRTG.

Andreas Reimann, Senior Networking Communication Architect

Zurich Airport

Paessler PRTG Network Monitor licenses & pricing

Choose the PRTG Network Monitor subscription that's best for you.

License Name	Price	License Details	Get started	Pricing Details
PRTG 500	^$200	per month paid annually	Buy now Buy now	Enough to monitor multiple aspects of 50 devices
PRTG 1000	^$358	per month paid annually	Buy now Buy now	Enough to monitor multiple aspects of 100 devices
PRTG 2500	^$742	per month paid annually	Buy now Buy now	Enough to monitor multiple aspects of 250 devices
PRTG 5000	^$1,300	per month paid annually	Buy now Buy now	Enough to monitor multiple aspects of 500 devices
PRTG 10000	^$1,642	per month paid annually	Buy now Buy now	Enough to monitor multiple aspects of 1000 devices

Over 100,000 Customers Worldwide Love Paessler

SSL Monitoring: Frequently Asked Questions

What does SSL certificate monitoring actually check, beyond just the expiry date?

Good SSL certificate monitoring goes well beyond tracking expiration dates. PRTG's SSL Certificate sensor checks certificate validity across several dimensions: revocation status, whether the certificate name matches the host address or SNI, whether the certificate is self-signed or trusted as a root authority (Signed By channel), and public key length and strength. Each is a separate monitoring channel with its own status, so you get specific information rather than a generic connection error to dig through.

How far in advance can PRTG alert me before a certificate expires?

You define the lead time. PRTG tracks days to expiration as a numeric channel and you set warning and error thresholds at whatever values fit your renewal process. A typical setup might warn at 30 days and escalate at 7, but there's no fixed value. If you're working with 90-day certificates, earlier thresholds make more sense. Notifications go out as soon as the sensor crosses a threshold on its next scheduled check, via email, SMS, push, or any other configured method.

Does PRTG monitor SSL certificates on internal services and non-standard ports, not just public websites?

Yes. The SSL Certificate sensor connects to any TCP/IP port, not just port 443. You configure the host and port per sensor, which means you can monitor certificates on internal web services, APIs, mail servers, management interfaces, and any other TLS endpoint, regardless of whether it's internet-facing. Each endpoint requires its own sensor, but there's no restriction on service type or network location.

What's the difference between the SSL Certificate sensor and the SSL Security Check sensor?

They cover different use cases. The SSL Certificate sensor retrieves the certificate from a connection and checks its health: expiration, revocation status, name validation, Signed By status, and key strength. The SSL Security Check sensor doesn't inspect the certificate itself; it tests which SSL/TLS protocol versions a given port accepts or denies. Use the SSL Certificate sensor when you want to monitor certificate validity and health. Use the SSL Security Check sensor when you want to know whether outdated or insecure protocols are still active on a port. Both sensors have BETA variants available in PRTG with updated monitoring engines.

Can PRTG monitor wildcard and multi-domain (SAN) certificates correctly?

Yes, for both, but name validation requires active configuration in the sensor settings. By default, the SSL Certificate sensor does not compare the certificate name against the device address or SNI. When you enable name validation, you can choose to validate against the Common Name (CN) only, or against both the CN and Subject Alternative Names (SANs). For multi-domain and wildcard certificates, selecting the CN and SAN option is the appropriate choice. For servers using SNI with multiple website certificates, configuring the Virtual Host field ensures PRTG retrieves the intended certificate rather than the default one returned for that IP. DNS-based name resolution applies normally as part of the connection process.

Can PRTG send SSL certificate alerts to tools like Slack, Microsoft Teams, or external systems via API?

Yes, though through HTTP action notifications rather than native integrations. Slack and Microsoft Teams both support incoming webhooks, and PRTG's HTTP action notification type can post to those webhook URLs when a sensor changes state. For external systems and custom workflows, HTTP action notifications support JSON payloads, making it practical to route alerts into ticketing systems, custom dashboards, or any other tool with an API endpoint. Standard email and SMS notifications are available for any SSL sensor alert as well.