How to Check Website Security Without Firefox’s Green Lock

For many years, the green lock icon in Firefox and other browsers was treated as a quick visual signal that a website was secure. Users saw the icon, assumed the website could be trusted, and rarely looked any further. Website owners also relied on it because it offered an easy way to demonstrate that HTTPS had been enabled.

Modern browsers have moved away from that approach. Firefox still provides detailed information about the security of a connection, but the browser no longer encourages users to think of a lock icon as a universal trust badge. This change reflects a more accurate view of web security: an encrypted connection is important, but it is only one layer of a secure website.

That distinction matters because a website can have a valid TLS certificate and still contain malware, phishing content, vulnerable software, deceptive offers, or compromised third-party scripts. HTTPS protects the connection between your browser and the website. It does not automatically prove that the people operating the website are trustworthy or that the application itself is secure.

So, if Firefox no longer gives users a simple green lock to rely on, how should you evaluate a website’s security? The answer is to examine several technical and contextual signals together rather than depending on a single browser icon.

What Did the Old Green Lock Actually Mean?

The old green lock was useful, but it was often misunderstood. It primarily indicated that the browser had established a secure HTTPS connection and that the certificate presented by the server could be validated. That meant the communication between the browser and the server was encrypted and that the server had demonstrated control over the domain covered by the certificate.

It did not mean that the website had passed a complete security audit. The browser was not checking whether the site’s code was free from vulnerabilities, whether the business was legitimate, whether its privacy practices were sound, or whether the content was safe.

This distinction becomes much clearer when you understand TLS and SSL in detail. TLS is designed to provide confidentiality, integrity, and authentication for the connection. It is not designed to judge the honesty or security maturity of the organization operating the website.

The OWASP Transport Layer Security Cheat Sheet makes the same distinction by explaining that TLS protects data in transit but is only one part of an application’s overall security architecture.

Start With HTTPS, But Do Not Stop There

The first thing to check is still the address itself. A secure website should normally load using an https:// URL rather than http://.

For example:

https://example.com

is protected by TLS, while:

http://example.com

is not.

HTTPS means that the browser and server have negotiated an encrypted connection. However, simply seeing https:// should be considered the beginning of your security check, not the end.

Google’s official Chrome guidance explains that the browser distinguishes between secure connections, pages that are “Not secure,” and sites that are considered dangerous. A secure connection means the communication is protected, but users still need to consider the legitimacy of the site itself.

For website owners, HTTPS remains an essential part of a broader security strategy. A properly configured HTTPS deployment should be accompanied by secure server settings, software updates, access controls, and monitoring, as discussed in how to secure your website.

Check the Certificate Instead of Looking for a Green Lock

Modern browsers still let you inspect the certificate used by a website even though they no longer emphasize a green lock icon. In Firefox, the Site Information panel provides details about the current connection, including whether it is secure and information about the certificate.

When reviewing a certificate, pay attention to several details:

• Domain name: Does the certificate cover the exact hostname you are visiting?
• Validity period: Has the certificate expired?
• Issuer: Which Certificate Authority issued it?
• Connection status: Is the browser reporting a secure connection?
• Errors: Is there a hostname mismatch, trust problem, or certificate-chain issue?

Mozilla’s documentation on the Site Information panel explains how Firefox exposes this information to users and why it is more useful than relying on a single visual indicator.

A valid certificate does not guarantee that a website is legitimate, but an invalid certificate is a serious warning. If the browser cannot validate the certificate, you should investigate before entering passwords, payment information, or other sensitive data.

Verify the Certificate Chain

Browsers do not simply check whether a certificate exists. They validate whether the certificate can be connected through a trusted chain to a root certificate authority included in the browser or operating system’s trust store.

A simplified certificate chain looks like this:

Website Certificate
        ↓
Intermediate Certificate
        ↓
Root Certificate Authority
        ↓
Browser Trust Store

If the server fails to provide the necessary intermediate certificate, some browsers or devices may reject the connection even though the website administrator believes the certificate itself is valid.

This is why understanding the certificate chain of trust and verification is important when troubleshooting browser warnings. A certificate can be correctly issued but incorrectly deployed if the server does not present the required chain.

Check the Domain Name Carefully

One of the most effective security checks has nothing to do with certificates.

Look carefully at the domain name.

