SSL, TLS and HSTS Header Check: What the Padlock Really Guarantees

The padlock icon in the address bar says one thing: the traffic between your browser and the server is encrypted. Someone sitting on the network in between can't read the content of the page you open, the form you fill in or the password you send, and can't alter it in transit.

The list of things the padlock doesn't say is much longer. It doesn't show that the company behind the site actually exists, that it will ship your order, that it won't sell your data to third parties or that the page is free of malicious code. Because domain-validated certificates can be obtained in minutes and automatically, fake stores and phishing pages display the same padlock with ease. The padlock answers the question "is this line being eavesdropped on?", not "is this site honest?".

This distinction is the starting point of a technical audit, because most HTTPS work is treated as finished the moment the padlock appears. Yet three separate questions still need checking: which protocol version the encryption uses, whether the rule persists in the browser and whether the resources inside the page travel over the same encrypted line.

Are SSL and TLS the same thing?

SSL (Secure Sockets Layer) and TLS (Transport Layer Security) are protocols that encrypt the connection between the browser and the server. They are two generations of the same lineage: SSL came first, and TLS replaced it. Everything sold and talked about today as an "SSL certificate" technically runs on TLS. The name stuck out of commercial habit; the protocol itself was replaced years ago.

This isn't just a matter of wording, because the old versions are no longer in use. The IETF formally deprecated SSL 3.0 on the grounds that it is "not sufficiently secure" and also prohibited falling back to that version. The same body later formally deprecated TLS 1.0 and TLS 1.1 as well. That leaves two versions in production: TLS 1.2 and TLS 1.3.

The takeaway, and the one most often overlooked in practice, is this: the certificate and the protocol version are separate things. Buying a more expensive certificate doesn't upgrade your server's TLS version. The certificate proves identity; the protocol version is determined by the server configuration. A site that renews its certificate and declares "security has been updated" may still have TLS 1.0 enabled; these are two completely independent settings.

Where HTTPS really stands in SEO

When Google announced that it had started using HTTPS as a ranking signal, it described the signal's weight in its own words: a very lightweight signal, affecting fewer than 1% of global queries and carrying less weight than other signals such as high-quality content. In the same announcement, it said it might decide to strengthen the signal over time, but it has never since said that the weight was increased.

In practice, this means HTTPS is a threshold, not a lever. If all your competitors already use HTTPS, installing a certificate gives you no relative advantage. Expecting it to move your rankings is a mistake.

The real impact shows up not in the search engine but in the browser. On an unencrypted page, the browser shows the user a "not secure" warning; if there's a form, the warning gets harsher. The behavior of a user who sees that warning matters far more than a marginal difference in rankings. When making the case for HTTPS, the argument "Google likes it" is weak; the argument "users leave without filling in the form" is real.

There's a third consequence as well: HTTPS is now a prerequisite for modern web protocols. Browsers don't establish HTTP/2 or HTTP/3 and QUIC connections without encryption. So a site that stays unencrypted leaves not only security but every speed gain on the table.

Certificate types and free certificates

Certificates fall into three categories by validation level. The difference between them is what the certificate authority vouches for on your behalf.

The last column in the table is the most misunderstood part. There's no difference in encryption among the three types. A connection established with a DV certificate is encrypted just as strongly as one established with an EV certificate. The difference is whose identity is proven behind the padlock, not how secure the line is.

Free certificates fall into the DV box in this table and are no different from a paid DV certificate in terms of encryption. The real differences lie elsewhere: free certificates are usually issued with a shorter validity period and require setting up automatic renewal, they include no commitment about organizational identity, and they offer no enterprise support or warranty coverage. For a blog, a corporate brochure site or a small e-commerce store, a free DV certificate is technically sufficient. In setups that process card data, take part in corporate procurement processes or require a contractual identity commitment, the reason for choosing OV or EV is not encryption but documenting identity.

Validation level doesn't come up at all in Google's basic recommendations for migrating to HTTPS. What it discusses is the certificate's scope: deciding whether you need a single-domain, multi-domain or wildcard certificate, and using a sufficient key length. So the real question when choosing isn't "which level" but "which domains and subdomains does it need to cover".

What is HSTS and which gap does it close?

The standard step after installing a certificate is to send every request arriving over HTTP to its HTTPS counterpart with a permanent redirect. That's the right step, but it leaves a gap: for the redirect to work, an unencrypted request first has to go out onto the network. When a user types the domain into the address bar without a protocol, the first contact is still over HTTP, and that first request is open to eavesdropping or redirection.

