Un certificado VPN propio no es una capa de cifrado adicional

Instalar un certificado propio en un extremo de VPN parece añadir protección, porque los certificados y el cifrado aparecen juntos en todas partes. En la práctica cambia dos cosas: qué identidad presenta el extremo y en qué emisor su par está dispuesto a confiar. Ninguna de las dos envuelve sus datos por segunda vez. Si la necesidad real es un segundo canal protegido, necesita un segundo canal con sus propios extremos, no otro certificado.

Tres tareas separadas en un handshake TLS 1.3

RFC 8446 mantiene estas cosas separadas, y esa separación es toda la respuesta. El mensaje Certificate transporta la cadena de certificados del extremo. CertificateVerify demuestra la posesión de la clave privada correspondiente y vincula la transcripción del handshake. La capa de registro protege el tráfico con las claves de tráfico negociadas.

Cambie el certificado y los dos primeros elementos cambian. La protección de registro no se ejecuta dos veces y no se vuelve más fuerte porque el emisor ahora sea privado.

Qué compra realmente una CA privada

Compra un sistema de identidad controlado: usted decide quién recibe la emisión, usted decide qué emisores aceptan los pares y puede revocar según su propio calendario. Eso es realmente útil cuando gestiona ambos extremos.

También incorpora obligaciones. La confianza debe distribuirse de forma deliberada, la verificación del par debe seguir activa y alguien debe ser responsable del ciclo de vida de las credenciales. Una CA privada no es un atajo alrededor de ninguna de esas tres.

Cuándo un segundo canal es la respuesta correcta

Supongamos que una aplicación abre HTTPS verificado hacia su propio servicio mientras sus paquetes también viajan por una VPN. Ese diseño tiene dos fronteras con extremos potencialmente distintos, y así es como se ve un segundo canal protegido.

La distinción importa en la puerta de enlace. Si la sesión TLS de la aplicación termina en la puerta de enlace VPN en lugar de en la aplicación, la protección que creía tener más allá del túnel no está ahí. Escriba quién termina cada canal antes de afirmar la propiedad.

Pregunte qué cambia la instalación

Una solicitud para instalar un certificado puede significar tres cosas distintas. Puede cambiar la identidad del propio cliente, un ancla de confianza específica de una aplicación o la confianza en toda la plataforma para todo en el dispositivo. No son equivalentes, y solo la última afecta a software no relacionado.

Pregunte cuál de las tres se pretende y luego qué debe conseguir. Si la respuesta es más cifrado, la propuesta apunta al mecanismo equivocado.

Escriba las fronteras

Para cada canal, registre los extremos, la identidad que verifica cada lado y lo que puede ver el operador en medio. Después registre el comportamiento ante fallos: qué ocurre cuando falla la verificación y qué ocurre cuando el canal se rechaza.

Dos líneas en una página suelen resolver una discusión que una rotación de certificados no puede.

Decida con tres preguntas

¿El problema es quién dice el extremo que es, o qué ocurre con los datos? ¿Debe la protección continuar más allá de la puerta de enlace VPN hasta una aplicación concreta? Y ¿puede nombrar los dos extremos que terminarían un segundo canal?

Si la primera pregunta es la real, corrija la identidad y la confianza. Si lo es la segunda o la tercera, diseñe el segundo canal y deje el certificado donde corresponde.