A phishing website can obtain a valid certificate for a domain that looks similar to a legitimate business. The browser will establish HTTPS correctly because the certificate matches that domain, but the domain itself may still be deceptive.

For example, a legitimate site might use:

https://www.example.com

while a phishing site could use:

https://example-security.com

or:

https://example.com.account-login.example.net

Both sites could have valid HTTPS connections.

This is one of the biggest limitations of the old green-lock mindset. The lock confirmed that the browser had securely connected to that domain. It never guaranteed that the domain belonged to the company you intended to visit.

Mozilla’s guidance on checking secure connections similarly recommends examining the address and connection details rather than treating a browser icon as proof of trustworthiness.

Pay Attention to Certificate Warnings

A certificate warning is much more important than the absence of a green lock.

Firefox displays a security warning when it cannot validate the certificate or establish a sufficiently secure connection. Mozilla provides error codes and additional details that can help identify the underlying problem.

Common certificate-related issues include:

Mozilla’s “Your connection is not secure” documentation explains these warnings and why users should not simply bypass them.

If you own the website, do not assume that reinstalling the certificate will solve every warning. The problem could be the certificate chain, server configuration, hostname, or another TLS issue.

Check for Mixed Content

A website can load through HTTPS and still contain insecure resources. This happens when an HTTPS page requests images, JavaScript files, stylesheets, fonts, iframes, or API data using HTTP.

For example, the page may load as:

https://example.com

while requesting:

http://example.com/script.js

The main page is encrypted, but part of the content is being fetched through an insecure connection. Modern browsers increasingly block or upgrade these requests because insecure resources can weaken the security guarantees of HTTPS.

If you own the website, use the browser’s developer tools to inspect the Console and Network panels. Mixed-content warnings often identify the exact resource responsible.

The complete troubleshooting process is covered in how to fix mixed content warnings on HTTPS websites. This is particularly useful after an HTTPS migration because old URLs can remain inside databases, themes, plugins, JavaScript, CSS, or third-party integrations.

Check the TLS Configuration

For technical users and website administrators, the browser’s certificate display is only one part of the picture.

A server’s TLS configuration determines which protocol versions, cipher suites, certificate chains, and key-exchange mechanisms are available to clients. A website can have a valid certificate while still supporting outdated protocols or weaker configurations.

One of the most widely used tools for examining this is the Qualys SSL Labs SSL Server Test. It analyzes the public TLS endpoint and reports on certificate deployment, supported protocols, and other configuration details.

A TLS configuration review should consider questions such as:

• Does the server support modern TLS versions?
• Are obsolete protocols disabled?
• Is the certificate chain complete?
• Are weak cipher suites still enabled?
• Is the server configured consistently across all public endpoints?

These checks go beyond what a browser icon can communicate.

Inspect HTTP-to-HTTPS Redirects

A properly configured website should redirect HTTP traffic to HTTPS.

Typing:

http://example.com

should normally lead to:

https://example.com

without unnecessary redirect chains.

A clean redirect looks like this:

HTTP
  ↓
HTTPS

A more complicated chain such as:

HTTP
  ↓
www HTTP
  ↓
www HTTPS
  ↓
non-www HTTPS

may not be an immediate security vulnerability, but it adds unnecessary requests and can make migrations and troubleshooting more difficult.

If HTTP remains accessible without redirecting to HTTPS, the site has not fully enforced secure connections.

Check Security Headers

HTTPS protects the network connection, but modern websites also use browser security headers to control how content is handled.

Depending on the application, useful headers can include:

• Strict-Transport-Security
• Content-Security-Policy
• X-Content-Type-Options
• Referrer-Policy
• Permissions-Policy

OWASP recommends HSTS as an important mechanism for enforcing HTTPS after a site has been correctly configured. It should be introduced carefully because enabling it before all HTTPS endpoints are working can make broken subdomains inaccessible.

Security headers are not replacements for HTTPS. They complement it by adding additional browser-side protections.

Use Browser Developer Tools for a Deeper Check

If you want to understand exactly what a page is doing, browser developer tools provide far more information than the address bar.

In Chrome, open DevTools and inspect the Security panel for connection details. Then use the Network panel to examine every resource the page requests.

This can reveal:

• HTTP resources on an HTTPS page
• Redirects
• Certificate information
• Third-party scripts
• API calls
• Failed resources

