How to Get an A+ SSL Rating

SSL grades are not just a vanity metric. An A+ rating from tools like SSL Labs signals that your server is correctly configured against a meaningful checklist — strong protocols, no known vulnerabilities, a complete certificate chain, proper OCSP handling, and reinforcing DNS controls. This guide explains what goes into that rating, what most servers get wrong, and exactly how to reach A+.

What SSL/TLS Is and Why It Matters

TLS (Transport Layer Security) is the cryptographic protocol that secures traffic between a client and a server. The older name — SSL (Secure Sockets Layer) — is technically obsolete; SSL 2.0 and 3.0 are long-dead and actively dangerous. Despite that, "SSL certificate" remains the common shorthand, and you will hear it throughout this guide.

When a browser connects to your site over HTTPS, the TLS handshake does three things:

sequenceDiagram
    participant B as Browser
    participant S as Server
    B->>S: ClientHello (supported TLS versions, ciphers)
    S->>B: ServerHello (chosen version, cipher) + Certificate
    B->>B: Verify certificate chain
    B->>S: Key exchange (ECDHE)
    S->>B: Finished
    B->>S: Encrypted application data
  1. Authentication — your certificate proves the server owns the domain.
  2. Key exchange — both sides agree on a shared secret without transmitting it.
  3. Encryption — all subsequent traffic is encrypted using that secret.

A misconfigured TLS stack can undermine any or all three. A server that accepts SSLv3, uses a 1024-bit key, or presents a broken certificate chain may still show the padlock icon but is genuinely vulnerable to practical attacks like POODLE, BEAST, DROWN, or ROBOT.

From a practical standpoint, TLS configuration also affects:

  • SEO — Google has used HTTPS as a ranking signal since 2014.
  • User trust — modern browsers display warnings for insecure or misconfigured sites.
  • Compliance — PCI DSS 4.0 requires TLS 1.2 minimum and prohibits early TLS.
  • Performance — TLS 1.3 is measurably faster due to its reduced handshake round trips.

How SSL Grading Works

The most authoritative public grader is Qualys SSL Labs. Their methodology assigns letter grades (A through F) based on a weighted score across four categories:

| Category | Weight | |---|---| | Certificate | 30% | | Protocol Support | 30% | | Key Exchange | 30% | | Cipher Strength | 10% |

A+ is not a separate score — it is an A with a bonus awarded specifically for enabling HTTP Strict Transport Security (HSTS) with a sufficiently long max-age (at least 180 days). You can have a perfect numeric score and still sit at A if HSTS is missing.

Grades are capped under specific conditions regardless of numeric score:

  • F — certificate is expired, untrusted, or the domain name does not match.
  • T — certificate is not trusted (self-signed or unknown CA).
  • C — RC4 cipher suites are supported, or TLS 1.0/1.1 is the only version offered.
  • B — weak Diffie-Hellman parameters (under 2048 bits), or no support for TLS 1.2+.

Understanding the caps is the fastest way to diagnose why a server is stuck at B or C. A single bad config item triggers the cap regardless of everything else.

Certificate Types: DV, OV, and EV

The ssl certificate checker distinction you will encounter most is between three validation levels:

Domain Validation (DV) — the CA verifies only that the applicant controls the domain. Let's Encrypt, ZeroSSL, and Google Trust Services all issue DV certificates. These are entirely adequate for most use cases and are what you should default to unless compliance or organizational identity display is required.

Organization Validation (OV) — the CA also verifies that a real legal entity operates the domain. The organization name is embedded in the certificate and visible in its details. OV certificates cost money and require documentation submission, but they do not display differently in modern browsers.

Extended Validation (EV) — the CA performs thorough vetting of the legal entity. Browsers once displayed the company name in a green address bar for EV certificates, but major browsers removed that UI treatment between 2019 and 2021. EV certificates now offer no meaningful user-visible distinction. They are expensive and slow to obtain. Unless your compliance framework explicitly requires EV, DV is the correct choice.

