SSL Grade: What an A+ Rating Means and How to Get One

SSL grading tools like Qualys SSL Labs analyze your server's HTTPS configuration and assign a letter grade from A+ down to F. The grade is not a subjective opinion. It is a weighted score derived from three measurable properties: which TLS protocol versions the server supports, how the key exchange is negotiated, and which cipher suites are offered. On top of that base score, the system applies caps and deductions for specific vulnerabilities, misconfigurations, or missing security headers. An A+ means the server passed every check and went further by deploying HSTS with preload eligibility. An F means something is critically broken.

This guide explains the grading methodology in detail, walks through what each grade level actually requires, provides a concrete checklist for reaching A+, identifies the most common configurations that silently cost points, and includes server configuration examples you can deploy directly. If you want to see your current grade before reading further, run your domain through the SSL Grade tool and keep the result open.

How SSL Grading Works

The SSL Labs grading methodology, which most grading tools follow or adapt, evaluates a server's TLS configuration across three weighted categories. Each category produces a score from 0 to 100, and the final numeric score is a weighted combination. That numeric score maps to a letter grade, which then gets adjusted by caps and deductions for specific issues.

• Protocol support (30%). Scores which TLS versions the server accepts. TLS 1.3 scores highest, TLS 1.2 scores well. TLS 1.1 and 1.0 drag it down, and SSL 2.0 or 3.0 floor it. Offering only TLS 1.2 and 1.3 earns a perfect protocol score.
• Key exchange (30%). Measures key exchange strength. ECDHE with P-256 or P-384 scores highest. DHE with 2048-bit or larger groups scores well. Static RSA with no forward secrecy scores poorly because a compromised key would decrypt all past traffic.
• Cipher strength (40%). This is the heaviest category. It evaluates the symmetric encryption ciphers the server offers. AES-256-GCM and ChaCha20-Poly1305 score highest. AES-128-GCM scores well. CBC-mode ciphers score lower. 3DES, RC4, and export-grade ciphers score near zero.

After the three category scores produce a weighted total, SSL Labs applies hard caps and deductions. If the server does not support TLS 1.2 at all, the grade is capped at C regardless of the numeric score. If the server is vulnerable to a known exploit like Heartbleed, POODLE, or ROBOT, the grade drops to F. An expired or otherwise untrusted certificate results in a T (trust) modifier or an outright F. These caps override the numeric score because they represent conditions where the connection cannot be considered secure at any level.

What Each Grade Means

Each letter grade corresponds to a specific range of configurations and issues. Understanding what separates an A from a B, or a B from a C, makes it clear which changes will actually move your grade and which are cosmetic.

• A+ (exceptional). A clean A grade plus an HSTS header with a long max-age, includeSubDomains, and the preload directive. This signals the server uses strong TLS and actively prevents downgrade attacks.
• A (strong). Protocol support is modern (TLS 1.2 and/or 1.3 only), key exchange uses forward secrecy, cipher suites are strong, and there are no known vulnerabilities. The server may be missing HSTS or have a short max-age, which is the only thing separating it from A+.
• B (adequate but outdated). Functional but includes outdated elements. Typical causes: TLS 1.0 or 1.1 still enabled, some ciphers lack forward secrecy, or key exchange parameters are weaker than recommended. Works, but makes concessions to legacy clients.
• C (weak). Cipher suites or protocol features are known to be weak. Often means 3DES is still offered or key exchange parameters are below 2048 bits. Not immediately exploitable but would not withstand a motivated attacker.
• F (critical failure). A vulnerability makes the TLS connection fundamentally insecure. Includes Heartbleed, POODLE, DROWN, and ROBOT. An expired or untrusted certificate also results in an F or T grade.

Grades B through D represent a continuum of declining security posture. The key insight is that most servers land in B territory not because of a deliberate decision but because nobody revisited the TLS configuration after the initial setup. The protocols and ciphers that were reasonable in 2018 are liabilities in 2026.

The A+ Checklist

Reaching A+ is not about finding obscure settings. It is about executing a specific list of configuration changes, each of which addresses a concrete scoring criterion. The following steps are ordered by impact and dependency: earlier steps are prerequisites for later ones.

1. Enable TLS 1.2 and TLS 1.3 only. These are the only versions that score well. TLS 1.3 eliminates downgrade attacks and reduces latency, while TLS 1.2 covers clients that have not adopted 1.3. Together they support every modern browser and API client.
2. Disable TLS 1.0 and TLS 1.1. Both were deprecated by the IETF in RFC 8996. They are vulnerable to BEAST and POODLE and lack AEAD cipher support. Keeping them enabled caps your grade and exposes you to attacks with public exploit tooling.
3. Use forward secrecy ciphers only. Offer only ECDHE or DHE key exchange and remove static RSA suites. Forward secrecy ensures that a future key compromise cannot decrypt past sessions. This directly affects the key exchange score.
4. Add HSTS with max-age >= 31536000, includeSubDomains, and preload. This header tells browsers to only connect over HTTPS. One year is the minimum for preload eligibility. This single header is what separates an A from an A+.
5. Enable OCSP stapling. The server includes a CA-signed revocation status in the TLS handshake, so clients skip a separate OCSP request. Improves performance and privacy. Absence can trigger warnings or minor deductions.
6. Serve the correct certificate chain. Send the leaf and all intermediates in order. Missing intermediates cause trust failures in API clients, mobile apps, and older browsers. Use the SSL Certificate Checker to verify your chain.
7. Eliminate mixed content. Every resource (scripts, stylesheets, images, fonts) must load over HTTPS. A single HTTP resource triggers a mixed content warning. Not part of the SSL Labs grade directly, but essential for HSTS preload to be meaningful.

