How to Verify HTTPS is Working on My Website with OpDeck's Tool

If you're wondering how to verify HTTPS is working on your website, you've come to the right place. Whether you just installed an SSL certificate, migrated from HTTP to HTTPS, or simply want to confirm your site is secure, this guide walks you through every method — from quick browser checks to deep technical validation — so you can be completely confident your HTTPS setup is solid.

HTTPS is no longer optional. It protects your visitors' data, boosts your search engine rankings, and signals trustworthiness to anyone who lands on your site. But simply having an SSL certificate installed doesn't always mean everything is working correctly. Misconfigurations, expired certificates, mixed content issues, and redirect problems can silently undermine your security posture. Let's fix that.

Why Verifying HTTPS Matters More Than You Think

A lot of site owners assume that because they installed an SSL certificate, HTTPS is "done." In reality, there are several layers to a properly functioning HTTPS implementation:

The certificate itself — Is it valid, not expired, and issued by a trusted authority?
The certificate chain — Are all intermediate certificates properly installed?
Redirects — Does HTTP automatically redirect to HTTPS?
Mixed content — Are any page resources (images, scripts, stylesheets) still loading over HTTP?
Security headers — Is HSTS configured to enforce HTTPS at the browser level?
Subdomains — Does your certificate cover www and any other subdomains you use?

Missing any of these can mean your site shows a padlock icon in some browsers but still has exploitable vulnerabilities, or worse — it shows a security warning that drives visitors away.

Step 1: The Quick Browser Check

The fastest way to do an initial check is right in your browser. Open your website in Chrome, Firefox, or Edge and look at the address bar.

What to Look For

A padlock icon next to your URL — this means the connection is encrypted and the certificate is trusted
"https://" at the start of the URL — confirms the secure protocol is in use
No warnings — a broken padlock, red warning, or "Not Secure" label means something is wrong

Digging Deeper in Chrome

Click the padlock icon and select "Connection is secure" followed by "Certificate is valid." This opens a panel showing:

Who issued the certificate (the Certificate Authority)
The domain(s) it covers (the Subject Alternative Names)
The expiration date

This is useful for a quick sanity check, but it won't catch every issue. For a thorough analysis, you need to go further.

Step 2: Use OpDeck's SSL Certificate Checker

The most efficient way to verify HTTPS is working on your website at a technical level is to use a dedicated SSL checking tool. OpDeck's SSL Certificate Checker gives you a comprehensive breakdown of your certificate's status without needing to install anything or run complex commands.

How to Use the SSL Checker

Go to https://www.opdeck.co/tools/ssl
Enter your website's domain name (e.g., example.com)
Click Analyze and wait a few seconds for the results

What the SSL Checker Reports

OpDeck's SSL tool examines multiple aspects of your HTTPS setup and returns clear, actionable results:

Certificate Validity Confirms whether your certificate is currently valid or has expired. An expired certificate causes browsers to block access entirely, showing a full-page warning to visitors.

Issuer and Trust Chain Shows which Certificate Authority (CA) issued your certificate and whether the full trust chain is properly configured. An incomplete chain means some browsers — particularly on mobile — may reject your certificate even if it looks fine on desktop.

Domain Coverage Verifies that the certificate covers the exact domain you're using, including whether both www.example.com and example.com are covered. A certificate mismatch error is one of the most common HTTPS problems.