For ssl grade purposes, the CA and validation level do not affect your score. A Let's Encrypt DV certificate configured correctly beats an EV certificate on a misconfigured server every time.

TLS 1.2 vs TLS 1.3

The tls certificate protocol version your server advertises is one of the most impactful factors in your rating.

TLS 1.3 (RFC 8446, published 2018) is the current standard. Key improvements over 1.2:

  • Eliminates several legacy cipher suites and key exchange mechanisms that were the basis of most TLS attacks.
  • Reduces the handshake from 2 round trips to 1 (and 0-RTT resumption is possible, though it carries replay risks).
  • Forward secrecy is mandatory — ephemeral key exchange is built into the protocol, not optional.
  • The handshake itself is encrypted after the first flight.

TLS 1.2 remains acceptable and is required for compatibility with older clients (some payment terminals, enterprise software, and older Android versions only support 1.2). Disable anything older.

TLS 1.0 and 1.1 are deprecated per RFC 8996. Supporting them will cap your grade at C on SSL Labs. They have been disabled by default in all major browsers since 2020.

The recommended protocol configuration for nginx:

ssl_protocols TLSv1.2 TLSv1.3;

For Apache:

SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1

Common Issues That Lower SSL Grades

Before walking through positive configuration steps, it is worth naming the most common reasons servers score below A+.

Weak or deprecated protocols — supporting TLS 1.0/1.1 is the single most common grade cap trigger. Many default server configurations still include them.

Incomplete certificate chain — your server must send the full chain: your end-entity certificate plus all intermediate certificates, but not the root. If intermediates are missing, some clients (particularly mobile) will fail to verify the chain even though it can be reconstructed. This does not always produce a visible error — it silently degrades or fails for a subset of clients.

Self-signed or expired certificates — obvious in theory, surprisingly common in practice on internal services that get exposed, or on servers with broken auto-renewal.

Weak cipher suites — older configurations include RC4, 3DES (SWEET32), or export-grade ciphers. These will cap or tank your grade.

No forward secrecy — if your server uses RSA key exchange (not ECDHE or DHE), the session is not forward-secret. Compromise of the private key retroactively decrypts all recorded sessions.

Logjam / weak DH parameters — servers using 1024-bit Diffie-Hellman parameters are vulnerable to downgrade attacks. If you use DHE cipher suites, generate 2048-bit (or larger) DH parameters.

Missing HSTS — as noted, this is the difference between A and A+.

Heartbleed / POODLE / ROBOT — SSL Labs actively tests for known vulnerabilities. A server testing positive for any of these receives an F regardless of everything else.

Step-by-Step: How to Check Your SSL Certificate

Before making changes, get a baseline reading. You have two main options:

SSL Labs (web-based) — visit ssllabs.com/ssltest and enter your domain. The scan takes 60–90 seconds and produces a full report including the numeric score breakdown, certificate details, protocol support, and individual vulnerability checks. This is the definitive tool for understanding your current posture.

SiteProbe — scan your domain at siteprobe.live to get an instant read on your SSL configuration alongside DNS health, security headers, and email authentication. SiteProbe aggregates the signals that matter most and surfaces the specific issues you need to fix, without requiring you to interpret a raw SSL Labs report.

Command-line tools — openssl s_client gives you raw handshake details:

# Check what protocols and ciphers the server accepts
openssl s_client -connect yourdomain.com:443 -tls1_2
openssl s_client -connect yourdomain.com:443 -tls1_3

# Inspect the full certificate chain
openssl s_client -connect yourdomain.com:443 -showcerts < /dev/null

# Check certificate expiry
echo | openssl s_client -connect yourdomain.com:443 2>/dev/null   | openssl x509 -noout -dates

testssl.sh is a more comprehensive CLI tool that replicates much of what SSL Labs does locally, useful for testing internal services or pre-deployment checks.

Step-by-Step: Achieving an A+ SSL Rating

