How to Get an A Grade in an SSL Server Test: A Practical Guide

Short answer: SSL server tests, such as the widely used Qualys SSL Labs test, grade your HTTPS configuration from A+ to F based on the certificate, supported protocol versions, key exchange and cipher strength, plus known vulnerabilities. To reach an A, serve a valid certificate with a complete chain, allow only TLS 1.2 and 1.3, use modern cipher suites with forward secrecy, and keep server software current. An A+ typically also requires a long-lived HSTS header. Most grade caps come from a handful of old settings that are quick to change.

Customers, partners and procurement teams increasingly run a quick SSL test on the websites they deal with, and a B or C grade raises questions even when the site works fine for everyone. The grade is also a convenient summary of whether your TLS configuration has kept up with current practice. This guide explains what these tests look at, which findings typically cap the grade, and how to fix each one on common servers.

What an SSL server test checks

Public test tools connect to your server many times, trying different protocol versions and cipher suites, and simulating a range of real browsers and devices. The report usually covers:

• Certificate: validity, trusted issuer, hostname match, key size, signature algorithm and chain completeness.
• Protocol support: which of SSL 2/3 and TLS 1.0–1.3 the server accepts.
• Key exchange and ciphers: whether connections use forward secrecy and strong, authenticated encryption.
• Known vulnerabilities: historical issues such as POODLE, Heartbleed, ROBOT or insecure renegotiation.
• Extras: HSTS, OCSP stapling, session resumption and handshake simulation for many clients.

The overall grade starts from sub-scores and is then capped by specific problems. That is why one outdated setting can drop an otherwise excellent server to B or worse. Grading criteria change over time as practices evolve, so a configuration that earned an A a few years ago may not today.

How to read the test report

A full report can run to several screens, and most of it confirms that things are fine. Read it in this order to find what matters quickly:

1. The summary box at the top. It shows the grade and, crucially, short notes explaining why the grade is capped – for example “This server supports TLS 1.0 and TLS 1.1. Grade capped to B.” Those notes are your to-do list.
2. Certificate section. Check the hostnames, the expiry date and the chain path. Any “extra download” or “incomplete” note means the chain needs fixing.
3. Protocols. Anything other than TLS 1.2 and 1.3 marked “Yes” should be switched off.
4. Cipher suites. Suites marked “weak” or “insecure” should be removed. Check whether forward secrecy is reported for all modern clients.
5. Handshake simulation. This shows which real browsers and devices can connect and with what settings. Use it to judge the impact of removing old options.
6. Protocol details. Vulnerability checks and HSTS status appear here.

If several servers answer for your domain, for example behind DNS round-robin, the test lists each IP address separately, and each can have a different grade.

Typical findings that cap the grade

How to fix the findings, step by step

Step 1: Get the certificate right

Everything else is secondary to a trusted, valid certificate. Check that it covers all hostnames, including www, that the server sends the intermediate certificates, and that the key is at least RSA 2048-bit or an ECDSA key (P-256 is a common, efficient choice). Certificates from Let’s Encrypt and other public CAs meet these requirements by default. With Certbot, make sure the server uses fullchain.pem, not cert.pem.

Step 2: Allow only modern protocol versions

Disable SSL 2, SSL 3, TLS 1.0 and TLS 1.1; enable TLS 1.2 and TLS 1.3.

# Nginx
ssl_protocols TLSv1.2 TLSv1.3;

# Apache
SSLProtocol -all +TLSv1.2 +TLSv1.3

If TLS 1.3 is not available, your OpenSSL or web server version is too old – which is worth fixing for its own sake.

Step 3: Use modern cipher suites

For TLS 1.2, allow only suites with ECDHE key exchange and authenticated encryption. A common, well-supported list looks like this in Nginx:

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;

Apache uses the same names in SSLCipherSuite. TLS 1.3 cipher suites are strong by design and rarely need configuring. Rather than maintaining lists by hand, many administrators use a reputable configuration generator that tracks current recommendations for each server and version. Note that removing CBC-mode suites entirely can exclude some very old clients; the handshake simulation in the test report shows exactly which clients would be affected.

Step 4: Keep software updated

