9 votos

La distribución de los Certificados SSL para Todos los Navegadores en un Entorno de Active Directory

He generado un único certificado SSL auto-firmado (que expira en 5000 años). El propósito del cert es simplemente cifrar el tráfico https de confianza deno' aplicación que se accede por una variedad de navegadores web en varios sitios de la intranet corporativa.

En un comentario de mi anterior pregunta, alguien me aconsejó que es posible distribuir mi auto-firmado pública de la clave SSL para todos los equipos dentro de un entorno de Active Directory mediante la Directiva de Grupo en el controlador de dominio.

Mi objetivo, es evitar que los usuarios de tener que aceptar de forma manual, esta auto-firmar el certificado.

Esta aplicación de seguridad no es la prioridad. La prioridad es la aceptación automática del certificado auto-firmado. Así que incluso si un nuevo usuario está usando Chrome o Firefox para acceder a esta aplicación por primera vez, no tiene que aceptar manualmente el certificado para ver una página dentro de la Aplicación.

Si usted se está preguntando por qué no sólo estoy usando http (en lugar de https), es sólo porque no son características de los estándares de la web que no están disponibles a menos que su protocolo https. La API de Notificación es un ejemplo.

¿Existe un tutorial completo para mi caso de uso?

I haga clic aquí: enter image description here

Lo que me trajo a el editor de directivas de Grupo, y de hecho he logrado importar mi auto-clave pública firmada aquí: enter image description here

Sin embargo, esto no tuvo ningún efecto. Por ejemplo, me he registrado en un par de estación de trabajo en la LAN, y de tanto en Firefox y Chrome que se solicita manualmente permitir el certificado.

Donde puedo encontrar instrucciones precisas para mi exacto de casos de uso y los objetivos. ¿Cómo puedo hacer esto de una manera que tanto Chrome y Firefox se auto-recibir la pre-autorización del certificado de que estoy tratando de distribuir?

Esto es algo que debo cumplir para varias instalaciones en varios sitios de la intranet de la empresa. En cada ubicación de instalación, necesito de active directory para distribuir este cert, por lo que todos los navegadores en cada estación de trabajo lo va a aceptar.

12voto

Esa Jokinen Puntos 1735

Escribir un tutorial completo sobre este podría no ser adecuado para un P/Un sitio, pero he aquí algunos consejos. También, esto es desde la perspectiva de la gestión de la instalación para un único cliente dentro de su propia intranet. Por ejemplo, SaaS instalaciones es mejor para el uso global de los nombres de dominio & PKI.

Como proveedor de software, usted NO DEBE:

  • implementar propia PKI y empuje a través de sus clientes, ya que permite la emisión de certificados para arbitrario hosnames, dándole un modo de Dios en toda su infraestructura.
  • el uso de la misma certificados autofirmados para varios clientes con codificada claves privadas, ya que fácilmente puede ser extraído y utilizado en contra de otros clientes.
  • combinar estos errores, como sería dar a cada cliente un modo de Dios sobre todos los demás clientes.

Crea tu propia PKI en lugar de confiar en los certificados individuales

Esto se debe principalmente a una consideración de seguridad, pero también es más fácil de mantener, como usted menciona tener varias instalaciones en varios sitios de la intranet.

  • Desde la perspectiva de la seguridad, no quieren que cada aplicación sea capaz de firmar los certificados arbitrarias de nombres de host. Por lo tanto, el individuo se auto-firmado los certificados no deben todos ser entidades de certificación de confianza.

  • Desde el mantenimiento de la perspectiva, usted no desea actualizar sus políticas y esperar a que se propaguen cada vez que usted necesita para añadir una nueva aplicación web.

  • Aunque preferible, a veces no es posible (o quería) para obtener los certificados de ca externas. Los sitios de intranet no puede tener en el mundo válidos los nombres de dominio, haciendo imposible la verificación de dominio, o su conectividad a Internet es restringido, lo que hace más difícil mantener el certificado de renovaciones.

En este caso, la alternativa recomendada es crear un certificado de autoridad para el cliente (no presione a su PKI para varios clientes como un proveedor de software) y firmar todos los certificados con ella. De esta manera usted sólo necesita agregar un certificado único para el certificado de confianza a las autoridades el uso de GP, y cada solicitud de certificado firmado con va a ser de confianza.

