TLS/SSL Security Assessment: How to Check, Understand, and Fix Your TLS Grade

A penetration tester runs a TLS assessment against your domain. The scan takes ninety seconds. The result comes back: Grade B. The report lists TLS 1.0 still enabled, two weak cipher suites, no HSTS header, and a certificate chain issue on one of your subdomains.

None of these are difficult to fix. But collectively, they tell a story — one that every attacker reads fluently. A B grade means your TLS configuration has not been reviewed recently. And if TLS has not been reviewed, what else has been left unattended? The exposed technologies, the discoverable employee emails, the forgotten subdomains running outdated software — they paint a picture of an organization that has not audited its external attack surface.

TLS security is not just about encryption. It is a signal. An A+ grade tells the world that someone is paying attention. A poor grade tells them no one is.

This guide covers how TLS grading works, what each grade actually means, how to identify and fix the most common issues that drag grades down, the differences between TLS 1.2 and TLS 1.3, and how to move from wherever you are today to an A+ configuration — permanently.

What Is a TLS/SSL Security Assessment?

A TLS security assessment is an automated evaluation of how a server handles encrypted connections. It examines the certificate, the supported protocols, the cipher suites, and the presence (or absence) of protections against known attacks. The result is a letter grade — from A+ (best-in-class) to F (critically broken) — that summarizes the overall security posture of the TLS configuration.

The industry-standard grading system, originally popularized by Qualys SSL Labs, uses letter grades from A+ to F. These grading criteria are regularly updated to reflect the evolving threat landscape — most recently in 2025, when the criteria were tightened to penalize configurations that still support TLS 1.0 and TLS 1.1.

Why TLS Grades Matter

A TLS grade is not just a vanity metric. It directly reflects:

• Whether data in transit is actually protected. A poor grade often means attackers on the same network can intercept or modify communications between your users and your servers.
• Compliance posture. PCI DSS 4.0 requires TLS 1.2 or higher. HIPAA mandates encryption in transit. SOC 2 auditors will flag weak TLS configurations. A grade below A is a compliance finding waiting to happen.
• Customer trust. Browsers now show security indicators based on certificate validity. Users who see certificate warnings will leave — and they should.
• Supply chain risk. If you are a vendor or partner, your clients’ security teams will assess your TLS grade as part of vendor risk management. A poor grade can block deals.

What Gets Assessed

A comprehensive TLS assessment evaluates multiple layers:

Understanding SSL Labs Grades: What Each One Means

SSL Labs assigns grades using a scoring system that weighs four categories: protocol support (30%), key exchange (30%), cipher strength (30%), and a set of qualitative adjustments for vulnerabilities, warnings, and best practices. The final grade is then capped or modified based on critical findings.

Here is what each grade range actually means in practice:

Special Grade: M (Hostname Mismatch)

A grade of M means the certificate’s Common Name (CN) or Subject Alternative Name (SAN) does not match the hostname being tested. This is surprisingly common with subdomains — a wildcard certificate for *.example.com does not cover sub.sub.example.com, and a certificate issued for www.example.com does not cover the bare domain example.com. Hostname mismatches cause browser warnings and are effectively the same as having no certificate at all from a user’s perspective.

The 2025 Grading Criteria Update

In 2025, SSL Labs updated its grading criteria to reflect current security standards. The most significant changes:

• TLS 1.0 and TLS 1.1 now cap the grade at B. Previously, supporting legacy protocols resulted in a deduction but could still allow an A grade in some configurations. Now, any server that accepts TLS 1.0 or 1.1 connections cannot receive an A grade, period.
• RSA key exchange without forward secrecy is penalized more heavily. Static RSA key exchange allows an attacker who obtains the server’s private key to retroactively decrypt all past traffic. Forward secrecy (via ECDHE or DHE) prevents this.
• HSTS is now required for A+. HTTP Strict Transport Security tells browsers to always use HTTPS, preventing downgrade attacks. Without HSTS, the maximum grade is A.

These changes mean many servers that previously had A grades now show B or lower — not because their configuration changed, but because the bar was raised.

TLS 1.2 vs TLS 1.3: What Changed and Why It Matters