1. Obtain a Valid Certificate from a Trusted CA

For most deployments, Let's Encrypt via Certbot is the right answer. It is free, widely trusted, supports wildcard certificates via DNS-01 challenge, and auto-renews.

# Install Certbot (Debian/Ubuntu)
sudo apt install certbot python3-certbot-nginx

# Obtain a certificate
sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com

# Verify auto-renewal
sudo certbot renew --dry-run

If you are on a platform (Vercel, Cloudflare, AWS, Fly.io), TLS is typically managed for you. Verify that the platform's managed certificate covers your domain and is renewing correctly.

Key requirements for the certificate itself:

  • RSA key of at least 2048 bits, or an ECDSA key on P-256 or P-384. ECDSA is preferred — smaller, faster, equally secure.
  • SHA-256 or better signature hash (SHA-1 certificates are distrusted by all major browsers).
  • SAN (Subject Alternative Name) must include the exact hostnames you serve. CN-only matching is deprecated.
  • At least 30 days of validity remaining at all times. Set renewal to trigger at 60 days.

2. Configure Cipher Suites for Forward Secrecy

The Mozilla SSL Configuration Generator (ssl-config.mozilla.org) produces copy-paste-ready configurations for nginx, Apache, HAProxy, and others. Use the "Intermediate" or "Modern" profile depending on your client compatibility requirements.

A modern nginx cipher suite configuration:

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:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers off;

Note ssl_prefer_server_ciphers off — this allows TLS 1.3 clients to negotiate their preferred cipher (which is correct behavior; TLS 1.3 does not use the server-preference model).

3. Enable OCSP Stapling

When a browser receives your certificate, it needs to verify the certificate has not been revoked. Traditionally this meant the browser would contact the CA's OCSP responder — adding latency and leaking the user's browsing activity to the CA.

OCSP stapling moves this responsibility to your server. Your server periodically fetches a signed OCSP response from the CA and "staples" it to the TLS handshake. The browser gets revocation status without any external request.

nginx configuration:

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/letsencrypt/live/yourdomain.com/chain.pem;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;

Apache configuration:

SSLUseStapling On
SSLStaplingCache "shmcb:logs/ssl_stapling(32768)"
SSLStaplingStandardCacheTimeout 3600

Verify stapling is working:

openssl s_client -connect yourdomain.com:443 -status < /dev/null 2>&1   | grep -A 10 "OCSP Response"

You should see OCSP Response Status: successful and a This Update timestamp.

4. Add CAA DNS Records

CAA (Certification Authority Authorization) records are DNS records that specify which certificate authorities are permitted to issue certificates for your domain. They do not affect the TLS handshake — they are enforced by CAs during the issuance process.

Adding CAA records:

  • Prevents certificate misissuance if an attacker attempts to obtain a fraudulent certificate from a different CA.
  • Is a signal of security hygiene; SSL Labs reports CAA presence.

Example records (add as DNS CAA type at your registrar or DNS provider):

yourdomain.com. 3600 CAA 0 issue "letsencrypt.org"
yourdomain.com. 3600 CAA 0 issuewild "letsencrypt.org"
yourdomain.com. 3600 CAA 0 iodef "mailto:security@yourdomain.com"
  • issue — permits this CA to issue standard certificates.
  • issuewild — permits wildcard certificate issuance (must be specified separately).
  • iodef — where the CA should send violation reports.

