☰

Jaque mate sobre certificados TLS en redes locales, certificados autofirmados y CA

tag-icon • tag-icon vpn ssl certificate https tls
Jaque mate sobre certificados TLS en redes locales, certificados autofirmados y CA

No sé casi nada sobre certificados SSL y TLS. Lo lamento.

Esto es lo que me pidió mi empresa:

  1. Necesitan colocar un servidor en la red local al que puedan acceder a través de VPN personas de todo el país.
  2. Quieren que este servidor se comunique mediante HTTPS.
  3. Quieren que el servidor tenga un certificado TLS creado por una CA certificada.
  4. Me dicen que el servidor es un servidor Microsoft IIS.

Lo que he descubierto hasta ahora:

  1. Es imposible tener un certificado SSL creado por una CA certificada para un servidor de intranet cuya dirección server.mydomain.localno sea accesible desde Internet.
  2. La única forma de tener un certificado SSL para ese servidor será un certificado autofirmado, pero estos certificados no son famosos por ser confiables para cosas como iOS, etc. iOS odia los certificados autofirmados y lo suyo son básicamente dispositivos iOS que acceden a un servidor local.

Lo que necesito es confirmación de que tengo razón o si no, cómo solucionar este jaque mate.

gracias

Respuesta1

Tiene razón en que las CA públicas solo emitirán certificados para nombres de dominio públicos (ya que eso es lo que pueden verificar). Sin embargo, se le escapa que esto no necesariamente tiene nada que ver con si el servidor es accesible públicamente o no, ni siquiera con si tiene una dirección IP pública o no.El servidor no tiene queserpublic para tener un nombre de dominio público.

La CA solo se preocupa por verificar la propiedad del nombre que estará en la URL.AlgunoLas CA, como Let's Encrypt, normalmente lo hacen conectándose al servidor a través de HTTP (aunque ya no es la única opción). Pero muchas otras CA le permitirán verificar solo la propiedad de todo el dominio (posiblemente a través de registros Whois) y luego emitir certificados libremente para cualquier subdominio, incluso los subdominios que no tienen un servidor web o aquellos que no tienen nada públicamente. accesibles, o incluso subdominios que no existen en absoluto.

Entonces supongo que la empresa ya tiene un sitio web y, por lo tanto, un nombre de dominio público. Hay varias formas de hacerlo, dependiendo de con qué se sienta cómoda la empresa:

  • Podría hacer que el servidor use una dirección IP pública normal y ponerla en DNS como lo haría siempre... y simplemente hacer que el servidor rechace todas las conexiones que no se realicen a través de la VPN, por ejemplo, usando el Firewall de Windows o algunas configuraciones específicas de IIS.

    (La mayoría de los sistemas VPN se pueden configurar para enrutar cualquier rango de direcciones IP a través del túnel seguro, no importa si las direcciones IP son "públicas" o "privadas". Enrutar el rango de IP públicas de la empresa a través de la VPN corporativa es algo normal. hacer.)

  • Puede crear un subdominio que apunte a una dirección IP interna (por ejemplo, server.corp.mydomain.compuede ser un subdominio público que apunte a 192.168.7.1, una dirección IP privada a la que solo se puede acceder a través de una VPN) y eso no impedirá que tenga una dirección IP interna. Certificado HTTPS públicamente válido emitido.

    (Esto no necesita nada especial en términos de configuración de DNS; literalmente, puede apuntar un dominio a cualquier dirección que desee).

  • Podría tener el servidor web real en una dirección IP privada, pero utilizar un servidor front-end "proxy inverso" en una dirección IP pública. El proxy inverso podría manejar el acceso basado en IP, así como la autenticación SSO o de contraseña. Incluso podría manejar la emisión de certificados basados ​​en HTTP de Let's Encrypt en nombre del servidor privado real.

    (Usamos este método para proporcionar acceso HTTPS seguro a algunas aplicaciones web antiguas y oxidadas; una de ellas todavía se ejecuta en Server 2003 y no puede manejar navegadores modernos en absoluto; en cambio, el proxy inverso proporciona el soporte TLS 1.2 necesario, así como autenticación SAML).

(También hay otras opciones. Además de las CA públicas, cualquiera puede crear su propia CA y la mayoría de las redes corporativas que ejecutan Microsoft AD tendrán una; el único problema es lograr que los dispositivos confíen en esa CA, pero para los iPhone emitidos por la empresa eso debería ser fácil de hacer a través de cualquier sistema de "administración de dispositivos móviles" que esté utilizando la empresa. Aunque no le diga a la gente que instale una CA de la empresa en sistemas personales...)

información relacionada