One of the most common questions in TLS security is whether TLS 1.2 is still secure and when to upgrade to TLS 1.3. The short answer: TLS 1.2 is secure when configured correctly, but TLS 1.3 is objectively better in every measurable way.

What Is TLS 1.2?

TLS 1.2, published in 2008 (RFC 5246), is the most widely deployed encryption protocol on the internet. It introduced support for AEAD cipher suites (like AES-GCM) and SHA-256, replacing the weaker algorithms from TLS 1.1 and earlier. Nearly every server and client on the internet supports TLS 1.2.

Is TLS 1.2 secure? Yes — when properly configured. The protocol itself is not broken. The problems arise from the flexibility it offers: TLS 1.2 supports a huge range of cipher suites, including many that are now considered weak. A server running TLS 1.2 with only AEAD cipher suites and forward secrecy is perfectly secure. A server running TLS 1.2 with RC4, CBC-mode ciphers without AEAD, and static RSA key exchange is not.

Is TLS 1.2 deprecated? No. As of 2026, TLS 1.2 is still widely supported and accepted by all major compliance frameworks. However, TLS 1.0 and TLS 1.1 are deprecated — officially retired by RFC 8996 in 2021. Major browsers dropped TLS 1.0/1.1 support in 2020. If you still have TLS 1.0 or 1.1 enabled, you are supporting protocols that no legitimate client needs and that only attackers benefit from.

What Changed in TLS 1.3

TLS 1.3, published in 2018 (RFC 8446), is a fundamental redesign — not just an incremental update. It removes decades of accumulated complexity and eliminates entire categories of attacks.

The five cipher suites in TLS 1.3 are:

TLS_AES_256_GCM_SHA384
TLS_AES_128_GCM_SHA256
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_CCM_SHA256
TLS_AES_128_CCM_8_SHA256

All use AEAD encryption. All use forward secrecy. There is no option to negotiate a weak configuration — you cannot misconfigure TLS 1.3. This alone makes it a massive security improvement.

Should You Disable TLS 1.2?

Not yet. While TLS 1.3 is superior, approximately 1-2% of internet traffic still requires TLS 1.2. Some enterprise clients, older IoT devices, and government systems have not yet upgraded. The recommended configuration is:

• Enable TLS 1.3 and TLS 1.2
• Disable TLS 1.1, TLS 1.0, SSL 3.0, and SSL 2.0
• Configure TLS 1.2 with only AEAD cipher suites and forward secrecy

This gives you the best of both worlds: maximum security for modern clients via TLS 1.3, backward compatibility with TLS 1.2 for older clients, and zero legacy protocol exposure.

The TLS Vulnerabilities That Kill Your Grade

Every TLS vulnerability that SSL Labs tests for has a specific technical mechanism and a real-world exploitation path. Understanding them is essential for web application security best practices — not just for fixing your grade, but for understanding what an attacker can actually do if your server is vulnerable.

Heartbleed (CVE-2014-0160)

What it is: A buffer over-read bug in OpenSSL’s heartbeat extension. An attacker can read up to 64KB of server memory per request — potentially including private keys, session tokens, passwords, and any other data in memory.

Impact: Catastrophic. If your server was vulnerable to Heartbleed and the private key was leaked, all past encrypted traffic (unless forward secrecy was used) could be decrypted. The private key must be revoked and reissued.

Fix: Update OpenSSL to 1.0.1g or later. Regenerate private keys. Reissue certificates. Revoke old certificates.

Grade impact: Automatic F.

POODLE (CVE-2014-3566)

What it is: An attack on SSL 3.0’s CBC cipher mode. The attacker forces a protocol downgrade from TLS to SSL 3.0, then exploits padding oracle behavior to decrypt one byte at a time.

Impact: An attacker on the same network can decrypt session cookies and hijack authenticated sessions. The POODLE TLS variant (CVE-2014-8730) affects some TLS 1.0/1.1 implementations as well.

Fix: Disable SSL 3.0 entirely. For TLS POODLE, upgrade your TLS library or disable CBC cipher suites.

Grade impact: Automatic F for SSL 3.0 POODLE. Significant deduction for TLS POODLE.

BEAST (CVE-2011-3389)

