Referencias TLS: las ediciones con que se juzga un servidor
Una referencia es una guía publicada para servidores TLS. Una comprobación TLS juzga la configuración del servidor frente a las referencias que elija, la de Mozilla por defecto, y un hallazgo contra cualquiera de ellas fija el estado de la comprobación tal como lo eligió en ella. Los hallazgos fuera de ellas se registran igualmente y cuentan para la calificación con candados, pero nunca generan alertas.
Una referencia solo significa algo en una edición exacta: el mismo servidor puede cumplir la edición de un año y no la del siguiente. Cada referencia de esta página está fijada a una edición, cada resultado registra la edición que lo juzgó, y una edición solo cambia mediante un cambio que figura al final de esta página.
Las cuatro referencias
| Referencia | Para | Edición |
|---|---|---|
| Mozilla intermediate | La mayoría de los sitios públicos; lo que buscan los generadores de configuración habituales. La predeterminada. | 6.0 |
| BSI TR-02102-2 y TR-02103 | El sector público alemán y sus proveedores | TR-02102-2 2026-01, TR-02103 1.0 |
| NIST SP 800-52 | Los sistemas federales de EE. UU. y los marcos que remiten a ella, con el perfil solo para la administración | Rev. 2 |
| Directrices TLS del NCSC-NL | La administración neerlandesa y sus proveedores, la sanidad y las finanzas neerlandesas | 2025-05 |
Mozilla intermediate mozilla
Mozilla, el fabricante de Firefox, publica directrices de TLS para servidores en tres perfiles. Intermediate es el perfil para sitios que deben atender a una amplia variedad de clientes, y el que producen la mayoría de los generadores de configuración.
Una lista de permitidos: la guía nombra las versiones, conjuntos de cifrado, grupos, tipos de certificado y firmas que acepta, y todo lo demás es un hallazgo. Solo se citan sus propias claves. Donde no dice nada (compresión, renegociación, Key Usage), no reclama nada, y esos hallazgos solo cuentan para la calificación. Su perfil modern se juzga a su lado y se muestra en cada resultado a título informativo; no se puede elegir, porque nadie debería recibir una alerta por no alcanzarlo.
Fuente
- Mozilla Server Side TLS 6.0: https://ssl-config.mozilla.org/guidelines/6.0.json
BSI TR-02102-2 y TR-02103 bsi
El BSI (Bundesamt für Sicherheit in der Informationstechnik) es la autoridad federal de ciberseguridad de Alemania. Sus directrices técnicas TR-02102-2, sobre TLS, y TR-02103, sobre certificados, marcan el nivel exigido a la administración federal alemana, que a menudo también las exige a sus proveedores.
El BSI da a cada mecanismo un año hasta el que puede usarse, así que un hallazgo puede aparecer el primer día de un año nuevo sin que el servidor haya cambiado, y su cláusula nombra el año. La guía dice que un mecanismo que no figura no es necesariamente inseguro; aun así, sus tablas son la lista con la que se contrasta una auditoría según ella, así que un hallazgo dice «fuera de la referencia», nunca «inseguro». Es estricta con los certificados: en la práctica, un sitio público solo la cumple con un certificado ECDSA bajo un intermedio ECDSA, porque ya no se recomiendan las claves RSA de menos de 3000 bits ni las firmas RSA PKCS #1 v1.5. Dos reglas de certificado no se evalúan, porque todo certificado de confianza pública las incumple por las reglas del CA/Browser Forum: Certificate Policies críticas y un sujeto sin la dirección del servidor.
Fuentes
- 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
El NIST, el Instituto Nacional de Estándares y Tecnología de EE. UU., fija los estándares de seguridad que siguen las agencias federales estadounidenses. La Special Publication 800-52 es su guía para elegir y configurar TLS.
El perfil solo para la administración, porque quien elige NIST pide el listón federal. Es una lista de permitidos según su propio texto. Sus listas aprobadas excluyen ChaCha20 y X25519, así que la mayoría de los servidores fuera de un despliegue en modo FIPS la incumplen solo por eso. Exige un certificado de una CA que ofrezca OCSP, así que los certificados de las CA que han abandonado OCSP la incumplen. Solo permite el HMAC truncado para clientes con recursos limitados, de los que ninguna comprobación externa puede saber, así que cuenta como hallazgo. La revisión es de 2019; no hay una más reciente.
Fuente
- NIST SP 800-52 Rev. 2: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r2.pdf
Directrices TLS del NCSC-NL ncsc_nl
El NCSC-NL es el Centro Nacional de Ciberseguridad de los Países Bajos, dependiente del Ministerio de Justicia y Seguridad. Sus directrices TLS son la referencia para el gobierno neerlandés y sus proveedores, y se siguen ampliamente en la sanidad y las finanzas neerlandesas.
Cada ajuste se califica como Good, Sufficient, To be phased out o Insufficient. «To be phased out» e «Insufficient» son hallazgos, así que cumplir esta referencia significa que no se ofrece nada más débil que Sufficient. Las directrices no ponen fecha al abandono progresivo y lo dejan en manos del operador. Un conjunto de cifrado se califica por su parte más débil. Las claves RSA de menos de 3072 bits deben abandonarse, así que la mayoría de los certificados RSA públicos la incumplen. El perfil del certificado queda fuera del alcance de las directrices, así que sus reglas solo cuentan para la calificación.
Fuente
- Directrices TLS del NCSC-NL: https://www.ncsc.nl/en/transport-layer-security/tls-security-guidelines
Qué reglas cuenta cada referencia
Cada hallazgo y la cláusula por la que lo cuenta cada referencia. Una celda vacía significa que la referencia no dice nada al respecto. Los códigos de los hallazgos son los del detalle del resultado.
| Hallazgo | 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 |
Esta tabla se genera a partir de las reglas que aplican las comprobaciones, y una prueba falla si ambas difieren.
Lo que ninguna comprobación externa puede ver
Algunos requisitos de estas guías se refieren a cómo se comporta un servidor con clientes que no somos nosotros, o a lo que se ejecuta dentro de él. No se juzgan, y un servidor no pierde nada por ellos:
- la renegociación iniciada por el cliente, los datos 0-RTT y los modos de clave precompartida y de reanudación;
- los esquemas de firma de un handshake TLS 1.3, que van cifrados;
- las firmas de certificado con SHA-224, que nuestro lector de certificados no identifica;
- el interior del servidor: módulos criptográficos validados, generación de números aleatorios, parches.
Historial de cambios
| Fecha | Cambio |
|---|---|
| 2026-10-17 | Primeras ediciones: Mozilla 6.0; BSI TR-02102-2 2026-01 con TR-02103 1.0; NIST SP 800-52 Rev. 2; NCSC-NL 2025-05. |