How to Check Website Security Online, and What 68 Sites Showed on the Basics

This post contains affiliate links. If you buy something through one of them, Veravix may earn a commission at no extra cost to you.

A basic website security check is a short list: does the site force HTTPS, is the certificate healthy, which TLS version does it speak, and did the owner publish three small records that most sites skip. I ran those checks on 68 well-known sites on 31 October 2026 and on the two sites I run, and the results were more uneven than I expected.

Almost everything passed the parts people worry about. All 68 negotiated TLS 1.3, 67 redirected plain HTTP to HTTPS, and no certificate had under 30 days left. The three optional records, security.txt, a CAA record and DNSSEC, were a different story, and none of the free online checkers I looked at say much about them.

What a basic security check covers

Search for this topic and you get tool lists: Sucuri SiteCheck, Mozilla Observatory, SSL Labs, VirusTotal and similar. They are worth running, but they bundle several different questions into one grade. Pulled apart, the basics are six separate checks, and each one can be done from a terminal in under a minute.

1. HTTP redirects to HTTPS. A visitor who types the plain address should be sent to the secure one.
2. The certificate is valid and not about to expire. Issuer, expiry date and total lifetime.
3. The TLS version. TLS 1.3 is the current one; 1.2 is still common.
4. A security.txt file. A small text file at /.well-known/security.txt that tells a researcher who to contact about a flaw.
5. A CAA record. A DNS record naming which certificate authorities may issue certificates for the domain.
6. DNSSEC. A signed DNS zone, shown by a DS record at the parent.

The first three are about the connection. The last three are about what the owner chose to publish. They are the ones that separate a site someone looks after from one that merely works.

How I ran the checks

I used the same list of sites as my earlier surveys on security headers and remote malware scans: 69 well-known domains, from WordPress and hosting companies to news sites and online shops. One, hismile.com, would not resolve from my machine, so 68 are counted. Each check was a single request or lookup, not a scan.

• HTTP redirect: a plain http:// request, redirects not followed, and I read where the first hop pointed.
• Certificate and TLS: a direct TLS connection on port 443, reading the protocol that was negotiated and the certificate dates and issuer.
• security.txt: a request to /.well-known/security.txt, counted only if it returned 200 after redirects, was not an HTML page and contained a Contact: line. I did not check the Expires: field, which the standard also requires, so some files counted here may be out of date.
• CAA and DS records: looked up through Google Public DNS over HTTPS. My first CAA attempt used my local resolver and failed with a connection error on every domain, so I discarded it and reran the lookup.

What the 68 sites showed

Check	Sites passing
HTTP redirects to HTTPS	67 of 68
Negotiated TLS 1.3	68 of 68
Certificate with 30 or more days left	68 of 68
A security.txt with a Contact line	29 of 68
A CAA record	31 of 68
A DNSSEC DS record	10 of 68

The one site that did not redirect, bluehost.com, answered my script with a 403 on plain HTTP. That looks like bot protection rather than a missing redirect, so I would not read it as a failure. Everything else on the connection side was clean.

Only 5 of the 68 had all three optional records. Twenty-four had none of them. The records tend to travel together: 18 of the 29 sites with a security.txt also had a CAA record, against 13 of the 39 without one, which fits the idea that these are things a security team adds on purpose.

The certificate lifetime finding

The most useful result came from looking at how long each certificate lasts in total, not just when it expires. Of the 68, 49 had certificates valid for 100 days or less (mostly Let’s Encrypt and Google Trust Services, at 90 days), 10 sat between 156 and 199 days, and 9 were valid for 365 days or more.

That split lines up with a rule change. The CA/Browser Forum, the body that sets the rules certificate authorities follow, voted to shorten the maximum lifetime of public TLS certificates in steps: 200 days from 15 March 2026, 100 days from 15 March 2027 and 47 days from 15 March 2029. The limit applies to certificates issued after each date, and older certificates keep their original term.

I worked out each certificate’s issue date from its dates. All nine long-lived certificates were issued between 17 December 2025 and 16 February 2026, before the 200-day limit. Every one of the ten mid-length certificates was issued later, and none runs past 199 days. Nothing in my sample was issued after 15 March 2026 with a longer lifetime.

The practical point for a site owner is that certificates are about to be replaced more often, so renewal has to run by itself. A calendar reminder is fine at one renewal a year and a trap at four. The shortest remaining time in my sample was 33 days, and the median was 71.

What I found on my own two sites

I ran the same checks on veravix.com and repairpicks.com, and I would rather show them than skip them.

• Both redirect HTTP to HTTPS and negotiate TLS 1.3.
• Both use a 90-day Let’s Encrypt certificate. veravix.com’s expires on 3 December 2026 (33 days left when I checked, the lowest in the whole sample) and repairpicks.com’s on 13 January 2027 (74 days). A Let’s Encrypt certificate is normally renewed automatically well before expiry, and I have not touched either.
• Neither has a security.txt, a CAA record or DNSSEC.

So on the optional three my sites sit with the 24 that have none. I have not added them. A security.txt needs a contact address and a regular expiry date, a CAA record has to list every certificate authority the host might use, and a wrong DS record can take a domain offline, so each one is worth doing deliberately rather than as part of a survey.

How to run each check yourself

These commands work in a terminal on macOS, Linux and Windows with OpenSSL and curl installed. Replace example.com with your domain.

1. Redirect: curl -sI http://example.com/. You want a 301 or 308 and a Location: line that starts with https://.
2. Certificate dates and issuer: openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -dates -issuer. The two dates give you the total lifetime and the expiry.
3. TLS version: the same s_client output prints the protocol on the line starting Protocol. Qualys SSL Labs will also grade the whole configuration if you want more than the version.
4. security.txt: curl -s https://example.com/.well-known/security.txt. Real content has Contact: and Expires: lines. An HTML error page is not a security.txt.
5. CAA: dig CAA example.com +short. An empty answer means any certificate authority may issue.
6. DNSSEC: dig DS example.com +short. An empty answer means the zone is not signed at the parent.

If you would rather click than type, run the domain through Mozilla Observatory for the connection and headers side. For a reputation and malware view, Sucuri SiteCheck gives a remote scan, and I ran it on both sites in my malware scan guide.

What this check does not tell you

• Whether the site is hacked. A perfect connection says nothing about malware in a page. The malware scan guide covers what a remote scan can and cannot see.
• Whether your plugins have known flaws. That is a version lookup, covered in the vulnerability scan guide.
• Which older protocols are still switched on. My script reports what a modern client negotiates, which was TLS 1.3 everywhere. It cannot show that TLS 1.0 or 1.1 are disabled; SSL Labs tests that.
• Whether a security.txt is current. I only checked that a Contact line exists.
• Anything behind a login. Passwords, two-factor settings and admin access need a look from the inside.

Checked for accuracy on 31 October 2026. Connection, certificate, security.txt, CAA and DS results were collected on 31 October 2026 from a single request or lookup per site, so a site behind bot protection can show a result that differs from what a browser sees. The certificate lifetime schedule was checked against published summaries of CA/Browser Forum ballot SC-081v3, and the security.txt fields against the RFC 9116 field list, not against the documents themselves.