HSTS (HTTP Strict Transport Security) is an HTTP response header that instructs the browser: "from now on, connect to this address only over HTTPS." The browser remembers this instruction for a period of time. Even if the user types http:// again, the browser converts the request to HTTPS internally without ever sending it onto the network. This eliminates both the unencrypted first contact and the redirect step.

The mechanism's weakness stems from this very reliance on memory. HSTS only kicks in after the browser has established a secure connection at least once and received the header. If the browser is visiting the site for the first time and loads an unencrypted address at that moment, that first request is still open to network attacks. This is called the first-request problem, and it's the one issue HSTS can't solve on its own.

The technical detail most often overlooked in practice is this: the HSTS header doesn't belong on the redirect response to a request that arrives over HTTP. The header is sent only over HTTPS. Because the response to an unencrypted request already travels over an untrusted channel, a header placed there is meaningless. The correct order is: the unencrypted request is sent to HTTPS with a permanent redirect, the browser makes the new request over HTTPS, and the HSTS header appears in that response.

HSTS header directives

The header consists of three parts, and each does a different job.

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

max-age specifies how long, in seconds, the browser will remember this rule. The counter restarts with every HTTPS response, so on a site that's visited regularly, the period practically never expires. The risk here is one-directional: if you set a wrong value and then want to back out, you can't revert in browsers that have already received the rule until that period expires. That's why, when enabling HSTS for the first time, it's standard practice to start with a short duration instead of writing one year straight away, and to extend it gradually after confirming the configuration works without problems.

includeSubDomains extends the rule to all subdomains of the main domain. It provides real protection against subdomain takeover attempts, but before enabling it you need to verify that every subdomain works over HTTPS. If there's a test, admin panel or API subdomain that's still unencrypted, that address becomes completely inaccessible in the browser the moment this directive is enabled.

preload signals that you are nominating the site to be added to the list built into browsers. When this directive is used, the max-age value must be at least 31536000 seconds (one year) and the includeSubDomains directive must be present.

The preload list and the cost of going back

The preload list is a mechanism built to solve the first-request problem at the root. Chrome embeds in its own source code a list of domains that have a strong HSTS policy and run entirely over HTTPS. Requests to a domain on the list don't go out onto the network unencrypted, even on the first visit. Other major browsers also use their own lists based on Chrome's.

The acceptance requirements for the list are clear: serve a valid certificate; if port 80 is listening, redirect from HTTP to HTTPS on the same host name; serve all subdomains over HTTPS (including www if a DNS record exists); and send an HSTS header on the main domain's HTTPS responses with a max-age of at least one year along with the includeSubDomains and preload directives.

The real weight of the decision lies not in the requirements but in going back. The list's own documentation carries a clear warning on this: inclusion on the list cannot easily be undone. Domains can be removed, but it takes months for the change to reach users through a browser update, and no guarantee can be given for other browsers. The same source says you shouldn't apply unless you're sure you'll sustain HTTPS for the entire site and all subdomains over the long term. Listing covers all subdomains, including internal subdomains that aren't publicly accessible.

Another recent development calls for even more caution with this decision. Browsers such as Chrome and Safari now automatically upgrade unencrypted navigations to HTTPS, whatever the domain's HSTS policy. According to the list's own explanation, preload produces value precisely in the case where these automatic upgrades fail in the presence of an active attacker. In other words, the marginal protection the mechanism adds has narrowed, while the cost of going back has stayed the same. For high-value targets such as banking, authentication or payment infrastructure, preload is still a defensible choice. For an ordinary corporate site or blog, the balance between gain and risk usually favors not applying.

One more warning: when a certificate error occurs on a domain with HSTS enabled, the browser doesn't offer the user a "proceed anyway" option. A warning that can normally be clicked through turns into a hard access block under HSTS. An expired certificate or a failed renewal therefore means a direct outage on sites that use HSTS.

The mixed content problem

Mixed content means loading an unencrypted resource inside a page served over HTTPS. The page itself arrives encrypted, but an image, script or stylesheet inside it is requested from an HTTP address. The result is that encryption is broken for the page as a whole.