What it is: A chosen-plaintext attack on TLS 1.0’s CBC cipher mode. The attacker can decrypt data by injecting chosen content into the encrypted stream and observing the resulting ciphertext.

Impact: Practical exploitation requires man-in-the-middle position and is partially mitigated by the 1/n-1 record splitting countermeasure in modern browsers. However, the underlying vulnerability remains if TLS 1.0 with CBC ciphers is supported.

Fix: Disable TLS 1.0 or disable CBC cipher suites when using TLS 1.0. Moving to TLS 1.2+ with AEAD ciphers eliminates the attack entirely.

Grade impact: Warning flag, caps grade depending on configuration.

DROWN (CVE-2016-0800)

What it is: An attack that exploits servers supporting SSLv2 to decrypt TLS connections. Even if your HTTPS server does not support SSLv2, if any other server uses the same RSA private key and supports SSLv2, all your TLS traffic is vulnerable.

Impact: Allows decryption of TLS connections using a different server’s SSLv2 support. This is a cross-server attack — your server does not need to support SSLv2 to be vulnerable.

Fix: Disable SSLv2 on all servers using the same private key. Ensure no certificate sharing across servers with different protocol support.

Grade impact: Automatic F.

FREAK (CVE-2015-0204) and Logjam (CVE-2015-4000)

What they are: Both exploit legacy “export-grade” cryptography. FREAK targets RSA export ciphers (512-bit), Logjam targets DHE export parameters (512-bit). An attacker forces a downgrade to the weak export cipher and then breaks the reduced-strength encryption.

Impact: Man-in-the-middle attacker can decrypt communications. Logjam is particularly dangerous because 512-bit DH parameters can be precomputed, making the attack practical against many servers simultaneously.

Fix: Disable all export cipher suites. Use 2048-bit or larger DH parameters. Prefer ECDHE over DHE.

Grade impact: Significant deduction, typically caps at C or lower.

ROBOT (Return Of Bleichenbacher’s Oracle Threat)

What it is: A modern variant of Bleichenbacher’s 1998 attack on RSA PKCS#1 v1.5 padding. The attacker sends specially crafted ciphertexts and uses the server’s error responses to progressively decrypt the RSA-encrypted premaster secret.

Impact: Allows decryption of RSA key exchange sessions. Requires significant computational effort but is practical against high-value targets.

Fix: Disable RSA key exchange entirely. Use only ECDHE or DHE key exchange. This also provides forward secrecy.

Grade impact: Significant deduction, typically caps at B or lower.

How to Check Your TLS Configuration

Manual Testing with SSL Labs

The simplest approach is the Qualys SSL Labs Server Test. Enter your domain, wait 60-90 seconds, and get a detailed report. The report shows:

• Overall grade and subscores
• Certificate details and chain validation
• Protocol support matrix
• Cipher suite list with strength ratings
• Vulnerability scan results
• Handshake simulation for various clients

This works well for a single domain. But most organizations have dozens or hundreds of hosts — the primary domain, subdomains, APIs, staging environments, internal tools exposed to the internet. Testing each one manually is not practical.

Command-Line Testing

For more control and scriptability, use testssl.sh — an open-source command-line tool that runs comprehensive TLS assessments locally:

# Install testssl.sh
git clone https://github.com/drwetter/testssl.sh.git

# Run a full assessment
./testssl.sh example.com

# Test specific checks
./testssl.sh --protocols example.com     # Protocol support only
./testssl.sh --vulnerabilities example.com  # Known CVEs only
./testssl.sh --cipher-per-proto example.com  # Ciphers by protocol

You can also use openssl for quick checks:

# Check supported TLS versions
openssl s_client -connect example.com:443 -tls1_3
openssl s_client -connect example.com:443 -tls1_2
openssl s_client -connect example.com:443 -tls1_1  # Should fail if properly configured

# View certificate details
openssl s_client -connect example.com:443 -servername example.com | openssl x509 -text -noout

# Check specific cipher
openssl s_client -connect example.com:443 -cipher RC4-SHA  # Should fail

The Problem with Testing at Scale

Here is where manual testing falls apart. A typical organization might have:

• The main domain (example.com)
• Several subdomains (app.example.com, api.example.com, mail.example.com)
• Staging and development environments (staging.example.com, dev.example.com)
• Legacy services that were supposed to be decommissioned (old-portal.example.com)
• Third-party services pointed at via CNAME records
• CDN endpoints with their own TLS termination

Each of these might have a different TLS configuration. The main domain might have an A+ grade while a forgotten subdomain runs TLS 1.0 with a self-signed certificate. Attackers do not target your strongest point — they find and exploit the weakest.

This is exactly why automated, comprehensive assessment matters. You need to know the TLS posture of every host associated with your domain, not just the ones you remember to test.

How to Fix Common TLS Issues and Improve Your Grade

Every point below is a concrete configuration change. The examples use nginx and Apache syntax since they cover the vast majority of web servers, but the principles apply to any TLS termination point — HAProxy, Caddy, AWS ALB, Cloudflare, or your CDN provider.

1. Disable Legacy Protocols

This is the single most impactful change. Remove TLS 1.0, TLS 1.1, SSL 3.0, and SSL 2.0.

Nginx:

ssl_protocols TLSv1.2 TLSv1.3;

Apache:

SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1

HAProxy:

ssl-default-bind-options ssl-min-ver TLSv1.2

After making this change, verify with:

# These should fail (connection refused or handshake error)
openssl s_client -connect yourdomain.com:443 -tls1
openssl s_client -connect yourdomain.com:443 -tls1_1

# This should succeed
openssl s_client -connect yourdomain.com:443 -tls1_2

2. Configure Strong Cipher Suites

Remove weak and insecure ciphers. Keep only AEAD ciphers with forward secrecy.

Nginx (recommended cipher string):

ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
ssl_prefer_server_ciphers off;  # Let client choose (TLS 1.3 ignores this)

Apache:

SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305
SSLHonorCipherOrder off

What this removes:

• RC4 ciphers (broken)
• CBC-mode ciphers (BEAST, Lucky13, POODLE TLS)
• 3DES (Sweet32 attack, only 112-bit effective strength)
• Static RSA key exchange (no forward secrecy, ROBOT attack)
• Export-grade ciphers (FREAK, Logjam)
• NULL ciphers (no encryption at all)

3. Enable HSTS (HTTP Strict Transport Security)

HSTS tells browsers to always use HTTPS for your domain, preventing SSL stripping attacks and accidental HTTP connections.

Nginx:

add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

Apache:

Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"

Important: Start with a short max-age (like 300 seconds) to verify everything works. HSTS is enforced by the browser for the entire max-age period — if you set it to 2 years and something breaks, you cannot easily undo it. Once confirmed working, increase to the recommended 63072000 seconds (2 years) and add preload for inclusion in browser HSTS preload lists.

The includeSubDomains directive is especially important. Without it, an attacker could target http://sub.yourdomain.com — a subdomain without HSTS — to perform a session hijack even if the main domain is protected.

4. Enable OCSP Stapling

OCSP (Online Certificate Status Protocol) allows clients to verify that your certificate has not been revoked. Without stapling, the client makes a separate request to the CA’s OCSP server — adding latency and a privacy leak. With stapling, your server includes the OCSP response in the TLS handshake.

Nginx:

ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 1.1.1.1 valid=300s;
resolver_timeout 5s;

Apache:

SSLUseStapling on
SSLStaplingResponderTimeout 5
SSLStaplingReturnResponderErrors off
SSLStaplingCache shmcb:/var/run/ocsp(128000)

5. Use Strong DH Parameters

If you support DHE cipher suites (alongside ECDHE), use at least 2048-bit DH parameters. The default 1024-bit parameters are vulnerable to precomputation attacks (Logjam).

# Generate 2048-bit DH parameters (can take a few minutes)
openssl dhparam -out /etc/ssl/dhparams.pem 2048

Nginx:

ssl_dhparam /etc/ssl/dhparams.pem;

Better yet, use only ECDHE key exchange and remove DHE entirely. ECDHE is faster and does not require custom DH parameters.

6. Fix Certificate Chain Issues

A common cause of trust failures is an incomplete certificate chain. Your server must send the full chain — the server certificate plus all intermediate certificates — but not the root certificate.

