Creando mi propia CA para una intranet

Si su infraestructura es pequeña , es probable que muchos de los detalles de la ejecución de una CA (por ejemplo, CRL y similares) puedan ignorarse. En su lugar, todo lo que tiene que preocuparse es firmar certificados.

Hay una multitud de herramientas por ahí que administrarán este proceso por ti. Incluso escribí uno hace muchos años. Pero el que te recomiendo si quieres algo realmente simple es easy-rsa del proyecto OpenVPN. Es una envoltura muy delgada alrededor de la herramienta de línea de comandos OpenSSL. Si va a administrar MUCHOS certificados y tratar realmente con la revocación y esas cosas, querrá una utilidad mucho más compleja y completa. Ya hay más que suficientes sugerencias, por lo que me limitaré a seguir los conceptos básicos de lo que intentas lograr.

Pero aquí está el procedimiento básico. Lo explicaré con OpenSSL, pero cualquier sistema funcionará.

Comience por crear su CA "raíz": será un certificado autofirmado. Hay varias formas de hacerlo; este es uno. Haremos de nuestro certificado de 10 años con una clave de 2048 bits. Ajustar los números según corresponda. Usted mencionó que estaba preocupado por el algoritmo de hash, así que agregué -sha256 para asegurar que esté firmado con algo aceptable. Estoy cifrando la clave usando AES-256, pero eso es opcional. Se le pedirá que complete el nombre del certificado y tal; esos detalles no son particularmente importantes para una CA raíz.

# First create the key (use 4096-bits if that's what floats your boat)
openssl genrsa -aes256 -out root.key 2048

# Then use that key to generate a self-signed cert
openssl req -new -x509 -key root.key -out root.cer -days 3652 -sha256

Si cifraste la clave en el primer paso, deberás proporcionar la contraseña para usarla en el segundo. Verifique su certificado generado para asegurarse de que bajo "Restricciones básicas" vea "CA: VERDADERO". Esa es realmente la única parte importante de la que tienes que preocuparte:

openssl x509 -text < root.cer

Genial. Bien, ahora firmemos un certificado. Necesitaremos otra llave y esta vez una petición. Se le preguntará acerca de su nombre y dirección nuevamente. Los campos que complete y lo que suministre dependerán de usted y de su aplicación, pero el campo que más importa es el "Nombre común". Ahí es donde ingresa su nombre de host o nombre de inicio de sesión o lo que certifique este certificado.

# Create new key
openssl genrsa -aes256 -out client1.key 2048

# Use that key to generate a request
openssl req -new -key client1.key -out client1.req

# Sign that request to generate a new cert
openssl x509 -req -in client1.req -out client1.cer -CA root.cer -CAkey root.key  -sha256 -CAcreateserial

Tenga en cuenta que esto crea un archivo llamado root.srl para mantener nuestros números de serie en orden. La bandera -CAcreateserial le dice a openssl que cree este archivo, de modo que lo proporcione para la primera solicitud que firme y nunca más. Y una vez más, puedes ver dónde agregar el argumento -sha256 .

En mi opinión, este enfoque (hacer todo manualmente) no es la mejor idea. Si está ejecutando una operación de tamaño considerable, es probable que desee una herramienta que pueda realizar un seguimiento de todos sus certificados por usted.

En cambio, mi punto aquí fue mostrarle que la salida que desea (los certificados firmados de la forma que desea) no depende de las herramientas que usa, sino de las opciones que brinda a esas herramientas. La mayoría de las herramientas pueden generar una amplia variedad de configuraciones, tanto fuertes como débiles, y depende de usted proporcionar los números que considere apropiados. Los valores predeterminados obsoletos son par para el curso.

No hay manera de hacer esto simplemente. Hay algunas herramientas que pueden ayudarte a comenzar fácilmente.

me gusta:

• XCA
• EJBCA
• openssl

ninguno de ellos es un PKI completo aparte de posiblemente EJBCA pero eso no es trivial para la configuración.

• XCA es una pequeña herramienta de interfaz para obtener una interfaz gráfica para generar, firmar y revocar certificados.
• EJBCA o Enterprise Java Beans Certificate Authority es una aplicación web JBOSS / Jetty que puede hacer la infraestructura PKI completa para una empresa.
• openssl es la herramienta de línea de comandos básica. Puede hacer todos los bits fuera de línea de una CA pero ninguna de la verificación (fuera de la caja). usted puede crear sus propios verificadores de OCSP, pero usted mismo debe crear el código "en línea".