Expiration Date Displays exactly when your certificate expires so you can plan renewals in advance. Most certificates are valid for 90 days (Let's Encrypt) or up to one year (commercial CAs), and letting one expire is a surprisingly easy mistake.

Protocol and Cipher Support Checks which TLS protocol versions your server supports. TLS 1.0 and 1.1 are deprecated and considered insecure — your server should be using TLS 1.2 or TLS 1.3.

Step 3: Test HTTP-to-HTTPS Redirects

Having a valid certificate is only part of the equation. You also need to confirm that anyone who visits your site over HTTP gets automatically redirected to HTTPS. If they don't, some users will land on the insecure version of your site without realizing it.

Using curl to Test Redirects

Open your terminal and run:

curl -I http://yourdomain.com

Look at the response headers. You should see something like:

HTTP/1.1 301 Moved Permanently
Location: https://yourdomain.com/

A 301 Moved Permanently redirect is what you want — it's permanent, passes SEO value, and tells browsers to always use HTTPS going forward. A 302 Found redirect works but is temporary and less ideal for SEO.

Testing the www Variant

Also test whether http://www.yourdomain.com redirects properly:

curl -I http://www.yourdomain.com

And check that https://www.yourdomain.com redirects to (or serves) the same canonical URL as https://yourdomain.com — whichever version you've chosen as your canonical domain.

Common Redirect Chains to Avoid

Redirect chains slow down your site and can confuse crawlers. Avoid setups like:

http://www.example.com → http://example.com → https://example.com

This is a two-step redirect when it should be one. Ideally:

http://www.example.com → https://www.example.com (single redirect)

Step 4: Check for Mixed Content Issues

Mixed content is one of the sneakiest HTTPS problems. It happens when your page is loaded over HTTPS but some resources — images, JavaScript files, CSS stylesheets, fonts, or iframes — are still being requested over HTTP.

Browsers handle mixed content in two ways:

Passive mixed content (images, audio, video): Browsers may load these but display a warning
Active mixed content (scripts, stylesheets, iframes): Browsers block these entirely, which can break your site's functionality

Finding Mixed Content in Chrome DevTools

Open your site in Chrome
Press F12 to open Developer Tools
Click the Console tab
Look for warnings like: Mixed Content: The page at 'https://...' was loaded over HTTPS, but requested an insecure resource 'http://...'

Finding Mixed Content with curl and grep

For a quick scan on the command line:

curl -s https://yourdomain.com | grep -i 'http://'

This pulls your page's HTML and looks for any http:// references. Note that this only catches hardcoded HTTP references in the HTML source — dynamically loaded resources won't show up here.

Fixing Mixed Content

The fix is usually straightforward:

Update hardcoded http:// URLs in your content, templates, and configuration files to https://
If you're using WordPress, a plugin like Better Search Replace can update all database references
Set your Content Security Policy (CSP) header to upgrade-insecure-requests as a safety net:

Content-Security-Policy: upgrade-insecure-requests

This instructs browsers to automatically upgrade any remaining HTTP requests to HTTPS.

Step 5: Verify HSTS (HTTP Strict Transport Security)

HSTS is a security header that tells browsers to always use HTTPS for your domain, even if someone types http:// manually or clicks an old HTTP link. Once a browser has seen your HSTS header, it will refuse to connect over HTTP for the duration of the max-age you specify.

Checking Your HSTS Header

Run this curl command to inspect your response headers:

curl -I https://yourdomain.com

Look for a header like this in the output:

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

What the directives mean:

max-age=31536000 — Browser will enforce HTTPS for one year (31,536,000 seconds)
includeSubDomains — Applies the policy to all subdomains as well
preload — Signals that you want your domain included in browsers' built-in HSTS preload lists

Adding HSTS to Your Server

Apache:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

Nginx:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

Cloudflare: Enable HSTS directly in the SSL/TLS settings under the Edge Certificates tab — no server configuration needed.

Important: Start with a short max-age (like max-age=300) when first implementing HSTS. Once you've confirmed everything works correctly, increase it to a year or more. A misconfigured HSTS header with a long max-age can lock visitors out of your site for an extended period if you ever need to revert to HTTP.

Step 6: Validate Your Certificate Chain

An incomplete certificate chain is a common problem that's easy to miss because it might work fine in desktop Chrome (which has a robust certificate store) but fail on older Android devices, some Linux systems, or automated tools.

Checking the Chain with OpenSSL

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com

Look at the output carefully. You want to see something like:

Certificate chain
 0 s:CN = yourdomain.com
   i:CN = Sectigo RSA Domain Validation Secure Server CA
 1 s:CN = Sectigo RSA Domain Validation Secure Server CA
   i:CN = USERTrust RSA Certification Authority
 2 s:CN = USERTrust RSA Certification Authority
   i:CN = AAA Certificate Services

Each certificate in the chain should be issued by the one above it, all the way up to a root CA. If the chain stops early (missing intermediate certificates), some clients will fail to verify your certificate.

What to Do If Your Chain Is Incomplete

Contact your SSL certificate provider and download the full certificate bundle, which includes both your domain certificate and all intermediate certificates. Then update your server configuration to use the full bundle rather than just your domain certificate.

Step 7: Check Certificate Expiration and Set Up Renewal Alerts

An expired SSL certificate is one of the most preventable HTTPS failures, yet it happens to experienced developers and large organizations alike. The moment your certificate expires, browsers show a full-page blocking warning that most visitors will not click through.

Checking Expiration via Command Line

echo | openssl s_client -servername yourdomain.com -connect yourdomain.com:443 2>/dev/null | openssl x509 -noout -dates

This returns output like:

notBefore=Jan  1 00:00:00 2024 GMT
notAfter=Dec 31 23:59:59 2024 GMT

Setting Up Renewal Reminders

Let's Encrypt / Certbot: Certbot handles automatic renewal via a cron job or systemd timer. Verify it's running with systemctl status certbot.timer or crontab -l
Commercial certificates: Set a calendar reminder 30 days before expiration
Monitoring services: Use uptime monitoring tools that include SSL expiration checks

OpDeck's SSL Certificate Checker shows your certificate's expiration date clearly, making it easy to check at a glance whenever you need a quick status update.

Step 8: Run a Full HTTPS Verification Checklist

Once you've worked through each step above, run through this final checklist to confirm everything is in order:

Check	Status
Certificate is valid and not expired	✅ / ❌
Certificate covers your domain (and www)	✅ / ❌
Full certificate chain is installed	✅ / ❌
HTTP redirects to HTTPS (301)	✅ / ❌
No mixed content warnings	✅ / ❌
HSTS header is present	✅ / ❌
TLS 1.2 or 1.3 is in use	✅ / ❌
Weak ciphers (RC4, DES, etc.) are disabled	✅ / ❌
Certificate renewal is automated or scheduled	✅ / ❌

If every item shows a checkmark, your HTTPS implementation is solid. Any failures point you directly to what needs attention.

Common HTTPS Problems and How to Fix Them

"Your connection is not private" Error

This browser error (NET::ERR_CERT_AUTHORITY_INVALID or similar) usually means:

Your certificate is self-signed (not trusted by browsers)
The certificate is expired
The certificate doesn't match the domain

Use the OpDeck SSL Checker to identify the exact cause quickly.

Padlock Icon Missing Despite HTTPS URL

This typically means mixed content. The page is served over HTTPS but is requesting some resources over HTTP. Follow Step 4 above to find and fix those resources.

Redirect Loop

If your site gets stuck in a redirect loop, check your .htaccess or Nginx configuration for conflicting redirect rules. Also check if your CDN or load balancer is stripping HTTPS before it reaches your origin server — in that case, you may be redirecting infinitely.

Certificate Works on Desktop But Not Mobile

This is almost always an incomplete certificate chain issue. Mobile devices and older operating systems have smaller built-in certificate stores and rely more heavily on the server providing the full chain. See Step 6 for how to diagnose and fix this.

How to Verify HTTPS Is Working: A Summary

Verifying that HTTPS is working on your website isn't a single check — it's a series of validations covering your certificate, redirects, content, headers, and renewal process. The good news is that with the right tools and a systematic approach, you can confirm everything is working in under 30 minutes.

Start with OpDeck's SSL Certificate Checker for an immediate, comprehensive overview of your certificate's health. Then work through the curl commands and browser checks outlined in this guide to validate your redirects, mixed content, and HSTS configuration.

A properly configured HTTPS setup protects your visitors, improves your search visibility, and prevents the kind of browser warnings that erode trust. Take the time to verify it properly — and then set up monitoring so you're never caught off guard by an expired certificate or a broken redirect.

Ready to check your site right now? Head over to OpDeck's SSL Certificate Checker and get a full report on your HTTPS configuration in seconds. No account required, no installation needed — just enter your domain and see exactly where you stand.