Verify SSL Certificate Before Launch

An SSL certificate encrypts the connection between your website and its visitors, protecting login credentials, payment information, and personal data from interception. But encryption alone is not enough — a misconfigured certificate, a missing intermediate chain, or an expired renewal can trigger browser security warnings that instantly erode visitor trust. Google has used HTTPS as a ranking signal since 2014, and modern browsers display prominent “Not Secure” warnings for sites without valid SSL. Verifying your certificate before launch — and monitoring it afterward — prevents these problems and ensures your site is secure from day one.

Why SSL Certificates Matter

SSL certificates serve three critical functions for any website. First, they encrypt data in transit using TLS (Transport Layer Security), preventing attackers on the same network from reading sensitive information. Second, they authenticate your server’s identity, proving to visitors that they are connected to your actual server and not an impersonator. Third, they enable HTTP/2 and HTTP/3, which significantly improve page load performance through multiplexing and header compression.

The consequences of getting SSL wrong are immediate and measurable. According to Google’s Transparency Report, over 95% of web traffic to Google is encrypted. Visitors expect HTTPS by default, and browsers make it very clear when a site does not have it. Chrome, Firefox, Safari, and Edge all display warnings for sites with expired, self-signed, or misconfigured certificates — warnings that most users will not click through.

Step 1: Inspect Your SSL Certificate

Open the SSL Certificate Checker and enter your domain name. The tool connects to your server, retrieves the full certificate, and displays the details you need to verify. Review these key fields:

• Certificate status — must show as valid. If it displays expired, revoked, or not yet valid, your site is showing security warnings to every visitor right now.
• Issuer (Certificate Authority) — identifies who issued the certificate. Trusted CAs include Let’s Encrypt, DigiCert, Sectigo, and GlobalSign. Self-signed certificates trigger browser warnings and should never be used on production websites.
• Expiry date — check when the certificate expires. Let’s Encrypt certificates last 90 days; most commercial certificates last one year. If your certificate expires within 30 days, plan your renewal immediately.
• Subject Alternative Names (SANs) — the list of all domains and subdomains the certificate covers. Make sure your primary domain, the www subdomain, and any other subdomains you use are all included.
• Key size — modern certificates should use at least a 2048-bit RSA key or a 256-bit ECDSA key. Anything smaller is considered weak by current standards.
• Signature algorithm — should be SHA-256 or stronger. Older SHA-1 certificates are no longer trusted by any major browser.

Step 2: Verify Domain Coverage

One of the most common SSL issues is a certificate that does not cover all the domains you need. A certificate issued for example.com may not cover www.example.com, and vice versa. If a visitor types the uncovered variant, they see a security warning instead of your site.

Wildcard certificates (*.example.com) cover all subdomains but not always the root domain itself — check whether the root domain is explicitly listed in the SAN field. Multi-domain (SAN) certificates let you cover completely different domains on a single certificate, which is useful if you operate multiple brands from the same server.

Use the DNS Lookup tool to verify that all your domains resolve to the correct server IP. A DNS misconfiguration can point a subdomain to a different server that has its own certificate (or no certificate at all).

Step 3: Check the Certificate Chain

SSL certificates rely on a chain of trust. Your server certificate is signed by an intermediate CA, which is signed by a root CA that browsers trust. If any link in this chain is missing or incorrect, browsers cannot verify the certificate and will show a warning — even if the certificate itself is perfectly valid.

The most common chain issue is a missing intermediate certificate. Your server must send both your certificate and the intermediate certificate(s) during the TLS handshake. The root CA certificate does not need to be sent because it is already built into browsers and operating systems. According to Let’s Encrypt’s chain documentation, their certificates use a cross-signed intermediate that ensures compatibility with older devices.

The SSL Certificate Checker shows the complete chain and flags any missing intermediates. If the chain is incomplete, download the correct intermediate certificate from your CA’s website and install it on your web server alongside your site certificate.

Step 4: Check for Mixed Content

Mixed content occurs when your HTTPS page loads resources — images, scripts, stylesheets, fonts — over plain HTTP. This partially breaks the security of your page. Browsers handle mixed content in two ways: active mixed content (scripts, iframes) is blocked entirely, while passive mixed content (images, audio) may be loaded but triggers a warning.

Common sources of mixed content include hardcoded http:// URLs in your HTML or CSS, embedded images from HTTP sources, third-party scripts loaded over HTTP, and internal links using absolute HTTP URLs instead of HTTPS or protocol-relative paths. After installing your certificate, audit every page for mixed content. Browser developer tools (F12 > Console) will log mixed content warnings.

Use the HTTP Header Checker to verify your server sends security headers. The Strict-Transport-Security (HSTS) header tells browsers to always use HTTPS, preventing accidental HTTP connections. The Content-Security-Policy header can detect and block mixed content at the browser level.

Step 5: Test HTTPS Redirects

After installing your certificate, ensure that all HTTP requests are properly redirected to HTTPS. There are four URL variations to test for every domain on your certificate:

1. http://example.com should redirect to https://example.com
2. http://www.example.com should redirect to your canonical URL
3. https://example.com should either serve content or redirect to the www variant
4. https://www.example.com should either serve content or redirect to the non-www variant

All four should eventually land on a single canonical URL with a 301 (permanent) redirect. Temporary 302 redirects do not pass full SEO value. Use the HTTP Header Checker to verify the redirect chain and status codes for each variation.

Common SSL Issues and How to Fix Them

Ongoing SSL Monitoring

SSL verification is not a one-time task. Certificates expire, CAs revoke certificates, server configurations change during updates, and new subdomains may need coverage. Build these checks into your routine:

• Monitor expiry dates — check your certificate expiry monthly, or set up automated alerts. Even with auto-renewal services like Certbot, renewals can fail silently due to DNS changes, server misconfigurations, or firewall rules blocking the CA’s validation.
• Test after server changes — any change to your web server configuration (updating Apache, Nginx, or your hosting panel) can affect SSL. Run the SSL Certificate Checker after every server update.
• Verify new subdomains — when you add a subdomain, ensure it is covered by your certificate. Wildcard certificates cover new subdomains automatically, but standard certificates require reissuance.
• Check from multiple locations — some SSL issues only appear from certain geographic locations or network paths due to CDN configurations or regional certificate caching.
• Review Certificate Transparency logs — Certificate Transparency (CT) is a public logging system that records every certificate issued for your domain. Monitoring CT logs helps you detect unauthorized certificates issued for your domain, which could indicate a compromised CA or a targeted attack. Tools like crt.sh let you search CT logs for any domain.
• Plan for certificate rotation — keep documentation of your certificate setup including the CA, key type, covered domains, and renewal process. When team members change or servers are migrated, this documentation prevents gaps in SSL coverage during the transition.

Frequently Asked Questions