This FAQ answers some of the most common questions regarding SSL Labs.

If you have any questions that are not covered in this FAQ, you are always welcome to send an email with your question to

Link to SSL Labs:

SSL LABS domain test


An introduction to SSL Labs

SSL Labs first launched in 2009. Originally, the main goal was to provide comprehensive diagnostics of SSL/TLS and PKI configuration issues.

However, the project also provided a way to measure and compare configuration quality, chiefly using the A-F letter grades. This grading approach proved very popular and helped many organizations improve their security posture.

Our understanding of the security of TLS and PKI today is vastly different from that in 2009. The SSL Labs grading algorithm largely kept up with the changes, but it’s time for a complete overhaul.

We present a new version of the grading algorithm that starts from scratch. With this version we have the following main goals:

  1. Rework the grading approach to incorporate everything we now know about the security of TLS and the PKI ecosystem, covering all current security techniques and allowing for the next batch of features that will come in the near future.
  2. Assign clear meanings to each of the grades.
  3. Break-down the grading into a series of individual rules, each of which should be easy to reason individually.

Additionally, as we’ve regularly done over the years, this new version of our grading criteria will further advance our criteria for what is considered reasonable security.

How to understand grades

We wish to provide meaningful and easy-to-understand grades to rate SSL/TLS and PKI configurations. The letter-based A-F grades have proved very successful and we wish to continue using them. Although the meaning of the letter grades can largely be inferred, the original SSL Labs rating guide never defined them, and that caused inconsistencies in how the grades were applied.

We wish to correct that mistake now and specify the meaning behind each grade. They are as follows:

A+ – exceptional configuration

A – strong commercial security

B – adequate security with modern clients, with older and potentially obsolete crypto used with older clients; potentially smaller configuration problems

C – obsolete configuration, uses obsolete crypto with modern clients; potentially bigger configuration problems

D – configuration with security issues that are typically difficult or unlikely to be exploited, but can and should be addressed

E – unused

F – exploitable and/or patchable problems, misconfigured server, insecure protocols, etc.

We wish to make clear that, while A+ is clearly the desired grade, both A and B grades are acceptable and result in adequate commercial security.

The B grade, in particular, may be applied to configurations designed to support very wide audiences, many of whom use very old programs to connect.

The C grade is generally used for configurations that don’t follow best practices. Grades D and F are used for servers with serious configuration and security issues.

Publicly-trusted certificates are required for a good grade

We’ve designed our grading criteria for use with public services, which is why we expect and require publicly-trusted certificates. When a certificate is not trusted, tools (e.g., browsers) usually show warnings that can be bypassed.

For example, a user who is under attack sees the same warnings when he or she accesses a server with self-signed certificates. Very small groups of very technical users might be able to use self-signed certificates securely, but this is not something we can recommend even for a moderately sized group. For grading purposes, we require that a certificate is trusted by the latest version of Mozilla’s root store.

What is good configuration?

At some level, defining good TLS and PKI configuration is not very difficult. We’ve designed our criteria so that it contains one positive rule for each of the desired configuration attributes.

If we look only at those rules, we get the following principles that apply to all TLS servers:

  • Have a strong private key
  • Use a certificate valid for public consumption
  • Have a correct certificate chain
  • Have a certificate with a strong signature algorithm
  • Support TLS 1.2
  • Support and prefer forward secrecy (effectively ECDHE, as modern browsers no longer support DHE)
  • Support and prefer authenticated encryption (AEAD)
  • Use strong encryptions algorithm and strong symmetric key sizes
  • Use strong key exchange

Additionally, for web applications, the following principles apply:

  • Use HTTPS for content (HTTP only for redirection to HTTPS)
  • Use HTTP Strict Transport Security (HSTS), with long duration and preloaded
  • Have all cookies secure
  • Don’t have any mixed content
  • Use CSP to mitigate mixed content

So it seems easy on the surface, but it’s not really in practice. First, following all of the above would give you strong security, but it’s also likely to refuse service to some older clients. Second, in many environments, it’s not possible to fulfil all of the above or sometimes not quickly.