Si usted sólo necesita un pequeño certificado de la autoridad para que este solo propósito, usted puede ir con OpenSSL:

  1. Generar la clave de la root (rootCA.key) y el certificado root (rootCA.crt).

    openssl genrsa -aes256 -out rootCA.key 4096
    openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 7300 -out rootCA.crt
    

    Guardar la clave de la caja fuerte, recommendably sin conexión, y distribuir el certificado de uso de Directiva de Grupo.

  2. Crear un certificado para el inicio de la aplicación con una clave y una solicitud de firma de certificado (.csr).

    openssl genrsa -out app.example.com.key 2048
    
    openssl req -new -sha256 \
        -key app.example.com.key \
        -subj "/C=US/ST=CA/O=My Application/CN=app.example.com" \
        -out app.example.com.csr
    
  3. Crear una solicitud de certificado firmado con la entidad emisora de certificados:

    openssl x509 -req -in app.example.com.csr \
        -CA rootCA.crt -CAkey rootCA.key -CAcreateserial \
        -days 730 -sha256 \
        -out app.example.com.crt
    
  4. El uso de la app.example.com.key y app.example.com.crt en su aplicación.

Para más pesado soluciones hay de Active Directory Certificate Services (AD CS), pero que realmente necesita un poco de planificación, y su conjunto de habilidades podría no ser adecuada para que, aún.

El uso de un GPO en lugar de modificar la Directiva de Dominio Predeterminada

Como una nota del lado, yo no modificar la Directiva de Dominio Predeterminada para esto, pero crear un nuevo Objeto de Directiva de Grupo (GPO) en su lugar. Esto hace mucho más fácil limitar el alcance de los cambios, por ejemplo, haciendo posible aplicar a un grupo de equipos de prueba, en primer lugar. También hace que sea más fácil para revertir los cambios, si algo va mal.


Firefox tiene el propio cert tienda posibles para el uso de certificados de Windows

Mozilla's Certificado de CA Programa regula la inclusión de la root certificados en Servicios de Seguridad de Red (NSS), un conjunto de código abierto las bibliotecas diseñado para el apoyo de la multiplataforma de desarrollo de de seguridad habilitado para aplicaciones de cliente y servidor. La NSS de la root almacén de certificados se utiliza en los productos de Mozilla como Firefox navegador, y también es utilizado por otras compañías en una variedad de productos.

Esto significa que los certificados añadido a almacén de certificados de Windows no se aplica a Firefox, por defecto. Para facilitar el mantenimiento podría ser una buena idea para hacer que Firefox use el certificado authories instalado en Windows. El uso de un certificado propio de la tienda es una buena idea para la protección de la privacidad de las personas que usan Firefox, pero no es adecuado para entornos Windows AD. Afortunadamente, hay una manera de desactivarlo.

Suponiendo que el directorio de instalación de Firefox es C:\Program Files\Mozilla Firefox\, deberá agregar dos ANSI codifica los archivos de configuración:

  1. C:\Program Files\Mozilla Firefox\defaults\pref\local-settings.js tener

    pref("general.config.obscure_value", 0); 
    pref("general.config.filename", "ownsettings.cfg");
    

    Esto se refiere simplemente al siguiente archivo, teniendo los parámetros de configuración reales.

  2. C:\Program Files\Mozilla Firefox\ownsettings.cfg tener

    //
    lockPref("security.enterprise_roots.enabled", true);
    

    Es importante que los valores reales se inicia a partir de la segunda línea después de la //!

Estos archivos pueden ser distribuidos en el mismo GPO mediante:

Computer Configuration \ Preferences \ Windows Settings \ Files

enter image description here

9voto

marcelm Puntos 431

No introducir ca root en otras organizaciones

El uso de los certificados auto-firmados y distribución de los mismos a través de Active Directory es posible, pero bastante implicados. Esa Jokinen entra en más detalle en su respuesta.

Más importantes son las implicaciones de seguridad; certificados root son como una llave maestra, todos los certificados firmados por un certificado root en el año será de confianza por parte de todos los equipos de la empresa. Si el control de una root cert en una aplicación, entonces usted no puede crear un certificado para yourapp.intranet que va a ser de confianza, puede hacer que para cualquier dominio. También para bigbank.como para google.com.

Básicamente, conseguir a alguien para instalar el certificado root pone en una posición para atacar a todos sus conexiones HTTPS. Esto significa que usted necesita tener los procedimientos adecuados para tratar con esas claves, para ocuparse de la revocación, y para hacer frente a las violaciones de seguridad. También significa que las empresas necesitan para poner un montón de confianza en ti. Y no creo que se debe, lo siento.

