If you've ever seen a "Your connection is not private" warning in your browser, you've encountered an SSL certificate issue. SSL (Secure Sockets Layer) — and its modern successor TLS (Transport Layer Security) — is the technology that encrypts data between a user's browser and your web server. Without it, sensitive information like passwords, credit card numbers, and personal data travels across the internet in plain text, visible to anyone who intercepts it.
This guide walks you through everything you need to know about checking, understanding, and maintaining SSL certificates for your website.
An SSL certificate is a digital file installed on your web server that serves two critical functions: it authenticates your website's identity, proving to visitors that they're connecting to the real site and not an imposter, and it encrypts all data transmitted between the browser and server.
When a browser connects to a website with HTTPS (the "S" stands for secure), it performs what's called an SSL/TLS handshake. During this process, the server presents its certificate, the browser verifies it's valid and issued by a trusted authority, and then both sides agree on an encryption key. All of this happens in milliseconds before any page content loads.
There are several ways to verify your website's SSL certificate, ranging from quick visual checks to detailed technical analysis.
The simplest method: click the padlock icon in your browser's address bar. This shows you whether the connection is secure and lets you view the certificate details. Here's what to look for:
Click through to the certificate details to see the issuing authority, validity dates, and the domains the certificate covers.
A dedicated SSL checker tool provides much more detail than the browser's built-in viewer. A good SSL checker will show you:
Enter your domain name into the checker, and within seconds you'll get a comprehensive security report. This is especially useful for identifying configuration issues that don't trigger browser warnings but still weaken your security posture.
For technical users, the openssl command-line tool provides direct access to certificate data:
# Check certificate details
openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -text
# Check expiration date
echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -datesThis gives you the raw certificate data including the validity period, subject alternative names, and the full certificate chain.
SSL issues are one of the most frequent causes of website downtime and visitor distrust. Here are the most common problems and their solutions.
Symptom: Browser shows "NET::ERR_CERT_DATE_INVALID" or a similar error.
Cause: The certificate has passed its expiration date. SSL certificates are valid for a limited period — most commonly 90 days (Let's Encrypt) to one year (commercial CAs).
Fix: Renew the certificate immediately. If you're using Let's Encrypt with Certbot, run certbot renew. For commercial certificates, reissue through your CA's portal. Set up automatic renewal to prevent this from recurring.
Symptom: "NET::ERR_CERT_COMMON_NAME_INVALID" — the certificate was issued for a different domain than the one you're visiting.
Cause: You installed a certificate for example.com but visitors are accessing www.example.com, or vice versa. The certificate's Subject Alternative Names (SAN) must include every domain and subdomain that will serve HTTPS traffic.
Fix: Reissue the certificate with the correct domains. Include both the bare domain and the www variant. If you have many subdomains, consider a wildcard certificate.
Symptom: The site works in some browsers but shows security errors in others. Mobile browsers are especially prone to this.
Cause: Your server is serving the end-entity certificate but not the intermediate certificate(s) that connect it to the root CA. Some browsers cache intermediate certificates, which is why it works sometimes.
Fix: Install the full certificate chain on your server. Most CAs provide a bundled file that includes both your certificate and the required intermediates. If you're configuring Nginx, use the ssl_certificate directive to point to the full chain file.
Symptom: The page loads with HTTPS but the padlock shows a warning triangle or slash. Browser console shows "Mixed Content" errors.
Cause: The page is served over HTTPS but loads resources (images, scripts, stylesheets, iframes) over HTTP. While the main connection is encrypted, these subresources are not.
Fix: Update all resource URLs to use HTTPS. Use relative URLs (//example.com/image.png) or HTTPS-absolute URLs. In Nginx, you can add a Content-Security-Policy header to upgrade insecure requests automatically:
add_header Content-Security-Policy "upgrade-insecure-requests" always;Symptom: Browser warns that the certificate is not trusted because it's self-signed.
Cause: The certificate was generated and signed by the server itself rather than by a recognized certificate authority. This is common in development environments.
Fix: For production websites, replace the self-signed certificate with one from a trusted CA (Let's Encrypt provides free certificates). For internal tools, you can distribute the self-signed CA certificate to clients, but this is only practical in controlled environments.
Beyond just having a valid certificate, there are several steps you should take to maximize your website's security and performance.
HSTS tells browsers to always connect to your site over HTTPS, even if the user types "http://". This prevents man-in-the-middle attacks that try to downgrade the connection. Add this header to your server configuration:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preloadBe careful with the preload directive — once your domain is added to the HSTS preload list (hstspreload.org), it's very difficult to remove.
Disable outdated and weak cipher suites. Your server should prefer ECDHE-based key exchange (for forward secrecy) and AES-GCM or ChaCha20-Poly1305 for encryption. Disable SSLv2, SSLv3, TLS 1.0, and TLS 1.1 — only TLS 1.2 and TLS 1.3 should be enabled.
Manual certificate renewal is error-prone. Set up automated renewal using Certbot with cron or systemd timers. Test the renewal process regularly to ensure it works. Let's Encrypt recommends renewing certificates every 60 days (they're valid for 90), which gives a 30-day buffer.
Even with automation, things can break. Use monitoring tools to alert you when certificates are approaching expiration — 30 days, 14 days, and 7 days are common thresholds. Many SSL checker tools offer email alerts for this purpose.
ECDSA certificates with 256-bit keys provide equivalent security to RSA with 3072-bit keys, but with smaller certificate sizes and faster TLS handshakes. This translates to faster page loads, especially on mobile devices. Most modern CAs offer ECDSA certificates, and Let's Encrypt supports them with the --key-type ecdsa flag in Certbot.
SSL/TLS is no longer optional — it's a fundamental requirement for any website. Understanding how to check, troubleshoot, and maintain your SSL certificates protects your visitors, boosts your search rankings, and builds trust in your brand. Use a reliable SSL checker tool regularly, automate your certificate renewals, and follow security best practices to keep your site safe. The effort is minimal, but the consequences of neglecting it can be severe.