Thus, the rules we’ve given above are what we strive for. Our A+ criteria are what you should be working toward when you are able to achieve it. In the meantime, you should be able to hit A, and B if you’re working with a very wide user base.

The other problem is that security is not black and white; there are many shades of grey. Thus, in fact, we have a very elaborate set of rules to try to make sense of the situations between secure and insecure.

Future directions

Adoption candidates

  • Certification Authority Authorization (CAA); CAA enables domain name owners to specify which CAs are allowed to issue certificates for their properties. With CAA in place, the attack surface for fraudulent certificates is reduced, effectively making sites more secure.
  • Certificates with mandatory stapled OCSP responses; Today, certificate revocation is generally ineffective, except maybe for some most popular web sites, whose operators might be able to convince the major browser vendors to explicitly blacklist stolen keys. Certificates that require OCSP can be abused for only about a week from the moment they’re revoked, which is a significant improvement. Unfortunately, many servers lack reliable OCSP stapling, which is why we can’t recommend mandatory OCSP stapling at this time.
  • Certificates with Certificate Transparency (CT); According to Google (Chrome), from April 2018 all new certificates will have to be logged in CT. We may at that time also add CT rules to our criteria.
    • TLS 1.3; TLS 1.3 is the long-awaited next-generation protocol, which removes a lot of baggage accumulated over the years. We will require TLS 1.3 support once there is sufficient support in major operating systems.TLS 1.0; It is expected that the PCI council will deprecate TLS 1.0 in 2018, which could lead to its accelerated decline. We will consider adjusting the grading to assist with the deprecation.
  • Cookie name prefixes; Cookie name prefixes are a new RFC that prevent insecure cookies from overwriting secure cookies, closing a major security hole caused by the original HTTP Cookies specification. Although not yet standardized, cookie name prefixes are already supported by some major browsers.

Removal candidates

  • TLS_FALLBACK_SCSV; Originally, the fallback SCSV was designed to prevent MITM attackers from interfering with TLS negotiation. After POODLE, most browsers disabled fallbacks to SSL 3, and then also TLS 1.0. We currently require TLS_FALLBACK_SCSV for A+. We would have already deprecated this requirement if it weren’t for the TLS 1.3 deployment problems; at this time, there is still a possibility that the fallback SCSV will be reintroduced. We will deprecate it if it isn’t.

Other candidates 

  • MTA-STS is a new standard which is still under development. It is to SMTP what HSTS is to HTTP. If this standard sees strong support, we’re very likely to require it in the future.
  • HTTP Public Key Pinning (HPKP); HPKP is a standard for HTTP public key pinning that’s quite dangerous and difficult to use. Before, HPKP was on our list as a possible (although not very likely) candidate for A+. However, after Chrome announced that they would be deprecating HPKP, we will no longer consider it for our grading criteria.
  • DNSSEC/DANE; the security industry has a love and hate relationship with DNSSEC; where some love it, others hate it. Browser vendors refuse to support it in its current form, which means that DANE is not feasible for HTTP. There is stronger support for using DANE to protect SMTP. We will closely monitor how the situation develops in the future.
  • ECDHE server parameter reuse; For performance reasons some servers reuse the server parameter during the ECDHE key exchange. This is an unfortunate practice, but it’s not as bad as reuse of the server value in DHE. Furthermore, if the server value is cached for a limited value only, the danger is small. As far as we’re aware, Microsoft’s IIS is the only major platform that behaves in this way. We’re currently not penalising ECDHE server parameter reuse because end users have no recourse and yet the problem is not big enough to warrant pressure to migrate to another platform.
  • Preference for newer EC curves (e.g., X25519) over NIST; ECDHE in TLS has traditionally relied on the P-256 and P-384 NIST curves, which are viewed as tainted by some. Modern clients support newer curves (e.g., X25519), which have been developed in the open. We think that software that adds support for these newer curves will naturally prefer them and that there isn’t a strong rationale for penalising servers that don’t support them.


In this section, we discuss how our grading criteria are implemented.


