En la web actual, el protocolo HTTPS dejó de ser exclusivo de pasarelas bancarias para convertirse en el requisito base de cualquier sitio público. Además de proteger la confidencialidad e integridad del tráfico frente a ataques de intermediario (Man-in-the-Middle), navegadores modernos como Chrome y Safari restringen APIs esenciales (como ServiceWorker, AudioWorklet, WebAuthn y navigator.wakeLock) exclusivamente a Contextos Seguros (HTTPS).
1. Por qué TLS 1.3 Reduce la Latencia de Conexión a la Mitad
En TLS 1.2, establecer una conexión segura requería dos viajes completos de ida y vuelta (2-RTT) entre el navegador y el servidor después del handshake TCP de 3 vías antes de poder enviar el primer byte de la petición HTTP. En conexiones móviles con una latencia base de 80 ms, solo el saludo criptográfico consumía más de 240 ms.
El estándar TLS 1.3 (RFC 8446) elimina algoritmos criptográficos heredados vulnerables y envía la compartición de claves efímeras Diffie-Hellman (ECDHE) desde el primer paquete ClientHello, completando la negociación en un solo viaje (1-RTT) y habilitando 0-RTT Resumption para visitantes recurrentes.
2. El Flujo Interno de Cert-Manager y ACME HTTP-01 en Kubernetes
Cuando administramos múltiples dominios y subdominios en un clúster Kubernetes (por ejemplo, el portal corporativo principal y sus aplicaciones web satélites), renovar certificados manualmente cada 90 días es propenso a errores humanos. El operador cert-manager automatiza este flujo mediante cuatro recursos coordinados:
- Certificate: Define los nombres DNS (
dnsNames) y el nombre delSecretdonde se guardará el par de claves pública/privada. - CertificateRequest & Order: Solicita la orden de emisión a la autoridad certificadora Let's Encrypt mediante el protocolo ACME v2.
- Challenge (HTTP-01): Levanta dinámicamente un pod ligero y una regla de Ingress de alta prioridad para la ruta exacta
/.well-known/acme-challenge/<token>. - Renovación Proactiva: A los 60 días de vida del certificado (30 días antes de su expiración), cert-manager repite el desafío en segundo plano y actualiza el
Secreten caliente sin tiempo de inactividad (Zero-Downtime Reload) en Traefik.
3. Diagnóstico de Desafíos ACME Atascados
Si un certificado permanece en estado Issuing durante horas, la causa suele encontrarse en una de tres áreas verificables con kubectl describe challenge:
- Registros DNS A/CNAME faltantes: Si un subdominio secundario (como un prefijo
wwwen un subdominio de tercer nivel) no tiene un registro DNS público apuntando a la IP externa del nodo, los servidores de validación de Let's Encrypt recibiránNXDOMAIN. - Reglas de Ingress solapadas: Si otro Ingress captura la ruta raíz sin permitir que el solver HTTP-01 tenga precedencia en
/.well-known/acme-challenge/. - Firewall de red en el puerto 80: El desafío HTTP-01 inicia siempre por el puerto 80 TCP antes de seguir redirecciones a HTTPS.
Mantener únicamente los nombres de host que cuentan con resolución DNS verificada dentro de la sección tls.hosts del manifiesto Ingress garantiza renovaciones limpias y libera al clúster de pods solucionadores pendientes.