How to Check SSL Certificates and Fix Chain of Trust Errors

An SSL (Secure Sockets Layer) certificate is the digital passport that authenticates the identity of a website and encrypts information sent to the server using SSL/TLS technology. In today's modern web environment, HTTPS is no longer an optional security enhancement; it is a strict, universally enforced requirement. An expired, misconfigured, or untrusted SSL certificate instantly results in catastrophic browser warnings—such as Google Chrome's notorious "Your connection is not private" error. These warnings directly lead to a total loss of user trust, plummeting conversion rates, and severe SEO penalties from search engines.

Whether you are migrating a website to a new server, configuring a reverse proxy like NGINX, or simply ensuring your annual certificate renewal succeeded, knowing how to accurately inspect your TLS/SSL configuration is a mandatory skill for every webmaster. This guide will walk you through exactly how to check your SSL certificate, how to interpret the technical data, and how to resolve the most common cryptographic errors.

Why Browser Caches Mask SSL Errors

A common mistake made by junior developers and system administrators is relying solely on their local web browser (like clicking the padlock icon in Chrome) to verify an SSL certificate after making a server configuration change.

Web browsers are aggressively designed for speed. To reduce latency during the TLS handshake, browsers cache SSL certificates and intermediate certificate chains. If you recently had a valid certificate, broke your server configuration, and refreshed the page, your browser might still show a secure connection because it is using the cached certificate data. Similarly, it might show an old certificate even after you have deployed a new one.

To get an accurate reading, you must use an external, server-side diagnostic utility like the FluxToolkit SSL Certificate Checker. Our tool makes a fresh, raw TLS connection to your server every single time, bypassing all local caches. This guarantees that you are seeing the exact cryptographic parameters that a brand-new visitor (or a Google crawler) will experience when hitting your endpoint.

Step 1: Understanding Certificate Validation Levels

When checking your certificate, the first parameter to inspect is the "Issuer" and the validation level. Not all SSL certificates are created equal, and the validation level determines how much trust is conveyed to the end user.

Domain Validation (DV)

DV certificates are the most common and accessible type of SSL, largely popularized by free authorities like Let's Encrypt. The Certificate Authority (CA) simply verifies that the applicant has control over the domain name, typically via an automated DNS TXT record challenge or an HTTP challenge. While DV certificates provide strong cryptographic encryption, they do not verify the legal identity of the business operating the website.

Organization Validation (OV)

OV certificates require a much deeper level of vetting. The CA manually verifies the legal existence of the organization, its registered physical address, and its operational status. This validation data is embedded directly into the certificate details, providing sophisticated users with a higher level of assurance regarding who they are interacting with.

Extended Validation (EV)

EV certificates are the gold standard for trust and security. They require a rigorous, standardized vetting process. Historically, EV certificates triggered the prominent "green padlock" and company name display in browser address bars. While modern browsers have shifted this information into the certificate details pane to save UI space, EV is still heavily utilized by financial institutions, government agencies, and enterprise e-commerce platforms to prevent sophisticated phishing attacks.

Step 2: Checking Subject Alternative Names (SANs)

Historically, a single SSL certificate could only secure a single domain name (e.g., example.com). If you wanted to secure blog.example.com, you needed to purchase and configure an entirely separate certificate.

Today, modern certificates utilize the Subject Alternative Name (SAN) extension. A SAN allows a single SSL certificate to secure multiple domain names or subdomains simultaneously.

When you run your domain through an SSL checker, you should carefully review the SAN list.

• Wildcard Certificates: You might see *.example.com listed in the SANs, meaning the certificate covers any first-level subdomain.
• Multi-Domain Certificates: You might see completely different domains, such as example.com and example.net, sharing the same unified communications certificate.

If your website is accessible via www.example.com but your SSL certificate only lists example.com in the SANs, visitors typing the www prefix will encounter a terrifying security warning. Always verify that your SANs cover every possible routing path to your server.

Step 3: Diagnosing "Chain of Trust" Errors

One of the most frequent (and frustrating) SSL configuration failures is a "broken chain of trust" or "missing intermediate certificate." This is the number one reason an SSL certificate will appear valid on a desktop computer but fail entirely on mobile devices.