Our grading algorithm consists of a series of rules that are processed sequentially, each rule affecting the overall grade. The rules are grouped, but only for convenience; the grouping doesn’t affect the outcome.

At a high level, each rule focuses on one aspect of configuration that is evaluated and the grade changes depending on the outcome of the evaluation. There are two types of rules:

  • Positive rules. If a feature is desirable, we wish to encourage its use. Using positive rules, support for a particular feature can be required to achieve a certain grade. For example: “you need to support TLS 1.2 to be awarded an A grade”. If the rule evaluates to false, the grade is reduced according to the specified penalties. For example, if TLS 1.2 is not supported and the current grade is A or better, the grade is reduced to a C.
  • Negative rules. If a feature is not desirable, we wish to discourage its use by applying penalties to reduce the grade. In this case, if penalties are applied if the rule evaluates to true (the opposite of what happens with positive rules).


Penalties come in two flavours. First, there is the default penalty, which is applied in all situations when a rule is triggered. Almost all rules specify the default penalty.

However, having just one penalty has proven to be limited in practice. For example, sometimes a server will need to support a particular feature only for use with older clients. When this can be done safely, we don’t necessarily wish to discourage this type of use. However, if such a feature is negotiated with a client that supports better features, we apply the associated capable client penalty.

Clients and capable clients

Often, it’s not possible to deploy with a perfect configuration. For example, at the time of writing, TLS 1.2 provides the best security, but if you deployed with this protocol only, some of the older clients wouldn’t be able to connect to your servers.

For this reason, we allow less than ideal configuration element, but it’s important that they are used only with clients that don’t support anything better. Following the same example, it would be wrong to negotiate TLS 1.0 with a client that supports TLS 1.2.

We deal with problems like this through the concept of testing with “capable clients”. These are specially designed user agents that support strong security features, but also support one old or obsolete element. When we test a server’s configuration with a capable client, the expectation is that the obsolete feature is never negotiated.

Appendix A contains the definitions of one base capable client as well as several variations, each designed to trigger a particular situation.

All testing is done with Server Name Indication (SNI) enabled.

Example rules

To better explain our approach, in this section we show all three rules from the Protocols category of our grading criteria. This category contains one positive rule, which requires TLS 1.2 for the A grade. Servers that don’t support TLS 1.2 have their grade reduced to C.

There are two further rules to handle servers that support the use of obsolete protocols. The first of the two applies a mild penalty to servers that continue to support SSL 3, but use it only with servers that don’t support any better protocols.

You can see that the default penalty is a D. However, F is used if SSL 3 is negotiated with a capable client. The third rule reduces the grade to F if SSL 2 is used.

Description            Positive
Capable Client
TLS 1.2 supportedAC
SSL 3 supportedDF
SSL 2 supportedF


Complete grading criteria V2018

Appendix A: Capable clients

Base capable client (capable_base):

Our base capable client is a modern user agent that offers features similar to those found in major web browsers, typically TLS 1.2 and suites that use authenticated encryption and forward secrecy.

Protocol TLS 1.2


  • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
  • TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8)

Named groups

  • x25519
  • secp256r1
  • secp384r1
  • secp521r1

Signature algorithms

  • SHA256/ECDSA
  • SHA256/RSA
  • SHA384/ECDSA
  • SHA384/RSA
  • SHA512/RSA
  • SHA1/RSA


  • Server Name Indication (SNI)
  • Renegotiation Info
  • Signature Algorithms
  • EC Point Formats
  • Elliptic Curves

Capable client variations:

The base capable client is useful for some tests, but we also define several variations to detect misconfigured servers.


As the base client, with the following suites added to the end

  • TLS_ECDHE_ECDSA_WITH_RC4_128_SHA (0xc007)
  • TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011)
  • TLS_DHE_DSS_WITH_RC4_128_SHA (0x66)
  • TLS_ECDH_RSA_WITH_RC4_128_SHA (0xc00c)
  • TLS_ECDH_ECDSA_WITH_RC4_128_SHA (0xc002)
  • TLS_RSA_WITH_RC4_128_SHA (0x5)
  • TLS_RSA_WITH_RC4_128_MD5 (0x4)