# Check your chain
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com

# Look for "verify error" in the output
# A complete chain should show: "Verify return code: 0 (ok)"

Nginx (concatenated certificate file):

ssl_certificate /etc/ssl/yourdomain-fullchain.pem;  # Server cert + intermediates
ssl_certificate_key /etc/ssl/yourdomain-key.pem;

Most CAs provide the intermediate certificates separately. Concatenate them in order: server certificate first, then intermediates, root excluded.

7. The Complete A+ Configuration

Here is a complete nginx TLS configuration that achieves an A+ grade:

server {
    listen 443 ssl http2;
    server_name yourdomain.com;

    # Certificate
    ssl_certificate     /etc/ssl/yourdomain-fullchain.pem;
    ssl_certificate_key /etc/ssl/yourdomain-key.pem;

    # Protocols: TLS 1.2 and 1.3 only
    ssl_protocols TLSv1.2 TLSv1.3;

    # Cipher suites: AEAD only, forward secrecy only
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
    ssl_prefer_server_ciphers off;

    # HSTS (2 years, includes subdomains, preload ready)
    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

    # OCSP stapling
    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 8.8.8.8 1.1.1.1 valid=300s;
    resolver_timeout 5s;

    # Session configuration
    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:10m;
    ssl_session_tickets off;  # Disable for better forward secrecy

    # ... your application configuration
}

Apply this configuration, reload nginx (nginx -t && nginx -s reload), wait a few minutes for SSL Labs cache to expire, and run the test. You should see A+.

How to Enable TLS 1.2 (and 1.3) on Common Platforms

Not everyone manages raw nginx or Apache configurations. Here is how to enable modern TLS on common platforms and environments:

AWS Application Load Balancer (ALB)

AWS provides predefined security policies. Select a modern policy:

# Recommended: TLS 1.2+ with strong ciphers
ELBSecurityPolicy-TLS13-1-2-2021-06

# For TLS 1.3 only (if all clients support it)
ELBSecurityPolicy-TLS13-1-3-2021-06

Set this in the ALB listener configuration in the AWS Console or via CloudFormation/Terraform.

Cloudflare

Cloudflare manages TLS termination at the edge. In the SSL/TLS settings:

1. Set Minimum TLS Version to TLS 1.2
2. Enable TLS 1.3 (on by default)
3. Enable Always Use HTTPS
4. Enable HSTS with a long max-age

Windows Server (IIS)

How to enable TLS 1.2 on Windows Server — this is a common search because Windows does not enable TLS 1.2 by default on older versions:

# Enable TLS 1.2
New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server' -Force
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server' -Name 'Enabled' -Value '1' -PropertyType 'DWord'
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server' -Name 'DisabledByDefault' -Value '0' -PropertyType 'DWord'

# Disable TLS 1.0
New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server' -Force
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server' -Name 'Enabled' -Value '0' -PropertyType 'DWord'

# Disable TLS 1.1
New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server' -Force
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server' -Name 'Enabled' -Value '0' -PropertyType 'DWord'

A server restart is required after registry changes. Alternatively, use the IIS Crypto GUI tool which simplifies the process.

Let’s Encrypt Certificate Renewal

If you use Let’s Encrypt (via Certbot), certificate strength is handled automatically — Let’s Encrypt issues 2048-bit RSA or ECDSA P-256 certificates. The protocol and cipher configuration is still your server’s responsibility.

# Verify auto-renewal is working
certbot renew --dry-run

# Force renewal with ECDSA key (smaller, faster)
certbot certonly --key-type ecdsa --elliptic-curve secp256r1 -d yourdomain.com

ECDSA certificates are smaller and faster than RSA certificates while providing equivalent or better security. If your client base supports it (all modern browsers do), ECDSA is the better choice.

TLS Security Across Your Entire Attack Surface

Here is where most TLS guides stop — they tell you how to configure one server and call it done. But your TLS security is only as strong as your weakest host.

Consider a real scenario: Your main domain example.com has a perfect A+ configuration. But during subdomain enumeration, twenty subdomains are discovered. Three of them — a staging environment, an internal dashboard exposed to the internet, and an old marketing microsite — are running TLS 1.0 with self-signed certificates. An attacker who finds these subdomains (and they will — subdomain discovery is OSINT 101) now has three entry points with weak encryption.

