# Configurar TLS y HTTPS correctamente > Configuración TLS del servidor web según BSI TR-02102 y TLSRef: protocolos, cipher suites, certificados y comandos de prueba para Nginx, Apache y clientes PHP. Fuente: https://phpsos.de/es/blog/tls-https-richtig-konfigurieren/ Actualizado: 25/10/2026 Proveedor: PHP SOS, Ayuda de emergencia para PHP y seguridad de servidores. Ayuda inmediata por WhatsApp: https://wa.me/491736494914?text=Hola%20PHP%20SOS%2C%20necesitamos%20ayuda%20con%20nuestro%20servidor%20PHP.%20Empresa%3A%20%E2%80%A6%20Sitio%20web%3A%20%E2%80%A6 **En resumen:** una configuración TLS sólida para servidores web ofrece solo TLS 1.2 y TLS 1.3, usa cipher suites con Forward Secrecy y cifrado autenticado (AES-GCM, ChaCha20-Poly1305) y un certificado con clave ECDSA o RSA de longitud suficiente que se renueve automáticamente. Sirven de orientación la directriz TR-02102-2 de la Oficina Federal alemana de Seguridad de la Información (BSI) y las recomendaciones Server-Side TLS de TLSRef. Compruebe el resultado desde fuera y no olvide las conexiones que establece el propio PHP. ## Por qué los ajustes TLS antiguos sobreviven tanto tiempo El candado está en el navegador, así que el cifrado se da por resuelto. Así piensan muchos operadores, y por eso la configuración TLS suele permanecer sin cambios durante años. Procede entonces de la época de la puesta en marcha del servidor, de una plantilla copiada o de los valores predeterminados de un panel. El problema: las recomendaciones cambian. Se sustituyen versiones de protocolo, ciertos procedimientos pasan a considerarse débiles y aparecen nuevos métodos de intercambio de claves. La BSI publicó por última vez la TR-02102 en la versión 2026-01 del 27 de enero de 2026 y ya menciona en ella procedimientos híbridos poscuánticos para TLS 1.3. Quien no ha revisado sus ajustes en años, con alta probabilidad ya no está al día. Quien de todos modos está revisando servidores tras PHP2Shell puede mirar la configuración TLS de una vez. No cierra la vulnerabilidad de PHP, pero forma parte de cualquier refuerzo bien hecho. ## En qué se basa una buena configuración TLS para servidores web Dos fuentes resultan especialmente útiles para los operadores en Europa. La **BSI TR-02102** evalúa procedimientos criptográficos; la parte 2 trata de TLS. Se dirige sobre todo a desarrolladores y planificadores y, para las administraciones y los sectores regulados, suele ser el estándar de referencia. Las **recomendaciones Server-Side TLS**, mantenidas antes en la wiki de Mozilla, se siguen hoy en TLSRef y ofrecen perfiles concretos que se pueden copiar. En la versión 6.0, TLSRef distingue dos perfiles: | Característica | Intermediate (para la mayoría de los sitios web) | Modern | |---|---|---| | Protocolos | TLS 1.2 y TLS 1.3 | solo TLS 1.3 | | Cipher suites TLS 1.2 | ECDHE con AES-GCM o ChaCha20-Poly1305 | ninguna | | Grupos de intercambio de claves | X25519MLKEM768, X25519, prime256v1, secp384r1 | como Intermediate | | Certificado | ECDSA P-256 recomendado o RSA de 2048 bits | ECDSA P-256 | | Validez del certificado | 90 días recomendados, como máximo 366 días | 90 días | | HSTS max-age | dos años | dos años | Para los sitios web públicos, Intermediate es el punto de partida habitual. El perfil excluye equipos muy antiguos, pero cubre los navegadores y sistemas operativos actuales. El grupo híbrido X25519MLKEM768 requiere una biblioteca TLS actual. Compruebe si su versión de OpenSSL lo conoce antes de incluirlo. ## Nginx y Apache: un punto de partida seguro Los ejemplos siguientes aplican el perfil Intermediate. Las rutas son marcadores de posición; la lista de cipher suites vale para TLS 1.2, mientras que TLS 1.3 trae sus propios procedimientos estándar seguros. ```nginx server { listen 443 ssl; server_name www.example.de; ssl_certificate /etc/ssl/example/fullchain.pem; ssl_certificate_key /etc/ssl/example/privkey.pem; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305; ssl_prefer_server_ciphers off; } server { listen 80; server_name www.example.de; return 301 https://$host$request_uri; } ``` ```apache SSLProtocol -all +TLSv1.2 +TLSv1.3 SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305 SSLHonorCipherOrder off ``` El segundo bloque `server` redirige de forma permanente las llamadas sin cifrar a HTTPS. La redirección debería apuntar directamente a la dirección definitiva y no pasar por varias estaciones intermedias. Revise después también los recursos incrustados: imágenes, scripts o fuentes que aún se cargan por HTTP provocan advertencias en el navegador o son bloqueados. El ajuste por el que el cliente elige el orden corresponde a la recomendación de TLSRef: todos los procedimientos ofrecidos se consideran seguros y los dispositivos sin aceleración AES pueden así preferir ChaCha20. Tras cada cambio, pruebe la configuración (`nginx -t` o `apachectl configtest`) y recargue el servicio. La cabecera HSTS adecuada y otras directrices para el navegador se describen en la guía [Cabeceras de seguridad para sitios web](https://phpsos.de/es/ratgeber/sicherheits-header/). > **Consejo:** > Paneles como Plesk o cPanel suelen sobrescribir los cambios propios en archivos generados. Fije allí los ajustes TLS mediante las opciones o plantillas previstas por el panel. ## Certificados: clave, cadena, renovación Gran parte de los problemas de TLS en la práctica no tiene nada que ver con las cipher suites, sino con los certificados. Errores típicos son una cadena incompleta en la que falta el certificado intermedio, certificados caducados en subdominios secundarios y claves privadas con permisos de archivo demasiado amplios. Ayudan tres reglas: 1. **Renovar automáticamente** y supervisar la renovación. Las validez cortas que recomienda TLSRef solo son viables con automatización. 2. **Proteger las claves privadas:** legibles solo para root y el proceso del servidor web, nunca en el webroot, nunca en un repositorio. 3. **Registrar todos los nombres:** dominio principal, www, subdominios de tienda, staging, interfaz web de correo y paneles. Quien usa certificados en varios lugares, por ejemplo en CDN, balanceador de carga y servidor de origen, debería llevar una relación: qué certificado está instalado dónde, quién lo renueva y cuándo caduca. Sin esa relación, un certificado caducado a menudo solo se descubre cuando se quejan los clientes. ## Cómo comprobar su configuración desde fuera Los comandos siguientes son meras comprobaciones y no modifican nada. Sustituya el nombre de host por el suyo: ```bash # TLS 1.3 y TLS 1.2 deberían funcionar openssl s_client -connect www.example.de:443 -servername www.example.de -tls1_3 /dev/null | openssl x509 -noout -subject -dates ``` Un fallo en la prueba de TLS 1.1 puede deberse también a que su versión local de OpenSSL ya no ofrece ese protocolo antiguo. Para un informe completo de todos los procedimientos ofrecidos, resulta adecuado un escáner TLS especializado. Compruebe cada subdominio por separado, porque a menudo funcionan con ajustes propios. ## Lo que se olvida: TLS donde PHP mismo es cliente Las aplicaciones PHP establecen por sí mismas muchas conexiones: con proveedores de pago, empresas de transporte, interfaces, servidores de correo y bases de datos. Aquí el error más frecuente no es un ajuste débil, sino una verificación del certificado desactivada, a menudo como solución rápida a un problema durante el desarrollo. ```php true, CURLOPT_SSL_VERIFYPEER => true, CURLOPT_SSL_VERIFYHOST => 2, CURLOPT_TIMEOUT => 10, ]); $antwort = curl_exec($ch); ``` Busque en el código `CURLOPT_SSL_VERIFYPEER` con `false` y `verify_peer` en contextos de stream. Cada hallazgo anula en la práctica la protección de TLS para esa conexión. Donde los servicios estén detrás de un CDN, también el tramo entre el CDN y el servidor de origen debería usar un certificado válido y verificado. Más ajustes del servidor web para configuraciones PHP los encontrará en [Configurar Nginx para PHP de forma segura](https://phpsos.de/es/blog/nginx-fuer-php-absichern/), y criterios para todo el refuerzo en [Benchmarks CIS y módulos de la BSI](https://phpsos.de/es/blog/cis-benchmarks-bsi-bausteine/). ## ¿Cómo ayuda PHP SOS en concreto? - Registramos todos los nombres de host y servicios con TLS, incluidos paneles, staging e interfaces web de correo. - Contrastamos los ajustes con TR-02102 y el perfil TLSRef adecuado y documentamos las desviaciones deliberadas. - Pasamos los certificados a renovación automática con supervisión. - Buscamos en el código de la aplicación verificaciones de certificado desactivadas y mostramos la corrección. TLS es un módulo de nuestro [refuerzo de servidores web PHP](https://phpsos.de/es/leistungen/server-haertung/); la relación con la situación actual la explica [¿Qué es PHP2Shell?](https://phpsos.de/es/php2shell/was-ist-php2shell/). ## Preguntas frecuentes **¿Tengo que seguir ofreciendo TLS 1.0 y TLS 1.1?** Por lo general, no. Recomendaciones actuales como el perfil Intermediate de TLSRef fijan TLS 1.2 como límite inferior. Quien necesite protocolos antiguos para equipos heredados debería decidirlo de forma consciente, documentarlo y limitarlo a un servicio separado. **¿Es un certificado gratuito menos seguro que uno de pago?** Para el cifrado no hay diferencia. Lo decisivo son el tipo y la longitud de la clave, una cadena de certificados completa y una renovación automática fiable. Las diferencias están en el alcance de la verificación, la validez y el servicio del proveedor. **¿Basta con HTTPS entre el visitante y el CDN?** No. También la conexión entre el CDN y el servidor de origen debería estar cifrada y verificar el certificado del origen. De lo contrario, los datos circulan sin cifrar o sin verificar por la red en el segundo tramo. **¿Qué tiene que ver TLS con PHP2Shell?** Directamente nada. TLS protege los datos durante el transporte; PHP2Shell afecta al intérprete de PHP en el servidor. Una conexión cifrada transporta también con fiabilidad las peticiones de ataque, por lo que la actualización de PHP sigue siendo obligatoria, independientemente de ello. ## Fuentes - [BSI TR-02102: procedimientos criptográficos, parte 2 TLS](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/Technische-Richtlinien/TR-nach-Thema-sortiert/tr02102/tr-02102.html) - [TLSRef: Server-Side TLS Guidelines](https://docs.tlsref.org/) - [Documentación de Nginx](https://nginx.org/en/docs/) - [Apache HTTP Server: documentación](https://httpd.apache.org/docs/)