Overview
HTTPS protects an HTTP connection using TLS. It helps a client authenticate the requested server and protects traffic from being read or altered along that connection. This protection does not establish that the application is trustworthy, that its accounts are well managed or that its content is harmless. A fraudulent site can also have a valid certificate. Treat transport security as one necessary layer of website operation.
Use TLS 1.2 as the minimum supported protocol and prefer TLS 1.3 for capable clients. This baseline follows NIST SP 800-52 Rev. 2, which addresses federal TLS deployments. Enable TLS 1.3 alongside TLS 1.2, check older business clients, then disable TLS 1.0 and 1.1 through your hosting configuration. Keep certificate verification enabled. Assign the hosting owner to certificates and redirects, and the application or edge owner to response headers.
Understand the TLS connection and certificate
During a normal authenticated TLS connection, the client validates the certificate chain against its trust store, checks dates and matches the requested hostname. A certificate for example.com does not necessarily cover www.example.com. A wildcard for *.example.com does not cover the apex example.com or multiple nested labels. Inventory the names people actually use rather than relying on the address you happen to test first.
Different clients can see different behavior because their trust stores, protocol capabilities and network routes differ. One successful handshake demonstrates the behavior of that client and connection at that time. It does not enumerate supported ciphers, establish revocation status across all clients or prove that obsolete protocols have been disabled. Those are additional assessment questions requiring an agreed method and scope.
Certificate expiry needs operational context. Short-lived certificates are often renewed automatically, so a short remaining lifetime is not proof of broken renewal. The practical questions are who owns the automation, whether failures trigger alerts and whether recovery is documented. Verify the served certificate after renewal; updating a certificate file does not guarantee every edge node has started presenting it.
Redirect the ordinary HTTP entry point
Redirect HTTP to HTTPS with a permanent 301 or 308 on the same host before enabling HSTS. For example, http://example.com/ should first reach https://example.com/; http://www.example.com/ should first reach https://www.example.com/. Apply the upgrade to paths as well as the root, preserving the path and query. If you consolidate www onto the apex, do that after the HTTPS upgrade. A 308 preserves the request method and body; verify application behavior before selecting the status.
A redirect upgrades a request only after the initial HTTP exchange. It does not protect that initial exchange against an active network attacker. HSTS addresses subsequent browser behavior after a valid HTTPS response has established the instruction. Browser preload lists can address first contact for listed names, but preload is a separate operational commitment and should not be adopted just to improve a checklist.
Root-page behavior does not prove that every path behaves identically. Applications sometimes handle old URLs, localized routes or file downloads through different infrastructure. A broader review should use an agreed inventory and representative paths. Do not send credentials or sensitive query parameters over HTTP while checking a redirect, and never disable certificate verification to make a test appear successful.
Choose an HSTS rollout that your hosts can support
Strict-Transport-Security is an HTTPS response header defined by RFC 6797. Its max-age directive specifies how long a supporting browser should remember the instruction. A positive lifetime enables the instruction; max-age=0 removes a learned policy for that host. Browsers ignore HSTS received over plain HTTP, so adding it only to the redirect response is insufficient.
Ramp HSTS from max-age=300 to 86400, then 604800, and finally at least one year, max-age=31536000; two years (63072000) is common and is what hstspreload.org recommends. Advance after representative clients and workflows work at each stage; these are suggested rollout steps, not protocol requirements. Start without includeSubDomains. Add it only after every subordinate service, including delegated and internal names, supports HTTPS. Once a browser caches a long policy, restoring HTTP service will not undo that instruction.
Preload is optional and hard to undo. hstspreload.org requires max-age of at least 31536000, includeSubDomains and preload, plus valid HTTPS and the same-host HTTP redirect. HTTPS redirects must also serve HSTS. The preload token alone does not add a domain to browser lists; submission and acceptance are separate. Removal depends on browser-list updates reaching users. Keep HTTPS available during recovery: max-age=0 clears a learned policy only when a browser receives it over valid HTTPS and does not immediately remove a preloaded entry.
HTTP response for http://example.com/:
HTTP/1.1 308 Permanent Redirect
Location: https://example.com/
Initial HTTPS response for https://example.com/:
Strict-Transport-Security: max-age=300
After a successful ramp, on HTTPS responses:
Strict-Transport-Security: max-age=31536000
Only after all subdomains are ready and preload is approved:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preloadWhat to check
Record the public entry points, redirect destination, observation time, certificate names and renewal owner. Check that the root response is representative application content rather than an access challenge or hosting error. A valid TLS connection to an error page is transport evidence; it does not show that the intended application was available or that its headers were observed.
Ask the hosting team how traffic moves through the CDN, load balancer and origin. HTTPS to the edge does not prove encryption or authentication on the edge-to-origin connection. Inspect those settings through authorized configuration access. Keep private configuration records separate from the public report, and avoid disclosing internal hostnames or routing details in a broadly shared remediation summary.
Make changes through a staged release. Confirm redirect behavior, hostname coverage and the header on the public response after deployment. Set a reminder to verify renewal rather than waiting for an expiry alert. Where a change affects subdomains, identify an owner for each dependent service and record approval before extending HSTS inheritance or requesting preload inclusion.
Common mistakes: treating one handshake as a complete TLS audit
A normal client typically negotiates one supported protocol and cipher. Reporting that result as proof that all older options are disabled overstates the evidence. Likewise, a network timeout is not evidence of an invalid certificate. If authentication fails, preserve the type of failure and investigate with the administrator rather than retrying with an insecure client that ignores trust errors.
Another common mistake is fixing only the canonical hostname while leaving a widely used alternative with a mismatched certificate. The client must authenticate HTTPS before following an HTTPS redirect, so a redirect cannot repair an invalid certificate presented by its source. Check the redirecting name as well as the final destination, and keep certificate provisioning aligned with the published domain inventory.
How the free Meo audit checks this
Meo starts with HTTPS and HTTP root requests at the confirmed apex on ports 80 and 443. It reaches exact www through an in-scope redirect or an HTTPS fallback when no apex HTTPS page was accepted and budget remains. It does not guarantee separate samples from both hosts. It reports HTTPS, HTTP-to-HTTPS redirection and authenticated TLS as separate checks. The client uses a standard TLS 1.2-or-newer connection and does not probe older protocols, alternative chains, cipher suites or revocation. Authentication is never disabled to collect a result.
The accepted served certificate supplies expiry evidence, with attention raised when it expires within 30 days. HSTS is checked on a usable HTTPS HTML root response for a recognized positive max-age. That check does not validate preload readiness or every directive. Missing, challenged or incomplete responses can remain unknown. HSTS contributes to the website-hardening area, while the connection area covers HTTPS, redirects and TLS authentication.
Frequently asked questions
Is SSL the same as TLS?
SSL is older terminology still used in certificate product names. Modern HTTPS uses TLS. Calling a certificate an SSL certificate does not tell you which protocol a client actually negotiated.
Should every domain preload HSTS?
No. Establish one-year HSTS first. Consider preload only when every subdomain supports HTTPS and the team accepts the slow browser-list removal process. Eligibility requires max-age of at least 31536000, includeSubDomains and preload, plus the other hstspreload.org requirements.
Can I ignore a certificate error to inspect the page?
The instant audit does not bypass authentication errors. Ask the hosting owner to review trust, dates and hostname coverage. An insecure retry would change the meaning of the observation and could expose traffic.
Does a redirect fix an invalid HTTPS certificate?
No. The client authenticates the HTTPS source before it can receive its redirect. Provision a certificate valid for the redirecting hostname as well as the destination when both are offered over HTTPS.
Why can HTTPS pass while HSTS is unknown?
TLS authentication can succeed even when the response is an access challenge or unsuitable content. Meo needs a usable HTTPS HTML root sample for the HSTS check, so the evidence requirements differ.
Sources and review dates
Content reviewed against the instant audit’s implemented checks and the references below. This is a content review date, not a new revision date for these standards. Confirm provider-specific settings with the responsible administrator before deployment.