Endurecimiento TLS de Apache en 2026 — cifrados, OCSP stapling y el pipeline de renovación de cert

Cada instalación de Apache que auditamos tiene una config TLS que alguien copió y pegó de una guía Mozilla en 2019. Las suites de cifrado son demasiado largas. Los protocolos aún permiten TLS 1.0 en una línea SSLProtocol all -SSLv3 que nadie ha actualizado. OCSP stapling está apagado porque falló una vez durante un cambio de firewall y nunca se volvió a habilitar. La renovación de cert es un cron de Certbot que nadie monitoriza hasta que se detiene.

Esta es la config TLS que entregamos en cada host Apache gestionado en 2026.

El bloque SSL del vhost

SSLProtocol             -all +TLSv1.2 +TLSv1.3
SSLHonorCipherOrder     off
SSLSessionTickets       off
SSLUseStapling          on
SSLStaplingResponderTimeout 5
SSLStaplingReturnResponderErrors off
SSLCipherSuite TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305
 
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"

TLS 1.3 no necesita SSLCipherSuite — sus suites se negocian independientemente. La línea SSLHonorCipherOrder off es correcta en 2026: los clientes modernos eligen el cipher mejor que tu config.

El artículo completo cubre:

• Por qué los session tickets están desactivados (la forward secrecy no es real si reutilizas una clave de ticket durante semanas)
• OCSP stapling — cómo evitar que falle silenciosamente
• El hook certbot + apache-reload que sobrevive a certbot renew
• Monitoreo de certs: alertar a 30/14/7 días restantes, no al vencimiento
• El job ssllabs-scan que ejecutamos semanalmente sobre la flota
• HSTS preload — la decisión irreversible y cómo escalonarla

Entregamos esta configuración en cada instalación Apache gestionada.