Common Configurations That Cost You Points

Most servers that score below A+ are not misconfigured in an obvious way. They have a valid certificate, they serve traffic over HTTPS, and they look fine in a browser. The points they lose come from defaults that were reasonable years ago but have not been updated. Here are the most frequent offenders.

• CBC cipher suites. CBC ciphers are susceptible to padding oracle attacks (Lucky13, POODLE variants) and score lower than AEAD alternatives. Many servers still include them from old defaults. Removing CBC and keeping only AEAD ciphers is the highest-impact cipher change.
• Missing HSTS header. Without Strict-Transport-Security, the server gets an A at best, never A+. Surprisingly many sites deploy perfect TLS but never add the one HTTP header that locks it in. The header must be served on every HTTPS response, not just the homepage.
• Short HSTS max-age. A max-age of 86400 (one day) does not qualify for preload and provides minimal protection. Browsers revert to allowing HTTP after the window expires. Set at least 31536000 (one year) with includeSubDomains and preload.
• RSA key exchange without ECDHE. Static RSA encrypts the session key with the server's public key. If the private key is compromised, all past sessions become decryptable. ECDHE generates fresh keys per session. Grading tools penalize missing forward secrecy heavily.
• SHA-1 in the certificate chain. SHA-1 is cryptographically broken. If any certificate in the chain uses SHA-1, the grade is capped. Modern CAs default to SHA-256, but legacy intermediates can appear if the server uses an outdated bundle.
• Missing intermediate certificates. The server sends only the leaf, expecting clients to figure out the chain. Desktop browsers mask this via cached intermediates, but mobile apps, API clients, and curl fail hard. SSL Labs catches it every time.

Server Configuration Examples

The following configurations achieve an A+ grade on SSL Labs. They restrict protocol versions to TLS 1.2 and 1.3, offer only AEAD ciphers with forward secrecy, enable OCSP stapling, and include the HSTS header with preload. Adapt the certificate paths and domain names to your environment.

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

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

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

    # Cipher suites: AEAD only, forward secrecy required
    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;

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

    # HSTS with preload (1 year)
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

    # Session configuration
    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:10m;
    ssl_session_tickets off;
}

<VirtualHost *:443>
    ServerName example.com

    SSLEngine on
    SSLCertificateFile    /etc/letsencrypt/live/example.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem

    # Protocol versions: TLS 1.2 and 1.3 only
    SSLProtocol -all +TLSv1.2 +TLSv1.3

    # Cipher suites: AEAD only, forward secrecy required
    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

    # OCSP stapling
    SSLUseStapling on
    SSLStaplingResponderTimeout 5
    SSLStaplingReturnResponderErrors off

    # HSTS with preload (1 year)
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
</VirtualHost>

# OCSP stapling cache (must be outside VirtualHost)
SSLStaplingCache shmcb:/var/run/ocsp(128000)

Two important notes on these configurations. First, ssl_prefer_server_ciphers (Nginx) and SSLHonorCipherOrder (Apache) are set to off. With TLS 1.3, cipher preference is always the client's choice, and with only strong AEAD ciphers in the list for TLS 1.2, server-side ordering adds no security benefit while reducing compatibility. Second, ssl_session_tickets is disabled because session tickets can undermine forward secrecy if the ticket key is not rotated frequently. If your infrastructure rotates ticket keys on a short schedule, you can re-enable them.

Beyond the Grade

An SSL grade is a snapshot. It tells you the state of your TLS configuration at the moment the test ran. It does not tell you what the grade will be next month, after a certificate renewal, an OS update that changes default cipher lists, or the disclosure of a new TLS vulnerability. Treating the grade as a one-time achievement is the mistake that leads to silent degradation.

Certificate rotation is the most obvious source of grade drift. Let's Encrypt certificates expire every 90 days. If the renewal process breaks and nobody notices, the grade drops to F the moment the certificate expires. ACME automation handles this well, but automation that fails silently is worse than manual renewal with calendar reminders because it creates false confidence.

New vulnerabilities are the second source of drift. When a new TLS attack is published and SSL Labs adds a check for it, servers that were previously graded A may drop overnight without any configuration change. This happened with POODLE in 2014, DROWN in 2016, and ROBOT in 2017. The only defense is monitoring: re-test regularly and subscribe to TLS security advisories.

Configuration drift is the third and most insidious source. A package update changes the default cipher list. A load balancer migration uses a different TLS termination profile. A new team member copies a configuration template from a blog post written in 2019. None of these changes trigger an alert, but each one can silently weaken the TLS posture.

The practical answer is continuous monitoring. Use the Domain Monitor to track your SSL configuration over time and receive alerts when something changes. Run periodic checks with the SSL Grade tool as part of your deployment pipeline. Feed Certificate Transparency data into your security workflow to catch unauthorized certificate issuance. And run the Domain Health check monthly to catch issues across DNS, SSL, and email authentication before they compound.

An A+ grade is worth achieving. It means your TLS configuration is strong today. But the grade is only as durable as the monitoring and maintenance process behind it. The servers that stay at A+ are the ones where someone is watching, not the ones where someone ran the test once and moved on.

Independent references: Review the SSL Labs Rating Guide for the complete scoring methodology and Mozilla's Server Side TLS guidelines for recommended configurations maintained by the Mozilla security team.