Vulnerability findings almost always mean outdated server software, OpenSSL versions or appliance firmware. Apply updates from your operating system or vendor, restart the services, and re-test. On managed hosting, open a ticket with the test report attached; hosts can often fix server-wide TLS settings for all customers.

Step 5: Add HSTS for the A+

Once HTTPS works everywhere, add a Strict-Transport-Security header with a long max-age, typically at least six months to a year:

Strict-Transport-Security: max-age=31536000

Roll it out carefully: start with a short value, confirm nothing breaks, then increase it. Only add includeSubDomains when every subdomain supports HTTPS.

Step 6: Nice-to-have improvements

• OCSP stapling lets the server deliver certificate status information itself, saving clients a lookup. Note that some CAs are phasing out OCSP in favour of other revocation mechanisms, so check your CA’s current guidance.
• Session resumption speeds up repeat connections.
• ECDSA certificates, alone or alongside RSA, reduce handshake size and CPU load.
• HTTP/2, which browsers use only over TLS, improves loading performance on many sites.

A typical example: from B to A+

A common starting point for small business sites looks like this: a valid certificate from a free CA, a web server installed several years ago with its original TLS settings, and no HSTS. The test reports grade B with two notes – TLS 1.0 and 1.1 are supported, and some cipher suites without forward secrecy are accepted. The fix takes three changes: set the protocols line to TLS 1.2 and 1.3, replace the cipher list with a modern one, and reload. The re-test shows grade A. Adding an HSTS header with a one-year max-age, after a short trial period with a lower value, brings it to A+. In total this is usually less than an hour of work, most of it spent testing the site’s forms, checkout and integrations after each change.

Behind a CDN, test both sides

If your site sits behind a CDN, the public test grades the CDN’s edge configuration, not your server. That is usually good news – CDNs keep their TLS settings current – but it can hide a weak origin server. Set the CDN’s minimum TLS version and HTTPS options in its dashboard, and separately harden the origin: allow only modern protocols there too, use a valid certificate so the CDN can verify it, and, if possible, accept connections only from the CDN’s address ranges. Test the origin directly by its own hostname or IP address where the tool allows it.

Keep the grade over time

A grade is a snapshot. Server rebuilds, hosting migrations, new load balancers and changed grading criteria can all lower it later. Re-run the test after infrastructure changes and every few months, keep your TLS settings in version-controlled configuration so a rebuild does not reset them to defaults, and watch certificate expiry separately – an expired certificate turns any grade into a failure overnight.

How Site AI Audit helps

Site AI Audit complements a dedicated TLS test by checking what visitors and search engines experience: a valid SSL certificate and its expiry date, the HTTP to HTTPS redirect, security headers such as HSTS, and exposed software versions, along with SEO, speed and e-mail authentication. Paid plans monitor these weekly or daily and alert you when something breaks. Run a free check.

Related reading

• TLS 1.0 and 1.1 Are Obsolete: How to Disable Them Safely
• HSTS Explained: How to Enable Strict-Transport-Security Safely
• Incomplete SSL Certificate Chain: How to Find and Fix It

The bottom line

An A grade comes from a short list of fundamentals: a trusted certificate with a complete chain, only TLS 1.2 and 1.3, modern ciphers with forward secrecy, and current server software. HSTS takes you to A+. Fix the capping findings first, re-test, and repeat the test after every infrastructure change so the grade – and the protection behind it – stays where it should be.

BUJ

Does an A+ grade make my website secure?

It means your HTTPS configuration follows current best practice. It says nothing about vulnerable plugins, weak passwords or application bugs, which are separate parts of website security.

Why did my grade drop without any changes on my side?

Testing tools update their criteria as practices change, for example when older protocols or ciphers are downgraded. A server that has not been updated can therefore lose grades over time.

Will removing old ciphers block real visitors?

Rarely, for modern websites. The handshake simulation in the test report lists which browsers and devices would fail, so you can judge whether any matter for your audience.

Can I get an A grade on shared hosting?

Often yes, since many hosts use modern defaults. If the host still allows TLS 1.0 or weak ciphers server-wide, you may need to ask them to change it or consider a CDN in front of the site.

How often should I run an SSL server test?

After any server, hosting or CDN change, and every few months otherwise. Certificate expiry should be monitored continuously rather than through occasional tests.