TLS baselines: the editions a check is judged against
A baseline is a published guideline for TLS servers. A TLS check judges the server's configuration against the baselines you select, Mozilla's by default, and a finding against any of them sets the check's status as you chose on the check. Findings outside them are still recorded and count toward the lock grade, but never alert.
A baseline means something only at an exact edition: the same server can meet one year's edition and fail the next. Every baseline here is pinned to one, every result records the edition that judged it, and an edition moves only by a change listed at the end of this page.
The four baselines
| Baseline | For | Edition |
|---|---|---|
| Mozilla intermediate | Most public sites; what common configuration generators target. The default. | 6.0 |
| BSI TR-02102-2 and TR-02103 | The German public sector and its suppliers | TR-02102-2 2026-01, TR-02103 1.0 |
| NIST SP 800-52 | US federal systems and the frameworks that refer to it, government-only profile | Rev. 2 |
| NCSC-NL TLS guidelines | The Dutch government and its suppliers, Dutch health care and finance | 2025-05 |
Mozilla intermediate mozilla
Mozilla, the maker of Firefox, publishes server-side TLS guidelines in three profiles. Intermediate is the profile for sites that have to serve a broad range of clients, and the one most configuration generators produce.
An allowlist: the guideline names the versions, cipher suites, groups, certificate types and signatures it accepts, and anything else is a finding. Only its own keys are cited. Where it says nothing (compression, renegotiation, Key Usage), it claims nothing, and those findings count only toward the grade. Its modern profile is judged beside it and shown in each result for reference; it cannot be selected, because nobody should be alerted for missing it.
Source
- Mozilla Server Side TLS 6.0: https://ssl-config.mozilla.org/guidelines/6.0.json
BSI TR-02102-2 and TR-02103 bsi
The BSI (Bundesamt für Sicherheit in der Informationstechnik) is Germany's federal cyber security authority. Its technical guidelines TR-02102-2, on TLS, and TR-02103, on certificates, set the bar for the German federal administration, which commonly requires them of its suppliers too.
The BSI gives every mechanism a year it may be used up to, so a finding can appear on the first day of a new year with nothing changed on the server, and its clause names the year. The guideline says a mechanism it does not list is not necessarily insecure; its tables are still the list an audit against it checks, so a finding reads "outside the baseline", never "insecure". It is strict on certificates: a public site meets it in practice only with an ECDSA certificate under an ECDSA intermediate, since RSA keys below 3000 bits and RSA PKCS #1 v1.5 signatures are no longer recommended. Two certificate rules are not evaluated, because every publicly trusted certificate fails them by the rules of the CA/Browser Forum: critical Certificate Policies and a subject without the server's address.
Sources
- BSI TR-02102-2: https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-2.pdf
- BSI TR-02103: https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02103/BSI-TR-02103.pdf
NIST SP 800-52 nist
NIST, the US National Institute of Standards and Technology, sets the security standards US federal agencies follow. Special Publication 800-52 is its guideline for selecting and configuring TLS.
The government-only profile, because a check that selects NIST asks for the federal bar. It is an allowlist by its own words. Its approved lists exclude ChaCha20 and X25519, so most servers outside a FIPS-mode deployment fail it on those alone. It requires a certificate from a CA that runs OCSP, so certificates from CAs that have dropped OCSP fail it. It allows truncated HMAC only for constrained clients, which no outside check can know of, so it counts as a finding. The revision is from 2019; there is no newer one.
Source
- NIST SP 800-52 Rev. 2: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r2.pdf
NCSC-NL TLS guidelines ncsc_nl
The NCSC-NL is the Dutch National Cyber Security Centre, part of the Ministry of Justice and Security. Its TLS guidelines are the reference for the Dutch government and its suppliers, and are widely followed in Dutch health care and finance.
Every setting is rated Good, Sufficient, To be phased out or Insufficient. "To be phased out" and "Insufficient" are findings, so meeting this baseline means nothing weaker than Sufficient is on offer. The guidelines give phase-out no end date and leave it to the operator. A cipher suite rates as its weakest part. RSA keys below 3072 bits are to be phased out, so most public RSA certificates fail it. The certificate profile is outside the guidelines' scope, so its rules count only toward the grade.
Source
- NCSC-NL TLS guidelines: https://www.ncsc.nl/en/transport-layer-security/tls-security-guidelines
Which rules each baseline counts
Each finding and the clause each baseline counts it under. An empty cell means the baseline says nothing about it. The finding codes are those of the result drawer.
| Finding | Mozilla 6.0 | BSI 2026-01 | NIST Rev. 2 | NCSC-NL 2025-05 |
|---|---|---|---|---|
accepts_3des | ciphers | not in Tables 3–5 | §3.3.1.1 | Table 8: Insufficient |
accepts_anon | ciphers | not in Tables 3–5 | §3.3.1 | Table 2: Insufficient |
accepts_cbc | ciphers | Table 8: To be phased out | ||
accepts_dhe | ciphers | §3.3.1.1 Table 3 (TLS 1.2 DHE up to 2029) | Table 6: To be phased out | |
accepts_export | ciphers | not in Tables 3–5 | §3.3.1 | Table 2: Insufficient |
accepts_null | ciphers | not in Tables 3–5 | §3.3.1 | Tables 6, 8: Insufficient |
accepts_rc4 | ciphers | not in Tables 3–5 | §3.3.1 | Table 8: Insufficient |
accepts_sha1_mac | ciphers | not in Tables 3–5 | Table 9: Insufficient | |
accepts_ssl3 | tls_versions | §3.2 | §3.1 | Table 1: Insufficient |
accepts_static_kex | ciphers | RSA key transport, not in Tables 3–5; §3.3.1.2 Table 4 (up to 2026) | Table 6: Insufficient | |
accepts_tls10 | tls_versions | §3.2 | §3.1 | Table 1: Insufficient |
accepts_tls11 | tls_versions | §3.2 | §3.1 (should not) | Table 1: Insufficient |
accepts_tls12 | §3.2 Table 2 (TLS 1.2 up to 2031) | |||
cbc_without_etm | §3.3.4.5 | §3.4.2.7 | ||
cert_type_not_allowed | certificate_types | §3.3.3 Table 7 | §3.2 | Table 2: Insufficient |
curve_not_allowed | certificate_curves | §3.6.2 | §3.2, Table 3-1 | Tables 3, 5: Insufficient |
eku_any_purpose | Table 3-1 | |||
heartbeat_enabled | §3.3.4.6 | |||
insecure_renegotiation | §3.3.4.1 | §3.4.1.1 | Table 11: Insufficient | |
kex_group_not_allowed | tls_curves | §3.3.2 Table 6, §3.4.2 Table 10 | §3.3.1, §3.4.2.2 | Tables 3, 6, 7: Insufficient |
key_usage_mismatch | TR-02103 (1.0) §4.1.3 | Table 3-1 | ||
key_usage_not_critical | TR-02103 (1.0) Table 34 | Table 3-1 | ||
long_lifespan | maximum_certificate_lifespan | Table 3-1 | ||
no_aki | TR-02103 (1.0) Table 30 | Table 3-1 | ||
no_extended_master_secret | §3.3.4.7 | §3.4.1.3 | ||
no_fallback_scsv | §3.4.2.1 | |||
no_hsts | hsts_min_age | |||
no_key_usage | TR-02103 (1.0) Table 30 | Table 3-1 | ||
no_ocsp_responder | §3.2, Table 3-1 | |||
no_ocsp_stapling | ocsp_staple | §3.4.1.5 | ||
no_pq_hybrid | §3.1.3 (classical key agreement alone up to 2031) | |||
no_required_kex_group | §3.3.2 Table 6, §3.4.2 Table 10 | §3.4.2.2 | ||
no_server_auth_eku | TR-02103 (1.0) §4.1.4 | Table 3-1 | ||
no_tls13 | §3.1 | |||
pkcs1_handshake_signature | §3.3.3 Table 7 (rsa up to 2025) | |||
pkcs1_signature | §3.3.3 Table 7, §3.4.3 Table 12 (up to 2025) | |||
short_hsts | hsts_min_age | |||
suite_not_allowed | ciphers | not in Tables 3–5 | §3.3.1.1 | Table 8: Insufficient |
tls13_suite_not_allowed | ciphersuites | §3.4.4 Table 13 | §3.3.1.2 | Table 8: Insufficient |
tls_compression | §3.3.4.3 | §3.7 | Table 10: Insufficient | |
truncated_hmac | §3.3.4.2 | §3.4.2 item 8 | ||
version_intolerant | §3.1 | |||
weak_chain_key | §3.6 | §3.3.3 | ||
weak_dh | dh_param_size | §3.6.1 Table 14 | §3.3.1, §3.3.3 | Table 7: Insufficient |
weak_handshake_hash | §3.3.3 Table 8 | §3.3.3 | Table 9: Insufficient | |
weak_key | certificate_curves; rsa_key_size | §3.6.1 Table 14 | §3.2.1 Table 3-1, §3.3.3 | Table 3: Insufficient; Table 4: Insufficient |
weak_signature | certificate_signatures | §3.3.3 Table 8, §3.4.3 Table 12 | §3.3.3 | Table 9: Insufficient |
wildcard | TR-02103 (1.0) §4.1.2 |
This table is generated from the rules the checks apply, and a test fails when the two differ.
What no outside check can see
Some requirements of these guidelines concern how a server behaves for clients we are not, or what runs inside it. They are not judged, and a server is not marked down for them:
- client-initiated renegotiation, 0-RTT early data, and the pre-shared key and resumption modes;
- the signature schemes of a TLS 1.3 handshake, which are encrypted;
- certificate signatures with SHA-224, which our certificate reader does not identify;
- server internals: validated cryptographic modules, random number generation, patching.
Changelog
| Date | Change |
|---|---|
| 2026-10-17 | First editions: Mozilla 6.0; BSI TR-02102-2 2026-01 with TR-02103 1.0; NIST SP 800-52 Rev. 2; NCSC-NL 2025-05. |