Nothing tanks user trust faster than a browser security warning. That red padlock, the "Your connection is not private" interstitial—most visitors won't click through it. They'll leave. And they probably won't come back.
SSL certificates are one of those things that work invisibly until they don't. And when they fail, they fail loudly. Here are seven problems that catch teams off guard, and how to spot them before your users do.
1. The Certificate Expired
This is the most common SSL failure, and the most preventable. Every SSL certificate has an expiration date. When that date passes, browsers immediately distrust the certificate and show a full-page warning.
It happens to everyone. Even massive companies have let certificates expire on production systems. The problem is that certificate renewal is easy to forget when it only happens once a year (or once every 90 days with Let's Encrypt). The person who set it up might have left the company. The auto-renewal might have failed silently. The credit card on file—or even the domain registration itself—might have expired.
The fix is monitoring. Use an SSL checker to check your certificates regularly and alert when expiration is approaching. Most teams set alerts at 30 days, 14 days, and 7 days before expiration. That gives you three chances to notice and act before anything breaks.
An SSL checker returns the valid_from and valid_to dates. Subtract today from valid_to and you know exactly how many days remain. If the number gets below your threshold, somebody needs to renew.
2. The Domain Doesn't Match
An SSL certificate is issued for specific domain names. A certificate for example.com doesn't cover app.example.com unless it's a wildcard certificate (*.example.com). And a wildcard for *.example.com doesn't cover example.com itself—that's a separate entry.
This mismatch happens most often during infrastructure changes. You spin up a new subdomain, point it to a server that already has an SSL certificate, and assume it's covered. It isn't. The browser checks whether the certificate's subject (or subject alternative names) includes the domain being accessed. If not, warning page. A quick DNS lookup can confirm which server a subdomain actually points to before you assume certificate coverage.
Checking the subject.CN (Common Name) and subjectaltname fields from a certificate reveals exactly which domains it covers. Before launching a new subdomain, verify the certificate includes it. Before migrating a domain to new infrastructure, confirm the new server's certificate matches.
3. Weak Encryption
Not all SSL certificates are equally strong. The encryption strength depends on the key size and the cipher suites the server supports.
A 2048-bit RSA key is the current minimum for browser trust. Older certificates with 1024-bit keys are considered insecure. Even certificates that are technically valid might use deprecated cipher suites that modern scanners flag as weak.
The bits field from an SSL check tells you the key size immediately. If you see 1024 or lower, that certificate needs replacement regardless of its expiration date. Modern certificates should use 2048-bit RSA at minimum, with 4096-bit as the recommended standard for anything handling sensitive data.
This matters beyond security. Google uses HTTPS as a ranking signal, and strong SSL configuration is part of that assessment. Weak encryption can quietly hurt your search rankings.
4. Certificate Chain Issues
SSL certificates don't exist in isolation. They're part of a chain: your certificate, signed by an intermediate certificate, signed by a root certificate that browsers trust. If any link in this chain is missing or broken, validation fails.
The most common chain issue is a missing intermediate certificate. Your certificate is valid. The root certificate is trusted. But the server doesn't serve the intermediate certificate that connects the two. Some browsers can fill in the gap by fetching the intermediate themselves. Others can't.
This creates the maddening situation where your site works in Chrome but not in Firefox, or works on desktop but not on mobile. Inconsistent failures across browsers almost always point to a chain problem.
An SSL check that includes CA issuer information reveals whether the chain is complete. If the check succeeds but specific browsers fail, look at the chain configuration on your server.
5. Mixed Content
You have a valid SSL certificate. Your site loads over HTTPS. But some resources on the page—images, scripts, stylesheets—load over plain HTTP. This is mixed content, and browsers handle it harshly.
Active mixed content (scripts, iframes) gets blocked entirely. Passive mixed content (images, audio) might load but triggers warnings. Either way, that green padlock disappears, replaced by a warning icon that tells users something is wrong.
SSL certificate checks won't catch this directly—it's a content problem, not a certificate problem. But it ends up on this list because developers blame the certificate first, every single time. If your certificate checks clean but users report security warnings, audit your pages for HTTP resource references.
The fix is usually straightforward: change http:// to https:// in your resource URLs, or better yet, use protocol-relative URLs (//) that inherit the page's protocol.
6. The Wrong Certificate Type
Different certificate types provide different levels of validation.
Domain Validation (DV) certificates confirm you control the domain. They're automated, free (via Let's Encrypt), and sufficient for most applications. The certificate shows the domain name but no organization information.
Organization Validation (OV) certificates verify the organization behind the domain. The CA checks that the company exists and controls the domain. The certificate includes the organization name.
Extended Validation (EV) certificates involve the most rigorous verification. The CA verifies legal existence, physical address, and operational presence. These used to show a green bar in browsers (most no longer do), but they still convey maximum trust for high-stakes applications.
The issue isn't that one type is "wrong"—it's using the wrong type for your context. An e-commerce site processing payments should probably have OV or EV, not just DV. A personal blog? DV is more than enough. Financial institutions often require EV for regulatory compliance.
The issuer and subject fields reveal the certificate type. DV certificates show minimal subject information. OV and EV certificates include organization details—country, state, company name.
7. Certificate Revocation
Certificates can be revoked before they expire. This happens when private keys are compromised, the CA made an error, or the domain ownership changed. Revoked certificates should not be trusted, even if they haven't expired.
Revocation checking is, frankly, one of SSL's worst-designed aspects. Two mechanisms exist: CRL (Certificate Revocation Lists) and OCSP (Online Certificate Status Protocol). Both have reliability issues. CRLs can be large and slow to download. OCSP responders can be unreachable.
OCSP stapling improves this by having the server attach a recent OCSP response to the SSL handshake. Clients don't need to contact the OCSP responder separately. If your server supports OCSP stapling, enable it.
The infoAccess field from a certificate check shows the OCSP URI—where revocation status can be verified.
Automating the Checklist
Manually checking certificates doesn't scale. If you manage more than a handful of domains, automate these checks.
const response = await fetch(
'https://api.apiverve.com/v1/sslchecker?domain=yourdomain.com',
{ headers: { 'x-api-key': 'YOUR_API_KEY' } }
);
const { data } = await response.json();
// data.valid_from → certificate start date
// data.valid_to → certificate expiration date
// data.bits → key strength (2048, 4096, etc.)
// data.issuer.O → certificate authority name
// data.subject.CN → domain the cert covers
Run this daily against every domain you manage. Alert on certificates expiring within 30 days. Flag any certificate with key strength below 2048 bits. Log changes to detect unexpected certificate swaps.
Most SSL failures are preventable. They happen because nobody was watching. A daily automated check turns "surprise outage" into "routine maintenance."
Monitor your SSL certificates with the SSL Checker API. Verify TLS configuration with the TLS Checker API. Track domain expirations with the Domain Expiration API. Stay ahead of security issues.
Originally published at APIVerve Blog
Top comments (0)