Si todo lo que buscas es la configuración correcta de openssl. XCA puede ayudarte a generarlos. (Tiene una función de exportación de configuración openssl

Si realmente desea ser un CA, preste atención a las implicaciones de seguridad de hacerlo.

1. La clave privada utilizada para generar la CA raíz de su intranet debería estar literalmente bloqueada en una caja fuerte. Y el acceso a dicha caja fuerte debe ser monitoreado físicamente.
2. El uso de una CA raíz autofirmada obliga a sus usuarios a no solo confiar en que está realizando la diligencia debida con la protección segura de las claves, sino también a insertar una lata inicialmente insegura en su cadena de certificados.
3. Esto también rompe la funcionalidad de grapado OSCP en lo que respecta a la verificación externa de la cadena de certificados, que es la razón por la cual los servicios de administración de identidad existen en primer lugar.

Unos cuantos argumentarían el razonamiento detrás de la administración de su propia CA, como; es para una intranet corporativa donde parte de nuestras compilaciones de escritorio incluyen la raíz ca o es para un pequeño número de usuarios.

Si bien no es necesariamente incorrecto hacerlo y puede ofrecer algunos beneficios, niega la cadena de verificación para la cual se creó la gestión de identidades basada en certificados.

Si decide implementar su propio ca raíz, asegúrese de seguir las mismas prácticas de seguridad que utiliza cualquier otro ca ca. Como empresa, lo último que desearía que pasara es que alguien comprometa la clave privada utilizada para su raíz ca y comience a firmar certificados para campañas de phishing contra sus clientes.

Hay un montón de guías de mejores prácticas disponibles para esto, el NIST (instituto nacional de estándares y tecnología) es un grupo colaborativo que brinda asistencia en varios estándares para temas de seguridad informática.

Lectura recomendada:
Auditoría (PDF)
Recuperación de desastres (PDF)
Sistemas de clave pública (PDF)
Sans institute sobre implementaciones de PKI más pequeñas

Ok, veo que actualizaste tu pregunta para ser más específico.

Dos documentos para configurar su archivo openssl.cnf para detalles de CA:

enlace

enlace

Me doy cuenta de que esta puede no ser la respuesta que desea, pero como el entorno y los requisitos de cada persona son diferentes, tendrá que definir un ámbito para su implementación de CA para una buena configuración de ejemplo.

Para obtener un buen historial, consulte mi presentación Cómo construir y operar su propio Centro de gestión de certificados de mediocridad . La esencia de la presentación es que lo más necesario no es una lista de los comandos que se ejecutan, sino más bien una comprensión profunda de los diversos controles que intervienen en la operación de una CA comercial, cómo interactúan entre sí, el impacto exacto de la eliminación cualquiera de ellos, el impacto acumulativo de eliminar varios de ellos y los controles de mitigación necesarios para compensar la seguridad reducida.

Esta es la razón por la cual no hay una "respuesta canónica sobre la configuración de una CA simple". Ya sea que vaya por la ruta ISO completa, comenzando con una parte de firma de clave, certificados de raíz duplicados con bala y con aireación, múltiples firmantes intermedios, servidores de revocación, etc., etc., o bien tiene que idear algún compromiso basado en el costo / beneficio único y Perfil de riesgo que la empresa está dispuesta a aceptar. Cualquier persona con suficiente habilidad y experiencia para hacer esa evaluación por definición no necesita la hoja de trucos. Pueden analizar la sintaxis de comando correcta en función de una comprensión profunda de la función de negocio que se realizará y las primitivas de seguridad utilizadas para implementar ese requisito.

En la presentación hay historias de compromisos reales de tiendas que tomaron este camino y se equivocaron terriblemente. En algunos casos, mi evaluación informó que no puedo hacer absolutamente nada con la seguridad de su middleware que pueda superar las debilidades inherentes de la CA interna. Cualquiera en los EE. UU. Debería darse cuenta de que probablemente compre servicios de al menos uno de los proveedores a los que se refiere la presentación. Estos son bancos, cooperativas de crédito, aseguradoras de salud, minoristas y más.

Dado que para que las recomendaciones sean "correctas" se requiere que el respondedor haga suposiciones importantes sobre sus perfiles de riesgo aceptables, y que usted haga suposiciones importantes sobre el grado en que sus ideas de riesgo y sus ideas están alineadas y sincronizadas, Muy propuesta es arriesgada en su cara. En la mayoría de los casos, la evaluación de la idoneidad de los tutoriales proporcionados tiene más que ver con la presentación que con el nivel efectivo de seguridad resultante del seguimiento de sus procedimientos. Si está bien organizado y claramente articulado, esto importa MUCHO más que si es efectivo. Escogemos la hoja de trucos canónica que nos parece mejor.

Por estas razones, no creo que un experto creíble proporcione "archivos openssl.cnf correctos y actualizados", sino que, en el mejor de los casos, podría proporcionar un proceso de evaluación para evaluar los requisitos y el riesgo aceptable de manera más completa. Dado que está apostando a la empresa por el resultado, ningún experto creíble lo haría fuera de la protección de un contrato. Cualquier recomendación que obtenga, casi por definición, debe ser de un en experto creíble. Buena suerte.

Siga estas instrucciones para configurar una CA basada en Windows . Dado que está emitiendo certificados de cliente, tenga en cuenta que los hashes SHA2 no son compatibles con XP.

La respuesta simple es:

1. instalar AD
2. Instale una CA empresarial en el controlador de dominio
3. Edite la plantilla de certificado para emitir certificados de usuario final (establezca el permiso para que los usuarios se inscriban automáticamente o visiten una página web)
4. Implementar la clave pública del certificado raíz en todos los servidores que validan usuarios
5. Si los usuarios están en AD, use GPO para habilitar la inscripción automática