Most Turkish-language sources still explain this topic with the "active" versus "passive" mixed content distinction. That terminology belongs to an older version of the specification. The current classification has two categories: upgradable content and blockable content. Browsers automatically upgrade requests for upgradable content from HTTP to HTTPS and block requests for blockable content outright. Resources such as images, video and audio, which the old framework considered "optionally blockable", formed the core of the upgradable set; newly added file types are expected to be treated as blockable.

The practical consequence of this change is that the old assumption no longer holds. The approach "images are shown anyway, so the mixed content warning doesn't matter" is wrong: the browser tries to upgrade that request to HTTPS, and if the upgrade fails, the resource doesn't load at all. So an image path left unencrypted today means a missing image. On the script or stylesheet side, blocking leads directly to the page not working.

You don't need a separate tool for detection. The browser's developer console prints warnings for both upgraded and blocked mixed content. Opening the page and watching the console shows directly which resources have the problem. Common sources are absolute HTTP addresses embedded in template files, old content links written to the database and third-party embeds.

How to run the check

The audit isn't about looking at the padlock; it's about checking each layer separately, in order. The order matters, because if a lower layer is broken, fixing the one above it is pointless.

1. The certificate itself. Click the padlock in the browser and open the certificate details. Check three things: does the certificate cover this domain, when does it expire and is the chain complete? You can't assume these three are correct just because the padlock appears, because browsers can fill in some gaps from their own cache.
2. Protocol version. Check which TLS versions are enabled on the server. The goal is to have TLS 1.2 and TLS 1.3 enabled and older versions disabled. This setting is independent of the certificate and lives in the server configuration.
3. Redirect. When you open the domain with http://, it should go to its HTTPS counterpart in a single step. Every extra step in between adds latency and extends the time spent unencrypted. Test both the www and non-www versions separately.
4. Header check. Look for the HSTS header only in the HTTPS response. The absence of the header on the redirect response for the unencrypted address isn't an error; it's the correct behavior. A simple request is enough to see the response headers:

   curl -I https://example.com

   Check the strict-transport-security line in the response and the directives in it.
5. Mixed content. Browse the main templates, form pages and pages with embedded content with the developer console open. Replace the address of every resource that triggers a warning with its HTTPS counterpart.
6. Layer ownership. If there's a CDN layer in front, clarify who adds the header. Encryption between the CDN and the server is set up separately, and if the wrong mode is chosen there, the visitor sees the padlock while the leg between the CDN and the server stays unencrypted. Also, if the header is added both on the origin server and on the CDN side, the response ends up with a duplicate header.

If the browser shows a warning, the warning's code tells you directly where the problem is.

The third row is a particularly insidious error. A missing intermediate certificate often goes unnoticed in desktop browsers, because the browser can fill in the missing link from previous visits. That's why the same site can throw errors in mobile browsers, in-app browsers and search engine bots. "It opens for me" proves nothing with this error.

Common configuration mistakes

• Putting the header on the wrong response. Adding the HSTS header to an unencrypted response or a redirect response does nothing. The header must be on the HTTPS response.
• The header dropping off on error pages. In some server software, the header directive applies only to certain response codes by default. In that case, the HSTS header disappears on error responses such as 404 and 500. The option in the server configuration that applies the header to all responses must be enabled.
• Expanding the scope without taking stock of subdomains. Before enabling includeSubDomains, all subdomains need to be listed and the HTTPS status of each verified one by one.
• Enabling preload as an experiment. The preload directive is a formal request, and once the listing process starts, the timeline for going back is out of your control.
• Not automating certificate renewal. With short-lived certificates, manual renewal will be forgotten sooner or later. With HSTS enabled, the cost of that forgetfulness isn't a warning but a direct outage.

What HTTPS doesn't solve

This brings us back to the distinction we started with. HTTPS protects transport, not content. Encryption keeps data from being read or altered while it travels from point A to point B. It has nothing to say about what sits on the server itself.

In concrete terms: when someone who has gained unauthorized access to your site plants hidden links or redirects on your pages, all of them reach visitors through your valid certificate and with a flawless padlock icon. In attacks such as hacklink injection, the browser gives no warning, because technically there's no encryption problem. The malicious content is carried over your own secure line.

The padlock, the certificate, the TLS version and the HSTS header are therefore not the whole of security but an audit of the transport layer. Setting up this layer correctly is necessary, but without server access control, software updates and file integrity monitoring, it isn't enough. The padlock in the address bar only tells you the road is safe, not that the door of the house at the end of the road is locked.