¿Por qué OpenVPN requiere compartir certificados de forma segura con los clientes?

Veamos un desglose de todos los archivos, si son confidenciales y de dónde provienen.

/etc/openvpn/ca.crt

Desechable públicamente, este es el certificado para la autoridad de certificación de su VPN. Se puede compartir con cualquiera y permite que el cliente verifique el servidor VPN.

/etc/openvpn/easy-rsa/keys/hostname.crt

Este es un certificado que identifica al cliente. Fue firmada por la clave privada del cliente y luego fue firmada por la clave de la AC.

/etc/openvpn/easy-rsa/keys/hostname.key

Esta es la clave privada del cliente. En la documentación que está viendo, se generó en el servidor para su comodidad, de modo que el certificado del cliente se puede firmar con la clave allí y luego con la clave de CA. La clave privada podría generarse y mantenerse en el cliente sin que el servidor la viera, pero eso haría el proceso mucho más complejo. Si está interesado, haga una búsqueda en Google o abra otra pregunta para crear una CA privada, es un departamento completamente diferente.

/etc/openvpn/ta.key

Este es un poco especial, así que solo pegaré algo relacionado que encontré en enlace :

  

tls-auth

     

La directiva tls-auth agrega una firma HMAC adicional a todos los paquetes de intercambio de SSL / TLS para la verificación de integridad. Cualquier paquete UDP que no lleve la firma HMAC correcta puede eliminarse sin procesamiento adicional. La firma tls-auth HMAC proporciona un nivel adicional de seguridad por encima y más allá del proporcionado por SSL / TLS. Puede proteger contra:

     

• Ataques DoS o inundación de puertos en el puerto UDP OpenVPN.
  
• Exploración de puertos para determinar qué puertos UDP del servidor están en estado de escucha.
  
• Vulnerabilidades de desbordamiento de búfer en la implementación de SSL / TLS.
  
• Iniciaciones de protocolo de enlace SSL / TLS desde máquinas no autorizadas (mientras que dichos protocolos finalmente no se autentificarán, tls-auth puede cortarlos en un punto mucho más temprano).
  

El uso de tls-auth requiere que genere una clave secreta compartida que se use además del certificado / clave RSA estándar:

     

openvpn --genkey --secret ta.key

Resumen

Sí, es posible compartir todo lo necesario en claro, excepto ta.key, si genera la clave del cliente localmente y tiene un buen método para verificar que usó las claves correctas. El sistema puede ser seguro sin ta.key, es solo una medida adicional para limitar a los forasteros. Dicho esto, es una muy buena medida.

En pocas palabras: la clave pública ( hostname.crt ) se deriva , matemáticamente, de la clave privada, y se usa para verificar que el cliente realmente posee la clave privada correcta (y es capaz de descifrarlo en caso de que esté protegido).

Por lo tanto, es absolutamente necesario que obtenga la clave privada al cliente de forma segura; sin esto, la clave pública en el servidor es un tanto inútil.

En cuanto a los demás: el cliente utiliza ca.crt para verificar que efectivamente se está conectando al servidor correcto (y no a un MITM), y ta.key es un secreto compartido para ambos el cliente y el servidor (básicamente, "algo que tienes").

Este es un problema común para todas las soluciones VPN que usan certificados. Solo puede usar el secreto compartido (por ejemplo, nombre de usuario + contraseña cuando usa PPTP), pero esto es 1) por lo general es mucho menos seguro ya que la contraseña no es muy larga y 2) no lo protege de los ataques MITM.

Sí, es posible configurar OpenVPN, por lo que solo necesita instalar la clave pública y el certificado del cliente en el servidor, y solo necesita instalar la clave pública del servidor y el certificado del servidor en el cliente.

Las claves públicas y los certificados no son confidenciales. No son confidenciales: se pueden compartir de manera segura con el mundo, si por alguna razón lo quisieras. No revelan la clave privada.