HTTPS, certificates and website legitimacy

Guide Updated 25 October 2026

HTTPS protects the connection to an endpoint authenticated for the requested hostname; it does not establish that the operator is honest or that the page’s claims are true. A valid certificate can belong to a deceptive site. Read connection status, the actual hostname and any content warning as separate pieces of evidence.

What the connection protects

HTTPS uses TLS to protect application data in transit. The current TLS 1.3 specification, RFC 9846, describes protection against eavesdropping, tampering and message forgery; the July 2026 revision replaces RFC 8446¹. Those protections matter when a browser exchanges a page or sends a form, but they concern the channel between endpoints. They do not turn the recipient into a trustworthy business.

In ordinary certificate-based web authentication, the browser checks whether the certificate identity matches the service name it intended to reach. RFC 9525 specifies how application-service identities are represented and verified². The certificate is part of that authentication process, alongside the applicable trust and validation rules. A certificate file’s existence is not itself proof that a particular connection passed those checks.

Think of a correctly protected connection as preventing an unrelated observer on the route from reading or altering the protected exchange. The site receiving the data can still read what you send it. A deceptive form does not need to defeat encryption when it persuades someone to send information directly to the party controlling the form.

An observer on the network path can normally see the requested hostname in Server Name Indication (SNI), unless Encrypted Client Hello (ECH) is successfully used. ECH protects that handshake name, but connection IP addresses and traffic timing remain observable; unencrypted DNS can also reveal the name³¹. Encryption of the page content is not concealment of every connection detail.

The hostname-reading guide addresses the question that comes before connection trust: which hostname did the address actually request? The registrable-domain guide explains a different boundary again. Neither a parsed name nor a registration boundary identifies the human organization you intended to deal with.

A certificate can authenticate the wrong name perfectly

Suppose someone intends to reach accounts.example.test, but a message directs them to accounts-example.test. These are synthetic names, not inspected sites. In the hypothetical, the second name can have its own valid certificate. A browser accepting a certificate for that name would not establish that it represents the service the person had in mind.

The same distinction applies to a misleading subdomain such as accounts.example.test.login.invalid. The useful first question is the complete hostname, not whether a familiar word appears somewhere in the address. A certificate covering the actual requested hostname does not confer ownership of the familiar-looking text inside it. Our lookalike-name guide covers the visual and parsing issues separately.

A name match is not a review of the content behind that name. Keep the conclusion within the evidence available: a certificate and a connection check answer authentication questions, not whether an order will be fulfilled or a login page will use submitted information appropriately. Assess those separate claims with evidence relevant to them.

Chromium’s explanation of its move away from the lock icon makes this boundary explicit: connection security is not website trustworthiness⁴. The important lesson is the distinction, not memorizing an icon that can change between browser versions. A neutral site-controls symbol, a lock or the text https should never be read as a browser’s endorsement of the page’s business claims.

Certificate warnings and deceptive-site warnings ask different questions

A certificate warning concerns the browser’s ability to establish the protected connection under its rules. Mozilla documents separate error categories for expiration, an unknown issuer and a certificate that does not match the requested name⁵. The exact error code matters because those cases point to different evidence. None of them should be dismissed by saying that the site “has SSL.”

A deceptive-site warning instead concerns reported or detected harmful content or behavior. A download warning may concern a file or its reputation. Microsoft describes its site checks and download screening separately⁶. These categories can coexist: an encrypted connection does not prevent a phishing warning, and fixing a certificate issue does not resolve a content classification.

For an owner, retain the warning text and identify the affected object before choosing a response. Certificate deployment records belong in a connection investigation; provider issue details and content history belong in a deceptive-site investigation. The owner warning guide supplies one worksheet that keeps these branches separate without opening a flagged page in an everyday browser.

For a reader encountering a warning, the distinction is not a reason to bypass it. It is a reason not to let an unrelated positive signal cancel it. A statement that a certificate is valid does not answer an allegation about a deceptive form, just as a favorable content reputation does not repair a name mismatch in a connection.

Use Certificate Transparency to inspect issuance history

Certificate Transparency makes certificate issuance available for public monitoring. It helps owners and others detect certificates they did not expect, including possible mistaken or unauthorized issuance⁷. It is an issuance record, not a report of what a website currently serves. A logged certificate may not be the certificate deployed at the time of a visitor’s warning.

An owner can use a CT monitor or search service to look for certificates containing names they control. The CT project’s monitor documentation describes services that observe logs and look for certificates of interest⁸. Search the public certificate records, then compare the results with the organization’s own certificate inventory. There is no need to visit a listed hostname merely to review an issuance entry.

For each relevant record, retain the covered names, issuer, validity interval, serial or fingerprint and the log or monitor reference. Compare those details with approved issuance and renewal records. A wildcard record deserves its own scope note: it is not an inventory of every service that actually exists beneath the name. Multiple entries can also require interpretation before they are counted as separate deployed certificates.

Let’s Encrypt states that it submits every certificate it issues to CT logs⁹. That is a useful provider-specific statement; it should not be expanded into a claim that a particular search interface has complete, instant visibility into every certificate. Record the monitor, query scope and observation time if you maintain an inventory, and leave coverage limitations explicit.

An unfamiliar issuance entry is a reason to investigate authorization and deployment records, not immediate proof of an active attack. Conversely, recognizing an issuer or renewal pattern does not certify the site’s content. Keep the issuance question connected to the certificate owner process and the content question connected to the warning provider’s evidence.

Keep the conclusions separate

For a connection question, ask what hostname was requested and what validation result or error was reported. For an ownership question, compare authenticated names with an independently established service relationship. For a content question, inspect the relevant provider’s stated scope and evidence rather than treating encryption as a reputation score.

This page explains those boundaries; it did not connect to a target, inspect a real certificate or query a certificate inventory. The synthetic address comparisons illustrate how the conclusions differ. An owner using the method needs their own dated records before making a claim about a real service.

Not covered on this page

• A live TLS connection or certificate-chain test.
• Certificate Transparency queries for an actual domain.
• Warning bypasses or changes to browser trust settings.
• A legitimacy verdict for any site or organization.