What this check reads, and what it deliberately does not
Two different questions get called certificate checking, and they have almost nothing in common. The first is whether the certificate currently installed on a server is valid for a host name. Answering it requires opening a connection to that server and reading the certificate it presents. The second is whether the domain’s own records make it difficult for somebody else to obtain a certificate for the same name. Answering that requires reading DNS and nothing else.
This page answers the second question. It is the one that can be answered without probing a third party’s infrastructure, and it is the one that catches problems before they become incidents rather than after.
CAA: the list of authorities allowed to issue
A certificate authority authorisation record names the authorities permitted to issue certificates for a name. It is enforced by the authorities themselves rather than by the protocol, which is why it is described as advisory: a conforming authority checks it and refuses to issue for a name that does not list it, and one that does not check it is not stopped by the record.
The gap without it is narrower than it first sounds, because issuing already requires proving control of the domain. What CAA closes is the case where that proof is satisfied by a route the domain owner did not intend — a subdomain delegated to a service that can itself request certificates, or a validation method that is exploitable. Adding a record reduces the number of authorities that can be wrong about your name.
The operational risk is real and worth restating. Publishing a CAA list that omits the authority your own provider uses stops renewals. Because renewal happens weeks or months later, the mistake is invisible at the time it is made, and the symptom is an expiring certificate with no obvious cause. Enumerate every authority in use first, including any a provider uses on its own behalf.
DNSSEC: what the two records together mean
The DS record sits at the parent of the zone and the DNSKEY record inside the zone. When both are published and consistent, a validating resolver can verify that the answers it received were not modified in transit, because the chain from the root down to your zone is signed.
Two states are commonly seen and only one of them is fully informative. A DS record with no matching DNSKEY in the zone means the delegation claims to be signed while the zone does not publish the keys, which is a broken chain and makes the zone unreachable for validating resolvers. Publishing both and keeping them consistent is the working state.
The relationship to certificates is structural. Certificate validation involves following a chain of names, and each of those lookups is a place where an answer could be rewritten if no validating resolver is involved. Signing the delegation removes that opportunity, which is why DNSSEC is often described as strengthening certificate validation even though it is a DNS feature rather than a TLS one.
The warning worth keeping in mind is that a signing failure is worse than never signing. A zone with no DNSSEC is resolved normally everywhere. A zone whose chain is broken is refused by every validating resolver, which converts a signing mistake into a total outage.
The certificate lifetime, computed from two dates
Certificate lifetimes have been getting shorter for years, driven by the authorities themselves rather than by any single vendor’s policy. A fixed yearly renewal reminder that was safe when lifetimes were measured in years stops being safe as they shorten, which is the practical reason this part of the tool exists.
Paste the validity dates from a certificate you already have and the report computes the remaining days and the total window length. The arithmetic is a subtraction, and the report says so — there is no heuristic and no model. What it gives you is the number to plan a renewal against, expressed from dates you obtained rather than from a date the tool guessed.
What this page does not tell you
It does not read the certificate installed on any host, so it cannot tell you whether that certificate is valid, whether the chain is complete, whether the host name matches, or whether the server supports a current protocol version. It cannot tell you whether a certificate is about to expire on a server; it can only compute the remaining time from dates you supply.
It does not verify that the authorities listed in a CAA record are the ones that will actually be used. It reads what is published and reports it, which is exactly what an authority does — and the same limitation applies to both.
It does not test whether the site is reachable, whether it redirects correctly, or whether its responses are configured safely. The header audit on the HTTP header check covers the response configuration, and the reason the site cannot be loaded at all is more often a routing or resolution question — the network guide sets out the order to work through. If names resolve but connections fail, checking the certificate authority list is the wrong first step, and the DNS lookup page is a better one.