TLS / HTTPS

Quick Answer

TLS / HTTPS protects the connection between the browser and the site. CyberLens checks whether it can collect basic TLS information, which TLS version is in use, who issued the certificate, when it expires, and whether HTTP traffic is redirected to HTTPS. If the certificate is valid and the redirect is present, that is a good technical sign; if not, it is worth reviewing the setup.

What It Is

• HTTPS: the encrypted version of HTTP. It helps protect data exchanged between the user and the server while it is in transit.
• TLS (Transport Layer Security): the modern cryptographic protocol used to establish a secure connection. It is the successor to the old SSL protocol.
• TLS certificate: a digital certificate that lets the browser verify the site’s identity and start an encrypted session. It is issued by a certification authority, often shown as the certificate issuer.
• HTTP -> HTTPS redirect: a configuration rule that automatically sends visitors from the unsecured version (http://) to the secure one (https://).

Why It Matters

A correct TLS / HTTPS setup matters for several practical reasons:

• Protection of data in transit: it helps protect information exchanged between the user and the server, especially on contact forms, logins, admin panels, or ecommerce pages.
• Browser trust: modern browsers show a “Not secure” warning on sites without HTTPS or with an invalid certificate, which can discourage visitors.
• Traffic integrity: it makes it harder for third parties, such as compromised public Wi-Fi networks, to intercept or alter page content while it is being transferred.
• Consistency of the preferred version: it helps users and crawlers land on the correct secure version of the site.

Info: HTTPS means the connection is encrypted, but it does not automatically make the whole site secure. A valid certificate does not replace code updates, application security work, backups, or solid server configuration. It is a technical foundation, not a complete guarantee. In the same way, missing HTTPS does not mean the site is compromised; it means the connection is not encrypted.

How CyberLens Checks It

CyberLens connects to the target domain and collects a focused set of parameters:

1. the TLS protocol version in use;
2. the authority that issued the certificate (issuer);
3. the certificate expiry date;
4. whether an automatic redirect from HTTP to HTTPS is present.

Technical note: CyberLens performs a focused check on these four parameters. It is not a complete TLS audit. It does not analyze cipher suites, assign an SSL Labs-style rating, verify OCSP stapling, inspect certificate transparency logs, validate the full certificate chain in detail, review HSTS in depth, or analyze Mixed Content. If those areas matter for the site, they should be checked with dedicated tools.

Possible Findings

HTTPS active, valid certificate, and redirect present

Severity: Informational
The basic setup looks correct. Traffic is encrypted and consolidated on the secure version.

HTTPS active but no HTTP -> HTTPS redirect detected

Severity: Moderate
The site is available over HTTPS, but the HTTP version may remain accessible or may not be explicitly redirected to HTTPS.

Certificate close to expiry or already expired

Severity: High
If the certificate has expired, browsers may show security warnings or block access. If expiry is close, it is worth checking renewal immediately.

TLS information not collected or HTTPS unavailable

Severity: High
CyberLens could not establish a secure connection. Possible causes include a missing certificate, incorrect configuration, or DNS propagation issues. High priority.

Unexpected certificate issuer

Severity: Moderate
A certificate is present, but the issuing authority does not match what was expected or shows unusual data. This requires manual review.

Recommended Action

Priority depends on the finding:

1. Expired certificate or HTTPS unavailable: act immediately by checking the certificate status in the hosting panel and reviewing DNS propagation.
2. Certificate close to expiry: confirm that automatic renewal is working, or renew it manually through the provider.
3. Missing HTTP -> HTTPS redirect: add a 301 redirect at server, hosting-panel, or CDN level.
4. Unexpected issuer: review the certificate details manually and confirm where it was issued from.
5. Everything looks correct: no immediate action is needed, apart from periodic monitoring of automatic renewals.

How To Fix It

WordPress

• In Settings → General, make sure both the WordPress Address (URL) and the Site Address (URL) start with https://.
• Avoid installing plugins whose only purpose is to force HTTPS. In most cases, it is more efficient to handle the redirect at server or hosting-panel level.
• Check that loaded assets such as images, CSS, and JS are not using absolute http:// URLs, to avoid mixed-content issues.
• After making changes, test contact forms, login (/wp-admin), and any checkout flow.

Hosting / Control Panel (Plesk, cPanel, etc.)

• Enable or renew the certificate from the provider’s SSL/TLS section. Many control panels offer free certificates such as Let’s Encrypt.
• Enable automatic renewal to reduce the risk of the certificate expiring unexpectedly.
• Confirm that the certificate covers both the www and non-www versions, plus any relevant subdomains.
• Many control panels also offer a “Force HTTPS” or “Redirect HTTP -> HTTPS” option. If available, that is usually the simplest path and does not require manual server rules.

Apache / .htaccess

If you have access to the site root on Apache, you can add a permanent redirect rule in .htaccess:

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Warning: before applying the rule, check whether the redirect is already handled by the hosting panel or CDN, to avoid redirect loops such as “Too many redirects”. On more complex sites, test on a single page first.

Nginx

On a VPS using Nginx, configure the server block listening on port 80 (HTTP) so it redirects to port 443 (HTTPS):

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Warning: replace example.com with the real domain. Make sure the server block listening on 443 ssl is configured with the correct certificate paths. Check the syntax with nginx -t before reloading the server with systemctl reload nginx.

CDN / Reverse Proxy (for example, Cloudflare)

• If you use a CDN or reverse proxy, there is often an option to force HTTPS directly from the panel, so the redirect is handled before the request reaches the origin server.
• Make sure the encryption mode between the proxy and the origin server matches the certificate installed on the origin, to avoid communication conflicts.

How This Appears in CyberLens

In the report, the TLS / HTTPS block shows:

• TLS version — for example TLSv1.3
• Certificate issuer — for example {'countryName': 'US', 'organizationName': "Let's Encrypt", 'commonName': 'R13'}
• Certificate expires — for example Aug 13 07:46:26 2026 GMT
• HTTP -> HTTPS redirect — Detected or Not detected
• Technical details (JSON) with the raw collected fields

Example JSON output:

{
  "tls": {
    "issuer": {
      "countryName": "US",
      "organizationName": "Let's Encrypt",
      "commonName": "R13"
    },
    "expires": "Aug 13 07:46:26 2026 GMT",
    "version": "TLSv1.3"
  },
  "https_redirect": true
}