The risk multiplies when you factor in other attack surface elements:

• Weak TLS + exposed employee emails: Intercepted traffic from a weak subdomain may contain internal communications, credentials, or session tokens.
• Weak TLS + discoverable technology stack: An attacker who knows you are running WordPress 5.9 on a subdomain with TLS 1.0 can chain a known WordPress CVE with traffic interception.
• Weak TLS + spoofable domain: An attacker can intercept MTA-to-MTA email traffic if the mail server’s TLS is weak, complementing email spoofing with actual message interception.
• Weak TLS on a subdomain + shared session cookies: If cookies are set for .example.com (the parent domain), a weak subdomain can be used to intercept cookies for the main application.

This is why TLS assessment must be part of a broader external attack surface management strategy — not a standalone check on your homepage.

How Cyborux Includes TLS in Domain Reconnaissance

Checking your TLS grade manually is easy for one domain. But TLS is rarely the only thing you need to worry about. An organization’s real exposure is the combination of TLS weaknesses, spoofable emails, exposed employee data, leaked documents, and discoverable infrastructure — all feeding into the same attacker playbook.

Cyborux includes TLS assessment as part of its automated domain reconnaissance. When you enter a domain, the platform performs a high-quality TLS analysis alongside all other operations — subdomain enumeration, email harvesting, technology fingerprinting, breach checking, and more. Your TLS grade appears on the dashboard, giving you an immediate signal of your domain’s encryption posture without running separate tools.

What you see. The dashboard displays your domain’s overall TLS grade — from A+ (exceptional) to F (critically broken). This gives you the same answer an auditor, client, or attacker would get if they assessed your domain’s encryption — at a glance, with no manual testing required.

Where it fits. The TLS grade is one data point in a broader risk picture. A domain with an A+ TLS grade but no DMARC enforcement, dozens of exposed employee emails, and an outdated CMS on a subdomain still has a significant attack surface. Conversely, a poor TLS grade on a domain with otherwise strong security is a clear, actionable remediation priority. Seeing everything together — in one scan, on one dashboard — is what makes the difference between isolated checks and actual visibility.

Detailed findings in the report. For organizations that need more depth, the Cyborux report includes the full TLS assessment details: vulnerability findings (Heartbleed, POODLE, BEAST, DROWN, FREAK, Logjam, ROBOT, and others), supported protocols, and risk severity. This gives security teams and consultants the specifics they need to prioritize and fix configuration issues.

The entire assessment runs automatically. Enter a domain, wait a few minutes, and see your TLS grade alongside your complete external attack surface. No CLI tools, no separate scans, no context switching between security tools.

The TLS Security Checklist

Use this as a quick reference to validate your TLS configuration:

Frequently Asked Questions

What is TLS 1.2 and is it still secure?

TLS 1.2 is a cryptographic protocol published in 2008 that provides encrypted communication between clients and servers. Yes, TLS 1.2 is still secure when properly configured — specifically, when using only AEAD cipher suites (AES-GCM, ChaCha20-Poly1305) with forward secrecy (ECDHE key exchange). The protocol itself is not deprecated. However, TLS 1.2 allows many weak configurations, so security depends entirely on how it is set up. TLS 1.3 is recommended as the primary protocol, with TLS 1.2 as a fallback.

Is TLS 1.2 deprecated or end of life?

No. TLS 1.2 is not deprecated and has no announced end-of-life date as of 2026. What is deprecated is TLS 1.0 and TLS 1.1, which were officially retired by RFC 8996 in March 2021. All major browsers dropped TLS 1.0/1.1 support in 2020. PCI DSS 4.0 requires TLS 1.2 or higher. There is no industry movement to deprecate TLS 1.2 yet, though TLS 1.3 is the clear future direction.

What is the difference between TLS 1.2 and TLS 1.3?

