SSL Certificate Monitoring & Expiry Alerts

SSL monitoring is a scheduled external TLS handshake against your hostnames, checking the certificate that is actually being served: its expiry date, trust chain, hostname coverage, issuer and key strength. Domainyze connects the way a browser does, from outside your network, so it sees what visitors see rather than what your server believes it installed.

Because automation fails silently. An ACME challenge breaks after a DNS or redirect change, a cron job stops on a rebuilt host, a wildcard renews but the load balancer keeps serving the old file, or a CDN edge caches the expired chain. In each case the renewal log looks fine and the served certificate does not. Only an external handshake catches the difference.

No. SSL monitoring is included with Pro and Business, and a free account is never handshaked. Free covers registry monitoring on 5 domains, checked every 12 hours, which is the domain itself rather than the certificate on it. Upgrading adds the handshake, chain and hostname validation, issuer and algorithm change detection, per-subdomain checks, and Slack, Discord and signed-webhook delivery.

The first warning arrives weeks before expiry and the reminders tighten as the date approaches, ending with continuous re-checks once a certificate has actually expired. An alert also fires immediately if the served certificate becomes invalid for any other reason. A successful renewal closes the thread automatically, so you get a resolution notice instead of another round of reminders.

The whole chain. A missing intermediate is one of the most common real-world failures: desktop browsers often fill the gap from cache while mobile clients and API consumers reject the connection outright. We validate the served chain in full and alert when an intermediate disappears or the chain order breaks.

Yes. Each hostname is checked independently, because a wildcard certificate can be valid at the apex and absent on the one subdomain your checkout runs on. SAN coverage is compared against the hostnames you monitor, and a hostname that drops out of the certificate raises an alert.

Yes, and it matters more than it sounds. An unexpected issuer on your domain is one of the clearest signs of a mis-issuance or a hijacked DNS record used to pass a domain-control challenge. We alert on issuer change and read your CAA records so you can restrict issuance to the CAs you actually use.

Yes, and that is the case it is built for. Because the check is external and independent of your server, it catches a failed ACME renewal that your own logs recorded as a success, before a visitor hits a security warning.

An expired certificate, a hostname mismatch, a self-signed certificate, an untrusted root, a broken or incomplete chain, a revoked certificate, a weakened key or signature algorithm, or a protocol downgrade. Each of these is a full outage for some clients while the endpoint still answers 200, which is why an uptime monitor stays green through all of them.

No. Monitoring is an outside-in TLS handshake on port 443: no agent, no credentials, no firewall rule. That is deliberate, because the point is to see the certificate from the client's position rather than the server's.

Yes. TLS certificates are public by nature, so you can watch a vendor's API endpoint, a partner's portal, or a client's site before you take over their hosting.

Most uptime tools check one thing: does the certificate expire soon. Certificate failures are broader than expiry, covering chain gaps, hostname mismatch, weak signature algorithms, protocol downgrades, revocation and unexpected issuers. Each is a full outage for some clients while the endpoint still answers normally.