As the base client, with the following suites added to the end


As the base client, with the following suites added to the end

  • TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c)
  • TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d)
  • TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d)
  • TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c)
  • TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)
  • TLS_RSA_WITH_AES_256_CBC_SHA (0x35)
  • TLS_RSA_WITH_RC4_128_SHA (0x5)
  • TLS_RSA_WITH_RC4_128_MD5 (0x4)

As the base client, with the following suites added to the end

  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)
  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
  • TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c)
  • TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d)
  • TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)
  • TLS_RSA_WITH_AES_256_CBC_SHA (0x35)
  • TLS_RSA_WITH_RC4_128_SHA (0x5)
  • TLS_RSA_WITH_RC4_128_MD5 (0x4)

Appendix B: Criteria V2018 

This section contains the current rules in a user-friendly format.


Description            Positive
Client Penalty
TLS 1.2 supportedAC
SSL 3 supportedDF
SSL 2 supportedF



Description                                                                                                                                             Positive
Client Penalty
Private key algorithm secure                                  AC
Private key algorithm insecureF
Private key strength secure (>= 2048 bits)AC
Private key strength insecure
(< 1024 bits)
Private key insecure
(RSA exponent 1, known Debian key,
insufficient randomness, ROCA)
Certificate signature algorithm secureABF
Certificate signature algorithm insecureF
Certificate has no revocation information
(excluding short-lived certificates)
Certificate has no SAN informationF
Certificate revokedF
Certificate not yet valid or expiredF
Certificate name mismatchF
Certificate chain incompleteF
Certificate trust not suitable for audienceF
Certificate chain failed validationF
Certificate chain contains unrelated certificateB
Certificate chain not well formed in a way
that doesn’t impact validation
(e.g., unrelated certificate excl.
anchor present or incorrect order)


Cipher suites and key exchange

Description                                         Positive
Client Panalty
Cipher algorithm secureAFF
Cipher algorithm insecure: RC4BF
Cipher algorithm insecureF
Cipher strength secure
(>= 128 bits)
Cipher strength insecure
(< 112 bits)
Cipher block size small
(< 128 bits)
Cipher suite supports PFSABC
Cipher suite uses AEADAB
Cipher suite export strengthF
Key exchange strength secure
(>= 2048 RSA bits)
Key exchange strength insecure
(< 1024 bits)
Key exchange algorithm anonymousF
Key exchange parameters secureAF
Key exchange uses well-known
1024-bit Diffie-Hellman group
Key exchange reuses DHE parametersC
Key exchange uses insecure parameters
(e.g., small subgroup, composite DH prime)



Description          Positive
Client Penalty
Insecure client-initiated
TLS compression (CRIME)F
Heartbleed (CVE-2014-0160)F
Ticketbleed (CVE-2016-9244)F
OpenSSL CCS vulnerability
Bleichenbacher attackF
Other fatal misconfiguration
or vulnerability
serious but non-fatal
Protocol version intolerance
(any TLS version,
including TLS 1.3)



Client Penalty
HTTP traffic redirected to HTTPSAC
HSTS deployedAB
HSTS configuration robust
(min duration 1 year, includeSubDomains,
preloaded, correct redirections)
CSP mitigates mixed contentA+A
Page contains passive mixed contentC
Page contains active mixed contentF
Cookies are secureAB
Insecure authentication cookie cookieF

What is HTTP Strict Transport Security (HSTS)?

HTTP Strict Transport Security (HSTS) is a browser and server technology that removes the ability for your SSL encrypted session (HTTPS) to be downgraded to HTTP and thereby reduce the likelihood of some attacks such as man-in-the-middle attacks. HSTS works by forcing all communication to be sent via HTTPS by instructing your web-browser that no traffic ever should be sent via the HTTP protocol.

HSTS is available in both Google Chrome, Mozilla Firefox and Internet Explorer. The HSTS Preload List is a list of domains built-in to all modern browsers to see whether a domain should be using HSTS. If you have implemented HSTS and want to include your domain on the HSTS Preload preload page, the submission form can be found at