When a Certificate Authority issues your SSL certificate, they rarely sign it directly with their Root Certificate. Root Certificates are kept offline in highly secured vaults to prevent them from being compromised. Instead, the CA signs your certificate with an Intermediate Certificate.

When a user connects to your server, their browser must trace the cryptographic signature from your site's certificate, through the Intermediate Certificate, all the way up to a trusted Root Certificate that is pre-installed in their operating system's trust store.

The Fix: Bundle Your Certificates

If your web server (such as NGINX or Apache) is only configured to serve your specific domain certificate and fails to "bundle" or serve the Intermediate Certificate alongside it, the connection will fail. Mobile operating systems have smaller, stricter trusted Root Certificate stores compared to desktop environments. If your server fails to serve the intermediate chain, a desktop browser might silently download the missing intermediate cert from the internet, while a mobile browser will immediately drop the connection and throw an untrusted error.

To fix this, you must download the correct CA Bundle or intermediate certificate chain from your Certificate Authority. Then, concatenate (combine) your primary domain certificate and the intermediate bundle into a single file before pointing your web server (e.g., the NGINX ssl_certificate directive) to this unified file.

Step 4: Manual OpenSSL Verification Tactics

While our online visual dashboard is perfect for rapid diagnostics, system administrators frequently need to verify configurations directly from the terminal during automated CI/CD deployments or headless server migrations.

The industry standard for manual verification is the openssl command-line utility. To manually query an SSL certificate, execute the following command in your terminal:

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

This command initiates a raw TLS handshake. The -servername flag is absolutely crucial; it triggers SNI (Server Name Indication). SNI is a TLS extension that allows a web server to host multiple SSL certificates on a single IP address. During the initial handshake, the client tells the server which hostname it is trying to connect to, allowing the server to respond with the correct, domain-specific SSL certificate. Without the -servername flag, a multi-tenant server will often return its default (and incorrect) certificate.

1. Extracting the Expiration Date

You can pipe the raw OpenSSL output into x509 tools to extract specific data points. To check the exact expiration date via terminal, use:

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

This ensures your automated renewal scripts (like Certbot) are functioning correctly before a catastrophic expiration occurs.

Deep Dive: Cryptographic Fingerprints and Ciphers

Beyond expiration dates and issuer names, a thorough SSL audit involves inspecting the raw SHA-256 and SHA-1 cryptographic fingerprints of your certificate. These fingerprints act as a unique digital hash of the certificate's public key infrastructure.

Security analysts use these fingerprints to cross-reference certificates against Certificate Transparency (CT) logs. CT logs are public, append-only cryptographic ledgers that record every single SSL certificate issued by trusted CAs. By verifying your fingerprint against the logs, you can ensure that no rogue or compromised Certificate Authority has fraudulently issued a certificate for your domain without your knowledge.

Furthermore, verifying your certificate's signature algorithm ensures compliance. Your certificate should be signed with at least SHA-256 using an RSA 2048-bit key or an ECC (Elliptic Curve Cryptography) key. Anything less (such as the deprecated SHA-1) will be rejected by modern browsers and fails modern cryptographic standards mandated by the PCI Security Standards Council.

Common Mistakes When Configuring SSL

Mistake 1: Forgetting to Force HTTPS Redirection

The Fix: Installing an SSL certificate is only step one. If you do not configure your web server to force a 301 redirect from HTTP (port 80) to HTTPS (port 443), users and search engines can still access the insecure version of your site. This causes duplicate content issues in SEO and leaves users vulnerable to man-in-the-middle attacks.

Mistake 2: Mixed Content Errors

The Fix: If your site loads over HTTPS but embeds images, scripts, or stylesheets over HTTP, browsers will block the insecure assets and display a "Mixed Content" warning. Ensure every absolute URL in your source code uses https:// or relative protocol paths (e.g., //cdn.example.com/image.jpg).

Mistake 3: Ignoring Non-Standard Ports

The Fix: While standard web traffic uses port 443, SSL is used across various protocols. If you are running an encrypted mail server (SMTP on 465, IMAP on 993) or a custom admin panel (port 8443), you must verify the certificates on those specific ports.