TLS 1.3 is faster (1 round-trip handshake vs 2), more secure by design (only 5 strong cipher suites vs 300+ in TLS 1.2), and eliminates entire attack categories (BEAST, POODLE, ROBOT are impossible in TLS 1.3). TLS 1.3 mandates forward secrecy and removes all legacy algorithms. The tradeoff: TLS 1.3 is less compatible with very old clients. See the detailed comparison table above.

How do I enable TLS 1.2 on my server?

The method depends on your platform. For nginx: set ssl_protocols TLSv1.2 TLSv1.3;. For Apache: set SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1. For Windows Server/IIS: modify the registry under HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server to set Enabled=1. For AWS ALB: select the ELBSecurityPolicy-TLS13-1-2-2021-06 security policy. See the platform-specific sections above for complete instructions.

How do I get an A+ on SSL Labs?

An A+ requires: (1) TLS 1.2 and 1.3 only, no legacy protocols, (2) strong AEAD cipher suites with forward secrecy, (3) valid certificate from a trusted CA with complete chain, (4) HSTS header with a long max-age (this is what separates A from A+), (5) no known vulnerabilities, and (6) ideally OCSP stapling and disabled session tickets. The complete nginx configuration in this guide achieves A+.

What does a grade of T mean?

A grade of T means “trust issues” — the server’s certificate is not trusted by the assessment tool. This usually means the certificate is self-signed, expired, has a hostname mismatch, or has an incomplete chain (missing intermediate certificates). Fix the certificate issue and the actual grade (based on protocol and cipher configuration) will be revealed.

Should I disable TLS 1.2 and use only TLS 1.3?

Not yet. While TLS 1.3 is the better protocol, approximately 1-2% of internet traffic still requires TLS 1.2 — including some enterprise clients, older mobile devices, and government systems. The recommended approach is to support both TLS 1.2 and TLS 1.3, with TLS 1.2 configured to use only strong cipher suites. Monitor your access logs for TLS version distribution before considering TLS 1.3-only.

How often should I reassess my TLS configuration?

At minimum, quarterly — and immediately after any infrastructure change (server migration, certificate renewal, CDN change, new subdomain deployment). TLS security is not static: grading criteria change, new vulnerabilities are discovered, and infrastructure drift can silently weaken configurations. Tools like Cyborux include TLS assessment as part of broader domain reconnaissance, so you can check your grade alongside other security findings without running separate scans.

Does Cloudflare/CDN handle TLS for me?

Partially. A CDN manages TLS termination between users and the CDN edge — but the connection between the CDN and your origin server is separate. If your origin uses “Flexible SSL” (HTTP to origin) or weak TLS, the CDN’s A+ grade at the edge is meaningless — traffic between the CDN and your server is unprotected or weakly protected. Always configure “Full (Strict)” mode and ensure your origin server also has strong TLS.

What about internal services — do they need TLS?

Yes. Zero-trust architecture principles require encryption for all traffic, including internal. An attacker who gains access to your internal network (via phishing, VPN compromise, or a vulnerable service) can intercept unencrypted internal traffic. Internal services should use TLS 1.2+ with certificates from an internal CA or Let’s Encrypt. The cost of setting up internal TLS is negligible compared to the risk of unencrypted internal communications.

Conclusion

TLS security is not a one-time configuration task. It is an ongoing practice — part of the same attack surface management discipline that covers email authentication, subdomain hygiene, technology exposure, and employee digital footprint.

The technical fixes are straightforward. Disable legacy protocols. Use strong ciphers. Enable HSTS. Keep certificates valid. Any competent administrator can achieve an A+ grade on their primary domain in an afternoon.

The hard part is maintaining that posture across every host, every subdomain, every service endpoint — especially the ones you have forgotten about. A single forgotten staging server running TLS 1.0 can undermine the security of your entire infrastructure. And attackers always find the forgotten ones first.

Check your TLS configuration today. Start with your main domain, then work through every subdomain and service endpoint you can find. Run your domain through Cyborux to see your TLS grade alongside your complete external attack surface — spoofable emails, breached credentials, exposed technologies, discovered subdomains, and more. No tools to install, results in minutes. Just the visibility you need to know whether your encryption is actually protecting anything — or just providing a false sense of security.

Your TLS grade is public information. Anyone can check it. Make sure the answer reflects the security posture you intend.