If you use multiple CAs (e.g., Let's Encrypt for most certificates, DigiCert for a specific compliance requirement), add a record for each.

5. Enable HSTS

HTTP Strict Transport Security instructs browsers to only connect to your domain over HTTPS for a specified duration, and to refuse to make any HTTP connections during that period — even if the user types http:// or clicks an HTTP link.

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

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

Important caveats:

  • Do not enable preload until you are certain every subdomain supports HTTPS. The preload list is built into browsers and is nearly impossible to get removed from quickly.
  • SSL Labs awards A+ for any max-age of 180 days (15,552,000 seconds) or more. One year (31,536,000) is standard.
  • The header must be served over HTTPS (not HTTP). Verify your server redirects HTTP to HTTPS first.

6. Fix Certificate Chain Issues

A correctly ordered, complete chain is critical. Your server should present:

  1. Your end-entity certificate
  2. Intermediate certificate(s), in order from leaf to root
  3. Do not include the root certificate — clients have roots in their trust stores

With Let's Encrypt, Certbot handles this automatically via the fullchain.pem file. If you are installing a certificate manually, concatenate the files in the correct order.

# Check your chain is complete and correctly ordered
openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt   -untrusted /etc/letsencrypt/live/yourdomain.com/chain.pem   /etc/letsencrypt/live/yourdomain.com/cert.pem

A clean output is cert.pem: OK. Any errors indicate a chain problem.

7. Verify the Full Configuration

After making changes, reload your server and run a fresh scan:

sudo nginx -t && sudo systemctl reload nginx

Then check with SiteProbe for a consolidated view — SSL rating, header scores, and DNS health in one place — or run a full SSL Labs scan for the detailed breakdown.

Common Misconfigurations to Audit

Even servers that pass the basics often have one of these lurking:

Mixed content — serving HTTPS pages that load HTTP resources (images, scripts, stylesheets). Browsers block or warn on mixed content. Use CSP's upgrade-insecure-requests directive to catch stragglers.

Redirect chains — HTTP to HTTPS redirects should be a single 301. Chains (HTTP → HTTPS non-www → HTTPS www → final URL) add latency and can interfere with HSTS.

Certificate covering the wrong names — a certificate for www.yourdomain.com that does not include yourdomain.com (apex) will fail for bare-domain visitors. Use SANs to cover both, or use a wildcard (*.yourdomain.com — note that wildcards do not cover the apex).

Hardcoded HTTP URLs in application code — the server configuration is correct, but the application generates HTTP links internally. Audit for hardcoded http:// in templates, redirects, and API responses.

Stale OCSP stapling — if your server is offline or the resolver is unreachable at renewal time, the stapled response may expire. Monitor OCSP stapling status as part of your standard certificate health checks.

Port 443 not open — sounds obvious, but firewall rules and load balancer configuration are a frequent culprit, especially after infrastructure changes.

Ongoing Maintenance

An A+ rating is not permanent. Certificates expire, CAs revoke, vulnerabilities are discovered in TLS implementations, and grading criteria evolve. Maintain your rating with:

  • Automated renewal — Certbot's systemd timer or cron job, or your platform's managed renewal. Alert on renewal failures.
  • Certificate expiry monitoring — monitor expiry at 30 and 7 days. Tools like SiteProbe can alert you when expiry is approaching before it affects users.
  • Protocol and cipher monitoring — when new vulnerabilities are disclosed (e.g., a new BEAST-class attack against a cipher), you need to know your server is or is not affected. Regular scanning catches regressions.
  • HSTS max-age renewal — browsers renew the HSTS timer on each visit. If users stop visiting before the max-age expires and you later misconfigure HTTPS, returning users will be locked out. Keep max-age at a year as a standard.

Check Your Domain Now

The fastest way to know where you stand is to run a scan. SiteProbe checks your SSL configuration, certificate validity, HSTS status, security headers, DNS records, and CAA records in one pass, and gives you a prioritized list of what to fix.

A+ is achievable on any server in under an hour of configuration work. The checklist is not long: valid certificate with a complete chain, TLS 1.2 and 1.3 only, ECDHE cipher suites, OCSP stapling, CAA records, and HSTS with a year-long max-age. Each item has a clear pass/fail. Start with a scan, work through the list, scan again.

Check your domain now

See how your domain scores on SSL, security headers, and more.
Then set up monitoring alerts to catch problems early.

$
How to Get an A+ SSL Rating | SiteProbe