Honestamente, si un proveedor se trató de introducir su propia entidad emisora root en mi organización, sin un profundo conocimiento de las preocupaciones de los involucrados y tener planes para todo, me gustaría veto ellos. Yo probablemente incluso veto con esos planes.

Dependiendo de la organización, tal vez ellos ya tienen su propia CA interna; en ese caso, usted puede solicitar un certificado de ellas; este absuelve de la mayoría de estos problemas, ya que la administración de CA es su responsabilidad, no la tuya. También se le dará sólo los certificados sólo para su aplicación.

¿Hay alguna alternativa?

Considerar este enfoque alternativo; Obtener un buen nombre de dominio para su aplicación, y obtener un certificado SSL regular de cualquier CA. Si el costo es un problema, hay varios partidos de la oferta de los certificados de forma gratuita. Me gusta Vamos a Cifrar.

Para el nombre de dominio, las opciones más obvias son company.yourapp.com y yourapp.company.com. La primera es más fácil de manejar, ya que obtener el nombre de host y el certificado son estandarizados en todas las implementaciones. Esto último se requiere de usted para tratar con el cliente, pero ofrece una mejor integración de los mismos.

Por cierto, ninguna de estas opciones requiere que su aplicación sea de acceso público (a pesar de que es sin duda, una opción). El dominio simplemente podría apuntar a una dirección IP interna a la empresa, donde se implementa la aplicación; Que había necesidad de usar el correo electrónico de verificación o de comprobación de DNS para obtener los certificados.

Otra opción es la de split DNS; el dominio apunta a un servidor bajo su control, que alberga la CA necesarios de verificación de cosas así que usted puede obtener los certificados. En la empresa en donde se implemente, sus DNS interno de los puntos de su dominio de su servidor de aplicaciones.

Respondiendo a algunos comentarios

En mi opinión, la seguridad de los fanáticos de golpe este tema fuera de proporción. Tratar cada situación como la banca en línea, cuando a veces todo lo que un desarrollador quiere es que la transferencia de datos cifrados.

Lo que quieres no existen. Puede configurar sólo "cifrado", pero cuando el intercambio de claves de cifrado, un atacante puede simplemente interceptar esas claves, y el sustituto de su propia, lo que les permite leer todos los de su tráfico cifrado. Certificados de asegurarse de que el navegador es en realidad el intercambio de claves con la intención de servidor, en lugar de con un atacante. Esta parte es necesaria para la seguridad de la encriptación.

Al final, la verificación de la identidad es parte integral de la obtención de la cifra de comunicación; no es opcional.

La verdad es que un certificado auto-firmado puede proporcionar el mismo nivel de cifrado (durante la transferencia de datos) como el usado por el Banco de América.

Sólo si usted puede manejar para distribuir correctamente los certificados. Eso es fácil si sólo se trata de un equipo local que necesita el certificado, pero a escalas muy mal, y se hace muy difícil hacer lo correcto para un número arbitrario de los equipos.

Por eso recurrimos a las Autoridades de certificación, que proporcionan una manera de distribuir los certificados en una solución escalable y razonablemente segura.

Apps sirve de direcciones IP privadas no tienen que jugar con las mismas reglas que los bancos internacionales, en mi opinión.

La cosa es que, las computadoras no tienen sentido común. Ellos no entienden que la seguridad es necesaria para que la visita a un sitio web del banco, pero ehhh seguridad está bien para visitar a su aplicación. Ellos no pueden entender eso. Y que no intente. Lo que si se inicia la aplicación de tratar con los registros médicos? De repente el "sentido común" de la aceptación de la ehhh seguridad para su aplicación es inaceptable. El equipo no puede conocer esa distinción.

Si los equipos tienen que aceptar descuidado la seguridad en su sitio, ellos tienen que aceptar que para otros sitios. Y por suerte hemos llegado al punto en que es inaceptable. Acepta, y el orgullo de dar a su aplicación de la misma codificación que utilizan los bancos!

Se pone una terrible carga innecesaria para el desarrollador

No.

Sí, la protección de un sitio web con HTTPS pone una carga sobre el desarrollador, así es la vida. Llamando a cualquiera de los terribles o innecesarios sopla las cosas fuera de proporción.

Honestamente, simplemente colocamos algunos Vamos a Cifrar los certificados en sus sitios. Se pone usted la seguridad que deseas (más un poco extra), y es la manera menos esfuerzo que quejarse de todo esto. Es también menos esfuerzo y más seguro que intentar ser un CA para sus clientes.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: