An SSL certificate enables HTTPS and encrypts the traffic between your users' browsers and your servers, protecting sensitive data like passwords, credit cards, and personal information from interception. But many organizations treat SSL certificates as a checkbox: "we have HTTPS, we're secure." In reality, SSL certificate security is more nuanced. A properly configured certificate protects against specific threats but not others. Expired certificates, weak cipher suites, and missing certificate transparency checks leave you vulnerable to attacks that happen silently until they don't. This guide walks through what SSL certificates actually protect, how to audit your certificate configuration, and how to ensure your HTTPS setup is actually secure.
What SSL Certificates Actually Protect (And What They Don't)
An SSL certificate protects against two threats: eavesdropping and impersonation. When a user connects to your website, the certificate proves you are who you claim to be and ensures the connection is encrypted so no one can read the data being transmitted. The browser verifies the certificate against a list of trusted certificate authorities, confirms it's valid for your domain, and ensures the certificate hasn't expired. If any of these checks fail, the browser shows a warning.
Encryption protects against passive eavesdropping—an attacker can't read the data being transmitted, even if they intercept the connection. This is critical for protecting passwords, API keys, and any sensitive information users send to your site. Impersonation protection prevents attackers from creating a fake certificate for your domain. Before a certificate authority issues a certificate for a domain, they verify that the requester controls that domain. This prevents attackers from creating certificates for domains they don't own.
But SSL certificates do not protect against many threats. They don't protect against malware on a user's device. They don't protect against compromise of your private key. They don't protect against attacks on your application (SQL injection, cross-site scripting). They don't protect against man-in-the-middle attacks where the attacker also has a valid certificate for their own domain. They don't prevent data breaches of data stored on your servers—only data in transit. Understanding these limitations is crucial for realistic risk assessment.
Conducting an SSL Certificate Security Audit
Start by identifying all SSL certificates your organization uses: your primary domain, subdomains, internal services, staging environments, and any third-party tools that handle your domain. Check each certificate using SSL Labs (ssllabs.com/ssltest). Upload your domain and SSL Labs will perform a comprehensive security analysis, testing certificate validity, encryption strength, protocol versions, cipher suites, and known vulnerabilities.
The report grades your certificate security from A+ (excellent) to F (critical issues). Pay attention to the grade and the specific findings. Grade A is minimum acceptable for production systems. If you score lower, SSL Labs will identify the specific issues: outdated protocols (SSLv3 or TLS 1.0, which are broken), weak cipher suites, missing security headers, or other misconfigurations. Many are easily fixable by your hosting provider or CDN.
Check certificate validity. Verify that your certificate is valid for your domain (not a different domain or subdomain), hasn't expired, and won't expire in the next 30 days. Expired certificates break your site and cause browser warnings that terrify users. Set up automated renewal well before expiration—services like Let's Encrypt automate this entirely. If you're not using automated renewal, set calendar reminders 60 days before expiration to renew manually.
Test cipher suite strength. Modern TLS supports multiple cipher suites with varying levels of security. Weak cipher suites (like those using single DES or 40-bit encryption) should be disabled. SSL Labs will flag weak suites in your report. Most modern hosting platforms let you configure which cipher suites are enabled through their control panel or configuration files. Disable anything older than TLS 1.2—ideally, only support TLS 1.3.
Certificate Transparency and Monitoring
Certificate transparency logs are public records of every SSL certificate issued for your domain. While this sounds dangerous, it's actually a security feature: it prevents bad actors from silently issuing fraudulent certificates for your domain. However, it also means anyone can check which certificates exist for your domain.
Monitor certificate transparency logs for your domain using tools like crt.sh or Censys. These tools show you all certificates issued for your domain and any subdomains. You'll likely find certificates you didn't realize you had: old staging environments, defunct integrations, test instances. Each certificate you find should be intentional. If you find unexpected certificates, investigate immediately—they might indicate a compromised account or unauthorized certificate issuance.
Set up automatic alerts for new certificates issued for your domain. Most certificate transparency monitoring services (including crt.sh) offer email notifications. Alerts help you catch fraudulent certificates quickly, before they can be used in attacks. When you get an alert, verify that the certificate is legitimate and came from your organization. If it didn't, notify your certificate authority and registrar immediately.
Implement CAA (Certification Authority Authorization) records on your domain to control which certificate authorities can issue certificates for you. This prevents attackers from obtaining fraudulent certificates even if they compromise your DNS or domain registrar. A basic CAA record is: 0 issue "letsencrypt.org" or 0 issue "your-ca.com" depending on your certificate provider. This tells all certificate authorities except the specified ones that they're not authorized to issue certificates for your domain.
Common SSL Certificate Vulnerabilities
Expired certificates are surprisingly common. A surprising number of production services have expired certificates, often discovered only when users report browser warnings. This is inexcusable in the age of free, automated certificate renewal. Let's Encrypt offers free certificates with 90-day validity and automatic renewal. Digicert and other commercial CAs also support automated renewal. There's no excuse for manually managing certificate renewal or letting certificates expire.
Self-signed certificates should never be used for public-facing services. They trigger browser warnings, break functionality, and provide no authentication benefits. Even for internal services, using self-signed certificates is poor practice—use a private CA or free services like Let's Encrypt instead.
Weak private keys (like 1024-bit RSA, which was deprecated years ago) should be replaced with 2048-bit or higher. Check your certificate properties to verify key strength. Most modern services enforce minimum key strength, but older systems might still use weak keys.
Reused certificates across multiple domains (wildcard or multi-domain certificates) are convenient but create concentration of risk. If the private key is compromised, all domains are affected. Using individual certificates per domain (which Let's Encrypt makes free and automatic) reduces risk.
Ongoing Certificate Management
Implement a certificate inventory: a spreadsheet or database of all SSL certificates you use, their domains, expiration dates, and renewal dates. Update it quarterly. Automate renewal for all certificates using services that support it. For certificates that can't be automated, set reminders 90 days before expiration.
Review your SSL Labs grade quarterly. Keep it at A or above. Changes in security standards might require updates to your cipher suite configuration or protocol versions—a certificate that got an A five years ago might score lower today as standards evolve. Stay current.
Monitor certificate transparency logs for your domain continuously. Verify that all certificates in the logs are legitimate. Investigate any that aren't.
SSL certificate security is foundational for website security. While certificates alone won't prevent breaches, improper certificate management creates unnecessary vulnerabilities and damages user trust when users encounter certificate warnings or expired certificates. Getting this right requires minimal ongoing effort and costs nothing with modern certificate providers.
RedRadar provides comprehensive SSL certificate audits that test your certificate configuration, verify strength against current standards, check certificate transparency logs for unauthorized certificates, and identify any misconfigurations in your HTTPS setup.
Your browser shows a padlock icon. Your URL starts with https://. You probably think your site is secure. But here's what most startup CTOs don't realize: an SSL certificate is one of the smallest pieces of your security puzzle — and over-relying on it leaves real gaps that attackers exploit every day.
Let's break down what an SSL certificate actually does, what a proper SSL security check looks like, and what you should be monitoring beyond just "does it expire?"
What SSL Actually Does (And Doesn't Do)
An SSL/TLS certificate does one thing well: it encrypts data moving between a user's browser and your server. That means an attacker sitting on the same coffee shop Wi-Fi can't read the traffic. That's it. That's the job.
What SSL doesn't do:
- It doesn't verify your code is safe
- It doesn't protect your database
- It doesn't stop phishing attacks against your users
- It doesn't prevent attackers from reaching your server — it just encrypts what they see in transit
- It doesn't guarantee the site they're connecting to is actually yours
Google made HTTPS a ranking signal in 2014, so almost every site has an SSL cert now — including malicious ones. The padlock means the connection is encrypted. It doesn't mean the site is trustworthy or safe.
What to Actually Check in an SSL Security Review
A real SSL certificate security check goes beyond verifying expiry. Here's the checklist that matters:
1. Certificate Expiry (Yes, Still)
SSL certificates expire. When they do, browsers throw scary red warnings and users bounce. Set up automated monitoring — tools like UptimeRobot, StatusCake, or a simple cron job can alert you 30 days out. Many companies still get caught by this. Don't be one of them.
2. Cipher Suite and Protocol Version
Old TLS versions (TLS 1.0, TLS 1.1) and weak cipher suites are exploitable. Run your domain through SSL Labs — it's free and gives you an A–F grade. You want an A. If you're seeing B or below, you likely have deprecated protocols enabled.
Fix: Disable TLS 1.0 and 1.1 in your server config. Enforce TLS 1.2 minimum; TLS 1.3 where possible.
3. HTTP Strict Transport Security (HSTS)
Even with HTTPS, someone can downgrade a connection to HTTP before the secure handshake happens — this is called an SSL stripping attack. HSTS prevents it by telling browsers "never connect to this domain over HTTP, ever."
Check for the Strict-Transport-Security header with a max-age of at least 31536000 (one year). If it's missing, you're vulnerable to downgrade attacks.
4. Mixed Content
If your HTTPS page loads resources (images, scripts, stylesheets) over HTTP, browsers block them or show warnings. More importantly, those HTTP resources can be intercepted. Scan for mixed content with Chrome DevTools or a tool like WhyNoPadlock.
5. Certificate Transparency Monitoring
Here's the one most startups miss: Certificate Transparency (CT) logs are public records of every certificate ever issued for your domain. Attackers use this. They watch CT logs for new certificates on your domains to identify phishing targets, subdomains you've launched, and staging environments you forgot about.
You should be watching too. Tools like crt.sh or automated CT monitoring will alert you any time a new certificate is issued for your domain — including unauthorized ones. If you see a cert you didn't issue, someone may be setting up a phishing site mimicking your domain.
6. Wildcard Certificate Scope Creep
Many startups use a single wildcard cert (*.company.com) for convenience. The problem: if any subdomain running under that wildcard is compromised, the attacker has a valid cert for all of them. Wildcards also don't cover your root domain (company.com) by default — a common surprise.
Review what's actually covered by your wildcard cert versus what you think is covered.
7. Certificate Authority (CA) Selection
Not all CAs are equal. Some have been compromised or distrusted by browsers in the past. Stick to well-known CAs (Let's Encrypt, DigiCert, Sectigo). If you're using a CA your team picked years ago and nobody remembers why, audit it.
The Bigger Picture: SSL Is Table Stakes
Here's the honest truth: if SSL is the most sophisticated security check your company does, you have a security gap. The padlock is entry-level. It's expected. Customers assume it's there.
What they don't know — and what attackers do know — is everything that SSL doesn't protect:
- Your exposed subdomains running old software
- Open ports on your servers that shouldn't be public
- Leaked API keys in your GitHub repos
- Your company's email domains vulnerable to spoofing
- Third-party services connected to your infrastructure with weak configs
This is what external attack surface analysis covers — looking at your company from the outside, the way a threat actor would, and identifying what's actually exposed. An SSL grade of A+ on SSL Labs is a good sign. But it's one data point in a much larger picture.
Practical Takeaways
- Run an SSL Labs scan today. It takes 90 seconds and shows you your real TLS posture.
- Set up certificate expiry monitoring. Automate it — don't rely on memory.
- Enable HSTS with at least a one-year max-age.
- Subscribe to CT log alerts for your domain using crt.sh or a monitoring service.
- Audit your wildcard cert coverage — know exactly what it covers and what it doesn't.
- Fix mixed content if your SSL Labs scan or browser console shows warnings.
SSL is necessary. It's not sufficient. If you want to know what else is exposed about your company's digital footprint — subdomains, open services, leaked credentials, reputation issues — that's exactly what we check at RedRadar.
Get a full external security check for your company at redradar.aisolutionsdev.com/order/. We look at everything an attacker would see — not just the padlock.