Auto SSL
Emita y renueve certificados para sus hostnames automáticamente.
Abrir el temaAyuda de CDN.com.tr
Política de TLS en el edge
El edge de CDN.com.tr acepta solo TLS 1.2 y TLS 1.3, con una lista de intercambio de claves ECDHE y cifrados AEAD preferida por el servidor. TLS 1.0, TLS 1.1, RC4, 3DES, MD5 y los cifrados de exportación se rechazan.
Certificados SSL
Política de TLS en el edge
El edge de CDN.com.tr acepta solo TLS 1.2 y TLS 1.3, con una lista de intercambio de claves ECDHE y cifrados AEAD preferida por el servidor. TLS 1.0, TLS 1.1, RC4, 3DES, MD5 y los cifrados de exportación se rechazan.
Ruta en el panel
- Not a panel setting
- Edge configuration, applied to every account
Requisitos previos
- Un hostname suyo ya servido por el CDN.
- openssl en su máquina si quiere reproducir la evidencia.
Verificación
- openssl s_client -connect www.example.com:443 -servername www.example.com -tls1_1 — el handshake se rechaza, reportando que no hay protocolos disponibles.
- openssl s_client -connect www.example.com:443 -servername www.example.com -tls1_3 — el handshake tiene éxito y reporta TLS_AES_256_GCM_SHA384.
- Un cliente que ofrece un cifrado CBC primero igual termina en un cifrado AEAD, porque la selección la prefiere el servidor.
Casos de uso
Un cuestionario de seguridad, una licitación, o su propio escáner pregunta qué versiones de TLS y cifrados acepta su sitio. La respuesta es la misma para todas las cuentas: se fija en el edge y no es una configuración por cuenta.
Flujo de trabajo
- Responda la pregunta con la política de abajo — se aplica a todos los hostnames servidos por el CDN.
- Si necesita evidencia en lugar de una afirmación, ejecute las verificaciones de openssl de la lista de verificación contra su propio hostname.
- Si un cliente suyo no puede conectarse, identifique su versión de TLS antes de asumir un problema de certificado.
Verificaciones
- Aceptado: TLS 1.2 y TLS 1.3.
- Rechazado: TLS 1.0 y TLS 1.1. Un intento de handshake en esas versiones se cierra, no se degrada.
- La selección de cifrado la prefiere el servidor: el edge elige de su propia lista ordenada en lugar de respetar el orden del cliente.
- La lista es de intercambio de claves ECDHE con cifrados AEAD. RC4, 3DES, MD5, NULL y los cifrados de nivel de exportación no se ofrecen.
- No hay un interruptor por cuenta para esto. No está en Delivery Rules ni en SSL Management, porque una opción más débil para un cliente debilitaría el edge compartido.
- Un cliente muy antiguo que solo habla TLS 1.0 no puede conectarse. Ese es el resultado buscado de la política.
Preguntas frecuentes
¿Pueden habilitar TLS 1.0 para un cliente heredado nuestro?
No. La lista de protocolos es compartida por todos los sitios del edge, así que una excepción para una cuenta debilitaría a todas. TLS 1.0 y 1.1 están obsoletos y fallan en toda línea base de cumplimiento vigente — normalmente la misma línea base que le llevó a preguntar.
Nuestro escáner reporta un cifrado CBC. ¿Es un hallazgo?
La lista ofrecida mantiene una cola de CBC después de los cifrados AEAD para clientes antiguos. Como la selección la prefiere el servidor, cualquier cliente moderno negocia un cifrado AEAD — un escáner lista lo que se ofrece, no lo que se usa. Compruebe el cifrado negociado de una conexión real antes de tratarlo como un hallazgo.
¿Esto depende de mi certificado?
No. Las versiones de protocolo y los cifrados son política del edge; su certificado decide la identidad, no los parámetros del handshake. Un certificado Auto SSL y un certificado comercial subido reciben exactamente la misma política de TLS.
¿Cómo demuestro esto a un auditor?
Ejecute los dos comandos openssl de la lista de verificación contra su propio hostname y adjunte la salida. El intento de TLS 1.1 falla y el intento de TLS 1.3 reporta un cifrado AEAD negociado; juntos muestran las dos mitades de la política.