¿Certificados SSL internos?

10

Como desarrollador, me gusta mucho la idea de utilizar OpenSSL para obtener certificados SSL gratuitos, absolutamente buenos. Desafortunadamente, de todas las investigaciones / análisis que he realizado hasta ahora, no parece que haya ninguna forma de usar OpenSSL de tal manera que los navegadores de mis usuarios web confíen en los certificados que genera para mí.

Parece que, para evitar que mis usuarios reciban mensajes de advertencia desagradables de sus navegadores (quejándose de que mis certificados generados por OpenSSL no son confiables / verificados), voy a tener que usar un proveedor importante como Trustwave, VeriSign, etc.

Me pregunto si existe tal concepto de certificados SSL "públicos" frente a "privados". Con eso, quiero decir, compraría un certificado SSL "público" de uno de estos proveedores, y lo usaría para todas las comunicaciones entre los navegadores de mis usuarios y mis servidores HTTP públicos. Pero una vez que se consume un mensaje del lado del servidor, se comunicaría con el resto del back-end utilizando diferentes certificados "privados" (generados por OpenSSL).

La idea detrás de esto es mantener los datos en movimiento a través de mi back-end usando transportes seguros, pero no tener que pagar por un bazillion de certificados SSL diferentes.

¿Es esto inaudito o completamente innecesario? ¿O es esta práctica estándar?

¿Por qué necesitaría que los datos estén seguros entre 2 de mis propios servidores backend? No lo sé. Probablemente no es necesario que lo esté, pero es probable que no te duela. ¿Pensamientos?

    
pregunta zharvey 02.07.2012 - 16:56
fuente

2 respuestas

12

Sí, para su backend, simplemente puede generar certificados autofirmados con OpenSSL como ya lo ha hecho. La diferencia es que, a continuación, debe indicar a sus servidores front-end que confíen en esos certificados (cómo depende la plataforma utilizada).

Alternativamente, puede configurar su propia CA privada (autoridad de certificación, por ejemplo, Verisign) y hacer que sus servidores front-end confíen en su certificado raíz, luego usarlo para generar certificados para sus servidores back-end. Esto lo hace más fácil si necesita usar muchos certificados, aparte de que no hay diferencia.

Así es exactamente cómo funcionan los certificados "públicos", excepto que los certificados raíz de las CA conocidas se incluyen con, por ejemplo, los navegadores Son de confianza porque realizan comprobaciones de, por ejemplo, su identidad, y eso es lo que cobran, no por los aspectos técnicos de la creación de un certificado.

Por supuesto, existe la cuestión de si es necesario asegurar la comunicación de frontend-backend. ¿Alguien tiene la posibilidad de escuchar en la línea? Eso depende de su configuración de alojamiento.

    
respondido por el Bart van Heukelom 02.07.2012 - 17:02
fuente
6
  

La idea detrás de esto es mantener los datos en movimiento a través de mi back-end usando transportes seguros, pero no tener que pagar por un bazillion de certificados SSL diferentes.

Puede usar enlace para emitir sus certificados de free . Los he usado antes y funciona bien (muestra un candado verde) en todos los navegadores que he probado hasta ahora. El certificado gratuito también le permite un subdominio gratuito.

Si está dispuesto a desembolsar algo de dinero, los certificados Clase 2 de ellos permiten comodines, lo que significa que puede tener un certificado para *.yourdomain.com y puede usarlo para validar todos sus subdominios p.ej. mail.yourdomain.com , ftp.yourdomain.com etc. con un solo certificado.

Nuevamente, puede usar los certificados OpenSSL para la comunicación interna, como sugirió Bart. La forma en que funcionará es:

  • Su sitio web externo utiliza un certificado (proporcionado por startSSL o verisign).
    • Sus visitantes acceden a él usando https://www.yourdomain.com/whateverpage
    • Dado que proviene de una CA válida (reconocida y confiable por los navegadores), sus usuarios nunca verán una advertencia de SSL. Periodo.
  • Ahora suponga que desde su código, necesita llamar a una api interna (REST / SOAP) alojada en una máquina interna.
    • Lo llamas desde tu código (usando rest / soap / cualquier cliente) como https://10.23.42.23/getDetails?user=blah . Suponiendo que este servicio se ejecute en una instancia de servidor web diferente, puede usar un certificado SSL openSSL que haya creado. Cuando su código de yourdomain.com consulta esta API a través de https, será sobre SSL (por lo tanto, encriptado) y como su navegador no consume su API, obviamente no marcará ningún error de SSL para el usuario.
    • Sin embargo, es posible que deba configurar su código (cliente REST / SOAP) para ignorar cualquier advertencia de SSL.

Debido a la falta de conocimiento de su arquitectura exacta, he hecho generalizaciones en mi ejemplo, sin embargo, transmite lo básico.

  

¿Es esto inaudito o completamente innecesario? O es esta norma   ¿práctica?

No es raro ver este tipo de configuración, por lo que definitivamente estás pensando en la dirección correcta.

  

¿Por qué necesitaría que los datos estén seguros entre 2 de mis propios servidores backend? No lo sé. Probablemente no necesita serlo, pero probablemente no pueda hacer daño. ¿Pensamientos?

Tampoco se verá afectado el hecho de que los datos fluyan entre servidores back-end a través de SSL también. Hay un par de beneficios.

  • Es posible que no desee que un empleado interno conecte un tcpdump en una máquina intermedia (a través de la cual fluye la información) y que detecte el tráfico. Con SSL, ella está fuera de suerte.
  • Qué sucede si desea mover la funcionalidad de una de sus máquinas backend fuera de su red (abarque la nube - amazon / rackspace). Adivina qué, no tendrás que hacer nada extra para asegurar la comunicación. Eso ya está cubierto. (Surgen nuevos problemas de MITM, pero esa es una historia diferente)
  • La defensa en profundidad predica tener múltiples capas de seguridad. Definitivamente preferiría la comunicación interna sobre SSL si es posible. Un estudio práctico establece que SSL / TLS ya no es computacionalmente caro . Por lo tanto, cargar el servidor ya no es una preocupación.
respondido por el CodeExpress 03.07.2012 - 00:26
fuente

Lea otras preguntas en las etiquetas