Référentiels TLS : les éditions qui servent à juger un serveur
Un référentiel est une recommandation publiée pour les serveurs TLS. Une vérification TLS juge la configuration du serveur au regard des référentiels que vous choisissez, celui de Mozilla par défaut, et un constat au regard de l’un d’eux fixe le statut de la vérification selon votre réglage. Les constats hors de ces référentiels sont tout de même enregistrés et comptent dans la note TLS, mais ne déclenchent jamais d’alerte.
Un référentiel n’a de sens qu’à une édition précise : le même serveur peut respecter l’édition d’une année et pas celle de la suivante. Chaque référentiel de cette page est fixé à une édition, chaque résultat enregistre l’édition qui l’a jugé, et une édition ne change que par une modification indiquée en fin de page.
Les quatre référentiels
| Référentiel | Pour | Édition |
|---|---|---|
| Mozilla intermediate | La plupart des sites publics ; ce que visent les générateurs de configuration courants. Celui par défaut. | 6.0 |
| BSI TR-02102-2 et TR-02103 | Le secteur public allemand et ses fournisseurs | TR-02102-2 2026-01, TR-02103 1.0 |
| NIST SP 800-52 | Les systèmes fédéraux américains et les cadres qui y renvoient, profil réservé à l’administration | Rev. 2 |
| Recommandations TLS du NCSC-NL | L’administration néerlandaise et ses fournisseurs, la santé et la finance néerlandaises | 2025-05 |
Mozilla intermediate mozilla
Mozilla, l’éditeur de Firefox, publie des recommandations TLS pour serveurs en trois profils. Intermediate est le profil destiné aux sites qui doivent servir un large éventail de clients, et celui que produisent la plupart des générateurs de configuration.
Une liste d’autorisation : la recommandation nomme les versions, suites de chiffrement, groupes, types de certificat et signatures qu’elle accepte, et tout le reste est un constat. Seules ses propres clés sont citées. Là où elle ne dit rien (compression, renégociation, Key Usage), elle ne revendique rien, et ces constats ne comptent que pour la note. Son profil modern est jugé à côté et affiché dans chaque résultat pour référence ; on ne peut pas le choisir, car personne ne devrait être alerté pour ne pas l’atteindre.
Source
- Mozilla Server Side TLS 6.0 : https://ssl-config.mozilla.org/guidelines/6.0.json
BSI TR-02102-2 et TR-02103 bsi
Le BSI (Bundesamt für Sicherheit in der Informationstechnik) est l’autorité fédérale allemande de cybersécurité. Ses directives techniques TR-02102-2, sur TLS, et TR-02103, sur les certificats, fixent le niveau attendu de l’administration fédérale allemande, qui les impose souvent aussi à ses prestataires.
Le BSI donne à chaque mécanisme une année jusqu’à laquelle il peut être utilisé : un constat peut donc apparaître le premier jour d’une nouvelle année sans que rien n’ait changé sur le serveur, et sa référence nomme l’année. La recommandation dit qu’un mécanisme qu’elle ne cite pas n’est pas forcément peu sûr ; ses tableaux restent la liste qu’un audit selon elle vérifie, si bien qu’un constat dit « hors du référentiel », jamais « peu sûr ». Elle est stricte sur les certificats : en pratique, un site public ne la respecte qu’avec un certificat ECDSA sous un intermédiaire ECDSA, car les clés RSA de moins de 3000 bits et les signatures RSA PKCS #1 v1.5 ne sont plus recommandées. Deux règles de certificat ne sont pas évaluées, car tout certificat de confiance publique y échoue selon les règles du CA/Browser Forum : des Certificate Policies critiques et un sujet sans l’adresse du serveur.
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
Le NIST, l’institut national des normes et de la technologie des États-Unis, fixe les normes de sécurité que suivent les agences fédérales américaines. La Special Publication 800-52 est son guide de choix et de configuration de TLS.
Le profil réservé à l’administration, car choisir NIST, c’est demander le niveau fédéral. Une liste d’autorisation de son propre aveu. Ses listes approuvées excluent ChaCha20 et X25519, si bien que la plupart des serveurs hors d’un déploiement en mode FIPS y échouent pour cela seul. Elle exige un certificat d’une AC qui propose OCSP : les certificats des AC qui ont abandonné OCSP y échouent. Elle n’autorise le HMAC tronqué que pour des clients contraints, qu’aucune vérification externe ne peut connaître : il compte donc comme constat. La révision date de 2019 ; il n’en existe pas de plus récente.
Source
- NIST SP 800-52 Rev. 2 : https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r2.pdf
Recommandations TLS du NCSC-NL ncsc_nl
Le NCSC-NL est le centre national de cybersécurité des Pays-Bas, rattaché au ministère de la Justice et de la Sécurité. Ses recommandations TLS font référence pour l’administration néerlandaise et ses prestataires, et sont largement suivies dans la santé et la finance néerlandaises.
Chaque réglage est classé Good, Sufficient, To be phased out ou Insufficient. « To be phased out » et « Insufficient » sont des constats : respecter ce référentiel signifie que rien de plus faible que Sufficient n’est proposé. Les recommandations ne fixent aucune date pour l’abandon progressif et le laissent à l’opérateur. Une suite de chiffrement est classée selon sa partie la plus faible. Les clés RSA de moins de 3072 bits sont à abandonner, si bien que la plupart des certificats RSA publics y échouent. Le profil du certificat sort du champ des recommandations ; ses règles ne comptent que pour la note.
Source
- Recommandations TLS du NCSC-NL : https://www.ncsc.nl/en/transport-layer-security/tls-security-guidelines
Les règles que compte chaque référentiel
Chaque constat et la référence sous laquelle chaque référentiel le compte. Une case vide signifie que le référentiel n’en dit rien. Les codes des constats sont ceux du détail du résultat.
| Constat | 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 |
Ce tableau est généré à partir des règles qu’appliquent les vérifications, et un test échoue si les deux diffèrent.
Ce qu’aucune vérification externe ne voit
Certaines exigences de ces recommandations portent sur la façon dont un serveur se comporte avec des clients que nous ne sommes pas, ou sur ce qui tourne à l’intérieur. Elles ne sont pas jugées, et un serveur ne perd rien à cause d’elles :
- la renégociation initiée par le client, les données 0-RTT et les modes à clé prépartagée et de reprise ;
- les schémas de signature d’une négociation TLS 1.3, qui sont chiffrés ;
- les signatures de certificat en SHA-224, que notre lecteur de certificats n’identifie pas ;
- l’intérieur du serveur : modules cryptographiques validés, génération d’aléa, correctifs.
Historique
| Date | Changement |
|---|---|
| 2026-10-17 | Premières éditions : Mozilla 6.0 ; BSI TR-02102-2 2026-01 avec TR-02103 1.0 ; NIST SP 800-52 Rev. 2 ; NCSC-NL 2025-05. |