TLS y certificados entre servicios

En un TLS normal el cliente comprueba el certificado del servidor: que lo firma una autoridad en la que confía, que el nombre coincide y que no ha caducado. El servidor, en cambio, no sabe quién es el cliente más allá de lo que este le diga después.

En TLS mutuo (mTLS) el servidor también exige un certificado al cliente y lo valida. Entre servicios internos es útil porque cada llamada lleva una identidad de máquina comprobable, sin depender solo de que la red interna sea de confianza. No sustituye la autorización: saber quién llama no dice qué puede hacer.

La IETF deprecó TLS 1.0 y TLS 1.1 en el RFC 8996 (2021): ninguna implementación debería negociarlos. Hoy el mínimo razonable es TLS 1.2 y el preferible, TLS 1.3. La columna version_minima dice qué es lo más bajo que acepta negociar cada cliente.

Un cliente que no verifica el certificado del destino cifra el canal, pero no sabe con quién habla: cualquiera que se interponga con otro certificado sería aceptado. Suele aparecer como una opción puesta para que una prueba pase y que acaba en producción. Lo que se revisa es la columna verifica_certificado.

Un certificado caducado rompe el servicio de golpe, y las caídas por caducidad son de las más evitables. La política de Vientoazul pide empezar a renovar con 30 días de margen. Hoy es 7 de octubre de 2026: el margen llega hasta el 6 de noviembre. Cuenta los enlaces cuyo certificado del destino ya caducó o caduca dentro de ese margen.

El del proveedor de mensajería caducó el 30 de septiembre y la facturación no puede notificar. La renovación puntual lo arregla hoy; el problema de fondo es que nadie lo vio venir. En un pipeline, los certificados internos suelen renovarse con un protocolo automático (por ejemplo ACME, definido en el RFC 8555) contra una autoridad interna, con avisos antes de la fecha.