TLS certificate is valid

What this means

Passing means the certificate your site presents is one browsers trust, matches the host name a visitor types, and has not expired. Failing means a browser opens your site to a full-page warning instead of your page. Everything else on the grade sits behind this check, because a visitor who sees that warning never reaches the rest.

How we test it

We open a TLS connection to your host, the same handshake a browser does before it sends a request, and read the certificate chain it presents. We pass when the chain is trusted, the name matches your host, and the expiry date is in the future. We fail when any of those is false, including a certificate issued for another name or one that expired yesterday. There is no warn state: a browser either accepts the certificate or it does not.

Why it matters

Browsers block the site outright and every user sees a warning. The warning is not a banner; it is an interstitial that hides your page, and most visitors leave at that point. Search engines and link previews stop fetching the site too, so the damage reaches past the single visit. On a host such as Vercel the certificate is issued and renewed for you, so a failure here almost always means DNS points somewhere else or the domain was never attached to the project.

The fix

The certificate is issued by your host once the domain is attached to the project and DNS points at it. The fix is to make those two facts true and then prove it with one request each.

1. Confirm what the name resolves to. Both the apex and www must answer:

dig +short YOUR_DOMAIN
dig +short www.YOUR_DOMAIN

If either prints nothing, or prints an address that belongs to an old host, fix the DNS record at your registrar so it points at the host that serves the site. Module 0 of the Fix Kit is where the domain and the www or apex choice were made; the host's domain settings show the exact record it expects.

2. Confirm the host has the domain. In Vercel, both YOUR_DOMAIN and www.YOUR_DOMAIN must be added to the project so the host can issue a certificate for each. A domain that is attached but shows a DNS error is waiting on step 1.

3. Read the certificate the site actually presents:

openssl s_client -connect YOUR_DOMAIN:443 -servername YOUR_DOMAIN </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates

Expected: a subject that names your domain, an issuer that is a public certificate authority, and a notAfter date in the future. A subject naming a different host means the request reached the wrong server; go back to step 1.

4. Prove it as a browser would:

curl -s -o /dev/null -w '%{http_code}\n' https://YOUR_DOMAIN
curl -sI https://www.YOUR_DOMAIN | head -1

Expected: 200 from the first command, and 200 or a redirect status from the second. If curl reports a certificate error instead, the chain is still wrong; wait once, up to a few minutes after a DNS change, then run it again. Never wrap this in an open-ended loop.

Then re-run the Securealy check. A deeper runbook for this class is in the Fix Kit, Module 01.

Prompt for your AI

Paste this into the coding agent that built the app.

Run: dig +short YOUR_DOMAIN and then dig +short www.YOUR_DOMAIN. Show me both outputs.
Run: openssl s_client -connect YOUR_DOMAIN:443 -servername YOUR_DOMAIN </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates
Tell me the subject, the issuer and the notAfter date, and whether the subject names YOUR_DOMAIN.
If DNS prints nothing or points at an old host, tell me the exact record the current host expects and stop; I will change it at the registrar.
If the domain is not attached to the hosting project, tell me so and stop; I will add it in the host's domain settings.
Do not wrap any of this in a loop. One request each.
After I confirm the change, run: curl -s -o /dev/null -w '%{http_code}\n' https://YOUR_DOMAIN and show me the output. Expected: 200 with no certificate error.

Copy the prompt