Creando una Autoridad de Certificación
Cuando cree sus certificados de Autoridad de Certificación obtendrá ca.crt y ca.key archivos . El archivo .crt es la clave pública autofirmada y el archivo .key es el archivo de clave privada. No es tan simple como esto. Ambos archivos están codificados en base64, y los datos debajo están DER codificado . Como es probable que esté generando X.509 .
Realmente, todo lo que necesita comprender es que tiene un certificado autofirmado cuya porción pública está almacenada en ca.crt y la porción privada está almacenada en ca.key . Recuerde que debe mantener ca.key secret Todos los grandes números primos, las operaciones de GCD y todo lo que no está a cargo de lo que esté usando para generar el certificado.
El dh2048.pem no es una clave, son los parámetros Diffie Hellman para el servidor. Estos no tienen nada que ver con sus claves RSA, y solo se usan para cuando se usa Diffie Hellman para conectarse a su servidor en lugar de RSA. La diferencia entre los dos se puede encontrar en la sección Intercambio de claves de ¿Cómo funciona SSL / TLS? Esto no debería tener nada que ver con PKI.
El crl.pem se genera para ser su Lista de revocación de certificados. Cualquier certificado que revoque que haya sido firmado con su CA se agregará a este archivo. En su configuración de OpenSSL (supongo que está configurando OpenSSL, pero la idea se aplica a cualquier configuración) se señalará este archivo CRL. De esa manera sabrá dónde verificar los certificados revocados.
Firma de certificados
Ahora que tiene una Autoridad de certificación, puede comenzar a firmar certificados de usuarios para su sistema. Los usuarios hacen esto generando sus propias claves RSA client.crt y client.key . Estas claves deben generarse cada vez que se introduce un nuevo usuario en el sistema. Nuevamente, .crt es la parte pública de la clave y .key es la parte privada. El nuevo usuario debe mantener en secreto client.key .
Para firmar el certificado de un nuevo usuario, se realiza una solicitud de firma de certificado (CSR). Hay un comando en OpenSSL para hacer esto. La solicitud contiene la clave pública del usuario que se agregará y otra información pública que necesita la solicitud. El certificado del cliente se agregará a las listas autorizadas apropiadas en el servidor y se producirá un nuevo certificado firmado. Esto es lo que el usuario tendrá que importar a su navegador para visitar las páginas habilitadas para PKI.
Hay un gran tutorial sobre Infraestructura de clave pública en el sitio de OpenSSL para futuras referencias.
Esperemos que esto aclare algunas cosas. Cada variable que ha mencionado en el algoritmo RSA se genera cuando crea un certificado. Los certificados públicos no los contienen todos, pero las partes privadas generalmente los contienen. Para propósitos de implementación no tendrá que preocuparse por ellos. Solo recuerda que hay un par de claves públicas y privadas.
Para responder a tu 1 st Editar
El intercambio de CSR y el certificado resultante generalmente se realiza utilizando algún tipo de copia segura (scp). El servidor y el cliente deben estar en comunicación entre sí. La afirmación de que "el cliente y el servidor se autentican entre sí" no es realmente correcta. El cliente desea ser parte de la infraestructura, por lo que debe demostrar su identidad al servidor de firmas. Como Autoridad de certificación, es su responsabilidad verificar la identidad del cliente antes de procesar la CSR. El propio CSR debe tener toda la información necesaria para verificar la identidad del cliente que se agregará.
Para responder a su 2 nd Editar
RSA es solo el algoritmo de clave pública utilizado para la generación, el cifrado / descifrado de claves y la firma. La infraestructura de clave pública es una colección de estándares y servicios necesarios para implementar una infraestructura segura. Un servicio de sincronización confiable es probablemente uno de los muchos requisitos. Al igual que una Autoridad de Certificación es un requisito.