Cómo utilizar el certificado SSL emitido por CA para la aplicación web de acceso interno (dirección IP de LAN)

Existe una alternativa, pero entre un certificado autofirmado y un certificado público de CA firmado. Como han dicho otros, no puede obtener una CA pública para firmar un certificado para una dirección IP interna (por ejemplo, algo en 10.0.0.0/8 o 192.168.0.0/16). No desea que sus usuarios acepten un certificado autofirmado. Eso deja una CA interna.

Tienes una intranet y sitios locales. Por lo que sé, tienes una VPN y enclaves de red remota. Esta es una configuración más sofisticada que las casas o pequeñas empresas, y debe pensar como una empresa mediana o grande con un departamento de TI.

Su departamento de TI necesita administrar su propia autoridad de certificación. Coloca la clave pública para la CA interna en las máquinas de sus usuarios para que confíen en los certificados firmados por su CA interna. Puede crear solicitudes de firma desde su servidor interno, firmar las solicitudes con su CA e instalar los certificados firmados en sus servidores internos. Ahora sus usuarios pueden ir a sus servidores sin advertencias.

Por seguridad, su CA debe ejecutarse en una máquina aislada o al menos una VM sin conectividad de red.

Para que esto funcione, también deberá ejecutar un servicio DNS interno que resuelva sus recursos locales y reenvíe las solicitudes de direcciones públicas a un servidor DNS ascendente. Los certificados de su servidor deben tener tanto el nombre de host como la dirección IP.

Puede hacer esto con Windows Server o con servidores Linux. Ambos harán el trabajo, y lo que es mejor depende de su situación exacta.

Esto requiere un mayor nivel de experiencia en TI. Puedes aprender cómo hacer esto y todas las cosas que lo acompañan. Debe intensificar, contratar a una persona que pueda manejar esto o contratar un negocio para administrar sus recursos de TI.

El certificado SSL resuelve dos propósitos: cifrado del tráfico (para el intercambio de claves RSA, al menos) y verificación de confianza. Como sabe, puede cifrar el tráfico con (o sin, si estamos hablando de SSL 3.0 o TLS) cualquier certificado autofirmado. Pero la confianza se logra a través de una cadena de certificados. No te conozco, pero confío en verisign (o al menos Microsoft sí, porque se les ha pagado mucho dinero para instalarlo en sus sistemas operativos de forma predeterminada), y dado que Verisign confía en ti, entonces confío en ti también. Como resultado, no hay una advertencia aterradora cuando voy a una página de SSL en mi navegador web porque alguien en quien confío ha dicho que eres quien eres.

En general, cuanto más caro es el certificado, más investigación realiza la autoridad emisora ​​del certificado. Entonces, para los certificados de Validación Extendida, los solicitantes deben presentar más documentos para demostrar que son quienes dicen ser, y a cambio obtienen una barra verde brillante y feliz en los navegadores web modernos (creo que Safari no hace nada con Es bastante todavía).

Finalmente, algunas compañías van con los grandes como Verisign solo por la marca; saben que sus clientes al menos han oído hablar de Verisign y, por lo tanto, para las personas que compran en su tienda en línea, su sello se ve un poco menos boceto que, por ejemplo, GoDaddy’s.

Si la marca no es importante para usted o si su sitio no es propenso a los ataques de phishing, entonces el certificado SSL más barato que puede comprar que tiene su raíz instalada en la mayoría de los navegadores web estará bien. Por lo general, la única verificación realizada es que debe poder responder a un correo electrónico enviado al contacto administrativo del DNS, “demostrando” que “posee” ese nombre de dominio.

Puede usar esos certificados baratos en servidores que no son GoDaddy, claro, pero probablemente primero tenga que instalar un certificado intermedio en el servidor. Este es un certificado que se encuentra entre su certificado barato de $ 30 y el certificado raíz de “trato real” de GoDaddy. Los navegadores web que visiten su sitio serán como “hmm, parece que esto fue firmado con un intermediario, ¿entendido?” cual

requiere

Puede requerir un viaje extra. Pero luego solicitará el intermediario de su servidor, verá que se encadena a un certificado raíz de confianza que conoce, y no hay ningún problema.

Pero si no puede instalar el intermedio en su servidor (como en un escenario de alojamiento compartido), entonces no tiene suerte. Esta es la razón por la cual la mayoría de la gente dice que los certificados GoDaddy no se pueden usar en servidores que no son GoDaddy. No es cierto, pero es lo suficientemente cierto para muchos escenarios.

(En el trabajo utilizamos un certificado SSL de Comodo para nuestra tienda en línea)

Editado en cursiva para reflejar las aclaraciones perspicaces de erickson a continuación. ¡Aprenda algo nuevo cada día!

Las autoridades de certificación deben seguir los requisitos de línea base de CA / Browser Forum para la emisión y gestión de certificados. Según las nuevas reglas, las autoridades de certificación de confianza no pueden emitir un certificado para la dirección IP reservada o el nombre interno del servidor.

El objetivo principal del certificado emitido por CA es proporcionar confianza web en todo el mundo cibernético. El certificado de emisión para nombres no únicos que se prueban en servidores locales puede ser mal utilizado peligrosamente. Por lo tanto, en orden por CAB Forum, CA dejó de emitir un certificado en la dirección IP reservada o en el nombre del servidor interno.

Para obtener información más detallada, debe leer los requisitos de referencia: https://cabforum.org/wp-content/

Según la directriz del foro de CA / B, el certificado SSL emitido por CA ya no está disponible para el servidor interno y la dirección IP reservada.

En su informe dijeron

Para los nombres internos no cubiertos por el proceso de gTLD de ICANN mencionado anteriormente, el 11 de noviembre de 2015, está prohibida la emisión de certificados con una dirección IP reservada o un nombre de servidor interno. El 1 de octubre de 2016, todos los certificados SSL / TLS de confianza pública con un nombre interno o una dirección IP reservada serán revocados y / o bloqueados por el software del navegador.

Para obtener más detalles sobre la guía del foro CA / B sobre nombres internos, lea aquí …

Puede usar absolutamente un certificado firmado por CA para asegurar una aplicación solo disponible internamente. Simplemente configure su aplicación para usar el certificado firmado por CA. Para una aplicación web estándar, esto probablemente se configurará en el servidor web (por ejemplo, Apache), no en la aplicación directamente (por ejemplo, en su PHP).

No veo ninguna razón por la que no pueda obtener un certificado firmado por CA para ‘www.internal.example.com’. Hasta donde yo sé, no hay ningún requisito para que esa dirección sea públicamente enrutable, o incluso públicamente resoluble; podría aprovisionarla como 10.0.0.100 en su DNS interno, o incluso en su DNS público, nadie externo podría llegar a él o averiguar dónde está, ya que es un bloque de direcciones no enrutable en Internet. Todo lo que necesita para un certificado firmado por CA es una prueba de que tiene derecho a administrar ‘example.com’; cómo administras subdominios o DNS depende de ti.

Lo que no puede obtener es un certificado solo para “www” o la dirección numérica “10.0.0.100”.

Deberá implementar DNS de horizonte dividido para que su DNS pueda resolverse tanto interna como externamente, con diferentes direcciones devueltas.

Los navegadores de los usuarios pensarán que están accediendo a la misma ubicación, ya sea dentro o fuera de la red, siempre que el DNS coincida con el Nombre común del certificado.

Puede usar un proxy DNS interno que resuelva alguna dirección en el dominio del certificado en su servidor. Digamos mycompany.com -> 10.0.0.100
Si solo hay una o pocas computadoras accediendo al servidor, entonces tal vez solo modifique sus archivos de host.