This approach is especially useful when a website appears secure but users report browser errors. For example, an invalid URL error in Chrome is a different problem from a certificate error, and a Google Chrome critical error should not automatically be blamed on HTTPS.

HTTPS Does Not Mean the Website Is Trustworthy

This is the most important lesson.

Imagine two websites:

Website A
✓ Valid HTTPS
✓ Modern TLS
✓ Correct certificate
✗ Phishing website

and:

Website B
✓ Valid HTTPS
✓ Modern TLS
✓ Correct certificate
✓ Legitimate business

The browser can establish a secure connection to both.

HTTPS does not determine whether a business is honest or whether the website’s content is legitimate. It protects the communication channel.

Before entering sensitive information, consider several contextual questions:

• Did you reach the website through a trusted source?
• Is the domain spelled exactly as expected?
• Does the company provide verifiable contact information?
• Are prices or offers unusually unrealistic?
• Is the website asking for information that seems unnecessary?
• Does the site behave consistently with the organization you intended to visit?

These checks are often just as important as inspecting the certificate.

What the Old Green Lock Never Told You

The old green lock could never reliably prove that:

• The business was legitimate.
• The website was free of malware.
• The application contained no vulnerabilities.
• The company followed good privacy practices.
• Third-party scripts were safe.
• Customer data was handled responsibly.
• The server had no security weaknesses.

It primarily communicated the security state of the connection.

That is why moving away from the green-lock concept is not necessarily a reduction in browser security. It encourages users to evaluate websites using multiple indicators rather than assuming that one icon represents a complete security assessment.

A Better Website Security Checklist

Instead of looking for one visual symbol, evaluate a website across several layers.

This approach provides a much more accurate assessment than simply asking whether the browser displays a lock.

What Website Owners Should Monitor

Website security is not a one-time certificate installation.

Certificates expire, DNS changes, CDNs are reconfigured, plugins are updated, developers add new integrations, and server software changes over time. A website that is correctly configured today can develop HTTPS or security problems months later.

A practical monitoring process should include:

• Certificate expiration dates
• Certificate hostname coverage
• TLS configuration
• HTTP-to-HTTPS redirects
• Mixed-content errors
• Security headers
• DNS changes
• Third-party integrations
• Vulnerable application components

Technical teams can also benefit from understanding OpenSSL, which is widely used for certificate operations, cryptographic functions, and testing TLS connections during troubleshooting.

Final Thoughts

The old green lock was convenient because it reduced a complicated security state to a simple visual indicator. The problem was that many users interpreted it as proof that the entire website was trustworthy.

Modern browsers encourage a more accurate understanding.

Start by checking HTTPS. Then inspect the certificate, verify the domain, look for certificate warnings, examine the certificate chain when necessary, and use developer tools or TLS scanners if you need a deeper technical assessment. Finally, evaluate the legitimacy of the website itself because HTTPS can protect your connection to both trustworthy and malicious sites.

The disappearance of the green lock does not mean website security has become less important. Instead, it reflects a better security model: a secure connection is one essential layer, but real website security depends on certificates, TLS configuration, application security, infrastructure, and the trustworthiness of the organization behind the domain.

That is the most reliable way to evaluate website security today—by looking beyond a single browser icon and considering the complete chain of security signals that protect users on the web.

Frequently Asked Questions

Does Firefox still use a green lock?

Firefox still provides information about connection security, but it no longer promotes the old green-lock concept as a complete website trust signal. Users can inspect the Site Information panel to review the connection and certificate details.

Is HTTPS enough to prove a website is safe?

No. HTTPS protects the connection between your browser and the server. It does not prove that the website is legitimate, free from malware, or secure at the application level.

Can a phishing website use HTTPS?

Yes. A phishing website can obtain a valid certificate for its own domain. The certificate proves control over that domain for the TLS connection; it does not prove that the domain belongs to the company you expected.

How can I check a website’s certificate?

Open the browser’s Site Information or Security panel and inspect the certificate details. For a deeper server-side analysis, tools such as the Qualys SSL Labs SSL Server Test can evaluate the public TLS configuration.

What is more important than the green lock?

The best approach is to examine multiple signals together: HTTPS status, certificate validity, certificate chain, TLS configuration, exact domain name, mixed content, security headers, and the legitimacy of the organization operating the site.