Connection Findings
A check has to reach the service and complete a TLS handshake before it can read the certificate. These findings say why it couldn't. Only the earliest failure on each address is reported (see how findings work), and the finding names the addresses it happened on.
While a connection finding is open, the checks that need a certificate (expiration, hostname, chain of trust and the others) show Not checked on the report. The CAA check only needs the DNS lookup, so it still runs.
To confirm any fix on this page, click Check Now on the monitor's page.
CERT_NET01: Certificate couldn't be read
Key: CERT_NET01 · Label: Certificate Not Read · Severity: Error · Can be dismissed: No
What it means: the check connected, but no certificate could be retrieved or read. This finding is only reported on its own when nothing more specific explains it; a timeout or a failed handshake on the same address is reported instead.
Why it matters: clients connecting to this address can't get a usable certificate either, so secure connections fail.
How to fix it: check that the service is running and serving a certificate on this port, and look at the server's TLS settings and error log. A server that has TLS turned off on this port, or a certificate file it can't load, is the usual cause.
How to confirm: openssl s_client -connect example.com:443 -servername example.com should print the certificate chain. For a STARTTLS service add the protocol, for example -starttls smtp on port 25.
CERT_NET02: Check couldn't connect (internal error)
Key: CERT_NET02 · Label: Network Failure · Severity: Error · Can be dismissed: No
What it means: an internal error on our side stopped the check from connecting to the service.
Why it matters: the certificate wasn't checked on this run. It says nothing about your service.
How to fix it: nothing is needed on your side; it's usually gone by the next check. If it keeps happening, open a support case.
CERT_NET03: Connection to the service failed
Key: CERT_NET03 · Label: Network Failure · Severity: Error · Can be dismissed: No
What it means: the connection couldn't be made: the host may be down, or the port closed or blocked.
Why it matters: if the check can't connect, your users may not be able to either.
How to fix it: check that the service is running and listening on this port, and that your firewall allows connections from our check points. For a service that isn't reachable from the internet, use a monitoring agent.
How to confirm: nc -vz example.com 443 (or the monitor's port) from outside your network should connect.
CERT_NET04: Connection to the service timed out
Key: CERT_NET04 · Label: Network Timeout · Severity: Error · Can be dismissed: No
What it means: the connection timed out: the service is unreachable or too slow to answer.
Why it matters: a timeout usually means the service is unreachable for everyone on that path, not just for the check.
How to fix it: check that the host is up and the port is open to our check points. A firewall that drops connections silently, rather than refusing them, causes timeouts.
How to confirm: nc -vz -w 10 example.com 443 from outside your network should connect within a few seconds.
CERT_NET05: STARTTLS upgrade failed
Key: CERT_NET05 · Label: STARTTLS Failure · Severity: Error · Can be dismissed: No
What it means: the service accepted the connection, but the upgrade to TLS with STARTTLS failed. The service may not offer STARTTLS on this port.
Why it matters: clients that require encryption can't connect securely, and clients that don't may fall back to sending data in clear text.
How to fix it: check that STARTTLS is enabled on the service, or monitor the port that uses TLS directly (such as 465 for SMTP or 993 for IMAP) with the matching protocol. See what are monitors for the protocols and their ports.
How to confirm: openssl s_client -connect mail.example.com:25 -starttls smtp (or imap, pop3, ftp, ldap) should complete the handshake and print the certificate.
CERT_NET06: TLS handshake failed
Key: CERT_NET06 · Label: SSL Failure · Severity: Error · Can be dismissed: No
What it means: the TLS handshake failed: the server and the check couldn't agree on a protocol version or cipher, or the server is misconfigured.
Why it matters: current clients will fail the same handshake.
How to fix it: check that the server supports TLS 1.2 or 1.3 with current ciphers, and that it serves a certificate on this port. A server that only offers old protocols (SSL 3.0, TLS 1.0 or 1.1) fails modern clients.
How to confirm: openssl s_client -connect example.com:443 -servername example.com -tls1_2 (and -tls1_3) should complete the handshake.
CERT_NET07: Hostname doesn't resolve in DNS
Key: CERT_NET07 · Label: DNS Failure · Severity: Error · Can be dismissed: No
What it means: the hostname couldn't be resolved in DNS, so there was no address to connect to.
Why it matters: clients can't find the service at all.
How to fix it: check the hostname's spelling on the monitor's Settings tab, and that its A or AAAA record exists in public DNS.
How to confirm: dig +short A example.com and dig +short AAAA example.com should return the service's addresses.
CERT_NET08: Hostname resolves to a private address
Key: CERT_NET08 · Label: Private IP Blocked · Severity: Error · Can be dismissed: No
What it means: the hostname resolves to a private IP address (such as 10.0.0.5 or 192.168.1.20), which our check points don't connect to.
Why it matters: the certificate isn't being checked. Checks from our platform never connect to private or reserved addresses.
How to fix it: to check a service on a private network, deploy a monitoring agent inside that network and assign it to the monitor's profile. If the hostname should resolve to a public address, correct its DNS record.
CERT_NET09: Mail server rejected the connection
Key: CERT_NET09 · Label: Connection Rejected · Severity: Error · Can be dismissed: No
What it means: the mail server answered with an error instead of a greeting, for example because it's throttling or blocking connections, so the check couldn't reach the certificate.
Why it matters: this is often temporary (rate limiting or greylisting) and clears by the next check. If it persists, other senders may be turned away too.
How to fix it: check the mail server's logs and connection limits, and that it accepts connections from our check points.