Support & Help Centre

This means Certline could not open a TLS connection to the hostname you typed on port 443. The most common causes are:

• The hostname does not exist (typo, wrong domain).
• The server is not reachable (down, firewalled, or on a closed port).
• The server does not speak TLS on port 443 (it may use a different port, or may not serve HTTPS at all).
• The hostname resolves to an IP that does not accept connections from the Certline backend.

This is a connection failure — it is not a finding about your certificate. If you can reach the site in a browser, the difference may be that your browser uses a different network path (e.g. IPv6 vs IPv4, a different DNS resolver, or a corporate VPN). Check the hostname carefully and try again.

Your certificate is not necessarily broken. "Chain incomplete" means the server sent its leaf certificate but did not send the intermediate certificate that chains it to a trusted root.

Desktop browsers often hide this gap because they cache intermediates from previous visits. Mobile clients, fresh browser profiles, and programmatic TLS clients (curl, fetch, your own code) do not have that cache — they will fail to validate the chain until the intermediate is found elsewhere.

This is the exact scenario Certline exists to catch. Most certificate-checking tools only look at the expiry date; they miss the missing intermediate. If your report shows an incomplete chain, reconfigure your web server to send the intermediate certificate alongside the leaf. Many hosting control panels have a "CA bundle" or "intermediate certificate" setting for this.

No. Certline is a diagnostic tool, not a monitoring service. It checks the hostname you type at the moment you type it. There are no scheduled re-checks, no email alerts, no reminders, and no dashboards.

If you need monitoring, you will need a separate service. Certline's purpose is to give you a detailed look at what a server presents right now — so you can debug a broken chain, confirm a renewal took effect, or check what a server you inherited is actually serving.

Subdomains: Yes. Any public hostname works — api.example.com, mail.example.org, sub.domain.co.uk. Certline checks the hostname you type and reports the SANs the certificate covers (which may include additional hostnames).

Non-standard ports: No. Certline connects on port 443 (the standard HTTPS port). There is currently no way to specify a different port. This is a known limitation.

IP addresses: Yes, in the sense that you can type a bare IP address. Certline will attempt a TLS connection to it. However, the certificate presented by an IP-based server often contains a hostname in its SANs, not the IP address — the report will show what was sent, which may not match what you expect.

Certline never scans ranges, enumerates subdomains, or probes beyond the single hostname you type.

If a field shows "not provided", it means the server's certificate did not include that field. Certline reports exactly what the server sent. It never infers, fills in, or guesses a missing value.

For example, a self-signed certificate may omit the issuer subject or use an unusual subject format. Some certificates omit subject alternative names entirely (though modern browsers will reject them for that reason). The report shows the gap, not a best guess.

It is possible both are correct. Browsers compensate for incomplete server configurations in ways that other clients do not. The most common example is the missing intermediate (see the chain question). Desktop Chrome and Firefox cache intermediates from earlier connections, so they appear to load fine. Mobile Safari and a fresh Firefox profile will fail.

Certline reports what the server actually sent over the wire — not what your browser cached from a previous visit. If Certline says the chain is incomplete, the server is missing an intermediate, even if your browser shows the site working. This is the gap that makes the certline product useful: the expiry date alone is not enough.