Most sites that break HTTPS in 2026 do not break because someone forgot to install a certificate. They break because of two quieter problems that hide behind a valid padlock: mixed content, where an HTTPS page loads a resource over plain HTTP, and TLS misconfiguration, where the server still speaks outdated or weak versions of the encryption protocol. Both can sit on a site that looks perfectly secure in a quick glance, and both are increasingly punished by browsers that have spent the last few years tightening the rules. The result is a page that half-works, silently drops images and scripts, or refuses to load at all for some visitors, while the site owner sees nothing wrong on their own machine. This article explains exactly what these two failure modes are, why they are getting stricter in 2026, and how to find and fix each one at the source.
We scan sites for security issues as part of what we do, and mixed content and stale TLS settings are two of the most common things we surface on sites whose owners were certain everything was fine. The pattern is almost always the same: it worked when they migrated to HTTPS, nobody touched the security config again, and the web moved on around them. Let us walk through both problems properly, because understanding why they happen is what stops them coming back.
What is mixed content, and why does it break HTTPS?
Mixed content is what you get when a page delivered securely over HTTPS then asks the browser to fetch something else over insecure HTTP. The top-level document arrived encrypted, but one of its ingredients, an image, a script, a stylesheet, a font, an embedded frame, is referenced with an http:// URL. That single insecure request undermines the security guarantee of the whole page, because anything traveling over plain HTTP can be read or altered in transit by anyone on the network path. The padlock promises a private, tamper-proof connection, and a mixed request quietly breaks that promise.
Browsers sort mixed content into two buckets, and the distinction decides what actually happens to your page. According to MDN's mixed content documentation, mixed content is divided into upgradable content and blockable content: browsers automatically upgrade image, video, and audio requests from HTTP to HTTPS, and block insecure requests for all other resource types. In practice that means a mixed image might get silently rewritten to its HTTPS address and load fine, while a mixed script, stylesheet, or fetch call is simply blocked, and the feature it powered stops working.
The critical thing to understand for 2026 is that even the "passive" category is no longer a gentle warning. According to MDN, when the browser auto-upgrades an image or video request, the remote server either responds over HTTPS or the resource fails to load, with no fallback to HTTP. So if an image exists only at an http:// address and that server does not answer on the secure port, the upgrade fails and the image simply disappears. There is no safety net. The browser tried HTTPS, HTTPS was not there, and the content is gone.
How do I know if my site has mixed content?
You usually will not spot it by eye, which is what makes it dangerous. The reliable signal lives in the browser's developer tools. Open the console on the affected page and you will see explicit messages: a blocked resource produces a warning that the page was loaded over HTTPS but requested an insecure resource, and that the request has been blocked. An upgraded resource produces a separate notice that an http:// URL was automatically upgraded to HTTPS. Both message types name the exact offending URL, which is what you need to fix it.
The console is the fastest first look, but it only shows problems on pages you happen to open. A resource referenced only on a checkout step, or in an email template, or inside a rarely-visited admin page, will not appear until someone loads that specific page. This is why mixed content is so persistent: it hides in the corners of a site that the owner rarely visits, surfacing only for the unlucky user who lands there. Catching all of it means checking every page, not just the homepage, which is exactly the kind of coverage an automated crawl is built for.
How do you fix mixed content properly?
There is a fast, weak fix and a slower, durable one, and knowing the difference matters because the fast fix quietly fails in ways that are hard to notice.
The durable fix is to correct the source. Find every http:// reference in your page markup, your templates, your database content, and your stylesheets, and change it to https:// where the resource supports it, or to a protocol-relative or root-relative path where appropriate. This is the only fix that actually removes the problem, because it means the browser never even attempts an insecure request. When the failure is spread across old content, for example thousands of blog posts that hardcoded http:// image URLs during an earlier era, a careful search-and-replace across the database is the right tool, done with a backup first.
The tempting shortcut is the upgrade-insecure-requests directive, and it is worth being precise about what it does and does not do. According to MDN, this Content-Security-Policy directive instructs the browser to treat all of a site's insecure URLs as though they had been replaced with secure ones, covering blockable mixed content as well. You can deliver it as a response header, which is the stronger option because injected HTML cannot strip it, or as a <meta> tag in the document head. It is genuinely useful, but here is the catch that teams learn the hard way: it only helps if the resource is actually available over HTTPS. If the upgraded request reaches a server that does not support HTTPS, the request fails with a connection error rather than a mixed-content warning, and the content still does not load. That is why the directive is best understood as a safety net for a site you are actively cleaning up, not a substitute for fixing the URLs. Relying on it alone means trading a visible warning for an invisible failure.
There is a sensible order of operations. Fix the source URLs first so the underlying references are correct, then add upgrade-insecure-requests as a backstop to catch anything you missed or any new insecure reference that slips in later. Adding the directive without also fixing the source just hides the smell while leaving the underlying problem in place.
What are the TLS mistakes that break HTTPS in 2026?
The second family of problems lives one layer down, in how your server negotiates the encrypted connection itself. TLS, the protocol behind the S in HTTPS, has versions and cipher suites, and browsers have been steadily retiring the old ones. A server stuck on those old settings keeps working with legacy tools and older devices, so it looks fine, right up until a modern browser refuses to connect.
The headline mistake is still supporting deprecated protocol versions. According to Mozilla's server-side TLS guidelines, the recommended Intermediate profile for general-purpose servers enables only TLS 1.2 and TLS 1.3, with TLS 1.0 and 1.1 unsupported, in keeping with RFC 7525 and PCI DSS requirements. TLS 1.2 remains acceptable when it is restricted to strong, forward-secret cipher suites, and TLS 1.3 is the target. TLS 1.3 is the modern goal for good reasons: it removes the renegotiation mechanism that enabled many historical attacks, shortens the handshake, and supports only forward-secret, authenticated cipher suites. The practical fix for a stale server is not to guess at a cipher list by hand: Mozilla publishes an SSL Configuration Generator that emits a ready-to-use, hardened config for common web servers, and the Intermediate profile is the right default for the vast majority of public sites in 2026.
The visible symptom of a version problem is a specific browser error. According to a 2026 guide to the SSL version or cipher mismatch error, the error means the browser's ClientHello and the server's ServerHello found no overlap: no TLS version both sides allow, or no cipher suite both sides allow, so the handshake aborts before any certificate is even validated. The same source makes the point that matters most: this is far more often a deprecation problem than a certificate problem, because a server pinned to TLS 1.0 or 1.1 or a weak cipher keeps working with old tools and then breaks silently for updated browsers on the day the deprecation lands. A valid, in-date certificate can still trigger it, which is precisely why ordinary certificate-expiry reminders miss the failure completely.
Weak cipher suites are the subtler version of the same mistake. A server can negotiate a modern TLS version and still fall back to a weak, outdated cipher such as RC4 or 3DES, which reopens the door to attacks like SWEET32 even when your application code is correct, because the configuration itself is the vulnerability. According to Mozilla's server-side TLS guidelines, every cipher suite in the recommended profiles uses ephemeral key exchange (ECDHE or DHE) for forward secrecy and authenticated AEAD encryption such as AES-GCM or ChaCha20-Poly1305, while static RSA key exchange and CBC-mode ciphers are excluded from the modern and intermediate profiles. The fix is to remove the weak and deprecated suites, RC4, 3DES, export-grade, and NULL ciphers, and offer only those modern AEAD suites. The reassuring part is that TLS hardening is a configuration change rather than a code change, which makes it one of the lowest-cost, highest-impact security improvements available to most teams.
Why does my certificate look valid but the site still fails?
This is one of the most confusing situations, and it comes up constantly, so it deserves a direct answer. A certificate can be perfectly valid, issued by a trusted authority, and nowhere near its expiry date, while the site still throws a security error. That is because the certificate and the TLS configuration are two different things. The certificate proves identity; the TLS version and cipher suite negotiation establishes the encrypted channel. If your server only offers protocol versions or ciphers that the browser has removed, the handshake fails before the certificate is ever checked. So monitoring that only asks "is the certificate valid and unexpired" stays green while real users hit a wall. The lesson is that certificate monitoring and TLS configuration checking are separate jobs, and you need both.
Other quiet certificate-layer mistakes round out the picture. An incomplete certificate chain, where the server sends its own certificate but omits the intermediate, will verify in some browsers that happen to have cached the intermediate and fail in others and in many bots, which produces the maddening "works for me" bug. A hostname mismatch, where the certificate covers example.com but not www.example.com or a specific subdomain, breaks exactly the visitors who use the uncovered name. And a certificate that quietly lapsed because nobody set up automatic renewal is still, in 2026, a routine cause of sudden outages. Automating renewal and monitoring the actual served configuration, not just the expiry date, is what prevents these.
How do mixed content and TLS problems relate to the rest of your security setup?
They are two threads in the same fabric, and the tools that address them overlap. The upgrade-insecure-requests directive that helps with mixed content is delivered through the same Content-Security-Policy mechanism you use for other protections, and the HSTS header that forces browsers to always use HTTPS is what stops a downgrade to insecure requests in the first place. If you want the full picture of the response headers that hold all of this together, our complete 2026 guide to HTTP security headers covers CSP, HSTS, and the rest in practical detail, and it pairs naturally with everything here.
The deeper connection is that all of these problems share one trait: they are invisible on the developer's own machine and they drift over time. A site ships clean, then a marketing team embeds an http:// tracking pixel, or a CDN configuration change re-enables an old cipher, or a new subdomain launches without HTTPS, and the security posture quietly degrades with nobody editing the file that says "security." The only reliable way to know your live site is still correct is to keep checking what it actually serves, across every page, on a schedule.
That is exactly the gap a continuous scan is meant to close. Sitejar's security dimension renders and inspects your live pages the way a browser does, so mixed content that only appears three clicks deep gets surfaced alongside the response your server actually sends, rather than the one you configured months ago and assume is still in place. If you want to see where your own site stands right now, you can scan your site with Sitejar for free, up to five pages, no signup, and for teams that want to build these checks into their own pipeline, the developer documentation covers how the scan runs against live pages. Finding the problem is most of the battle, because once you can see the exact insecure URL or the exact deprecated protocol, the fix is usually straightforward.
A short field guide to the errors you might see
Because the error messages are cryptic, it helps to translate the common ones. A console message that a page loaded over HTTPS requested an insecure resource that has been blocked is classic blockable mixed content: a script, stylesheet, frame, or fetch referenced over HTTP. A console message that an http:// resource was automatically upgraded to HTTPS is upgradable mixed content that the browser rescued, but which you should still fix at the source in case the upgrade fails elsewhere. A page-level error along the lines of an obsolete TLS version means the server offered a protocol the browser has retired, and the fix is to enable TLS 1.2 and 1.3 and disable the older versions. A version-or-cipher mismatch error means there was no common ground at all between browser and server on protocol or cipher, again pointing at deprecated settings on the server. And a protocol-version alert during the handshake points the same direction: the server needs a modern TLS configuration. In every one of these cases the durable answer lives in the server configuration or the page source, not in asking users to change anything.
The bottom line
In 2026, a valid certificate and a padlock icon are not proof that your HTTPS is actually working. Mixed content quietly undermines secure pages by pulling in resources over plain HTTP, and because browsers now auto-upgrade some of it and hard-block the rest, the symptom is often a silently missing image or a broken feature rather than an obvious warning. TLS misconfiguration works one layer down, where servers still offering TLS 1.0, 1.1, or weak ciphers like RC4 and 3DES either expose users to downgrade attacks or fail the handshake entirely for modern browsers, all while the certificate itself looks perfectly healthy. The durable fixes for both are the same in spirit: correct the source rather than paper over it, use upgrade-insecure-requests and HSTS as backstops rather than crutches, disable everything deprecated, and, above all, keep checking what your live site actually serves, on every page, over time. HTTPS is not a one-time migration you finish and forget. It is a configuration you maintain, and the sites that stay secure are the ones that treat it that way.
Sources
MDN Web Docs, CSP: upgrade-insecure-requests
Mozilla, Server Side TLS Guidelines
Mozilla, SSL Configuration Generator
ERR_SSL_VERSION_OR_CIPHER_MISMATCH explained
This article is educational and reflects Sitejar's point of view. It is not legal advice. For your specific situation, consult a qualified professional.