Descripción general de la autoridad de certificación
Una instancia de autoridad de certificación (CA) es el componente básico de una instalación de PKI y, en una instancia, puede describirse como tal. Su función principal es gestionar la emisión y revocación de certificados, y en segundo lugar, validar, publicar y proporcionar flujos de trabajo para una gestión eficaz de los certificados. Si se reduce su tamaño, una CA podría consistir simplemente en un par de claves y un script, pero en EJBCA intentamos ofrecer mucho más que eso.
Esta descripción general de la autoridad de certificación cubre información conceptual sobre las CA.
Para obtener más información sobre cómo crear, editar y administrar CA, consulte Operaciones de autoridad de certificación .
Tipo de autoridad de certificación
La primera cuestión a considerar al crear una CA es el tipo. EJBCA actualmente admite dos tipos:
X509: el tipo de CA más común para correo electrónico seguro, inicio de sesión, autenticación web, VPN, etc., según se define en RFC 5280 .
CVC: CA que emite certificados CV, que son certificados especiales para pasaportes electrónicos de la UE y la CAE. Para más información sobre las CA CVC, consulte CA CVC .
Elementos de firma
Esta sección ofrece una descripción general de los elementos principales de la configuración de CA. Para obtener una referencia completa de todos los valores de configuración, consulte Campos de CA.
Token criptográfico
La base de una CA siempre se centrará en uno o más pares de claves. Desde la perspectiva de una CA, estas se almacenan en un token criptográfico y deben firmarse para su uso. Para obtener información sobre los tipos de tokens criptográficos disponibles y dónde se almacenan las claves privadas, consulte la sección "Resumen de tokens criptográficos" .
Históricamente, los tokens criptográficos en el contexto de CA se han denominado tokens CA. Si bien este término es puramente histórico, aún puede mencionarse en documentación y archivos de configuración antiguos. Ambos términos pueden considerarse equivalentes.
Pares de claves
Una CA está definida para usar varios pares de claves asignados a un propósito. En el siguiente ejemplo, la asignación de propósito se ve a la izquierda, mientras que el alias del par de claves está a la derecha. Tenga en cuenta que el mismo alias puede usarse para varias asignaciones.
defaultKey : la clave a utilizar si no se selecciona ninguna clave específica.
certSignKey : La clave que se utilizará para la emisión del certificado. Debe cumplir con el algoritmo de firma seleccionado (véase más abajo).
crlSignKey : La clave para firmar CRL. Aunque teóricamente podría ser independiente de certSignKey según las RFC, el soporte del cliente es poco frecuente y certSignKey siempre se usará.
keyEncryptKey : clave a utilizar para la recuperación de claves (si está habilitada) y descifra claves en custodia.
hardTokenEncrypt : funcionalidad obsoleta, no utilizar.
testKey : Clave utilizada por la comprobación de estado para verificar que el token criptográfico sea utilizable. Generalmente, es una clave corta para comprobaciones de conexión rápidas.
Para el cifrado, solo se admiten las suites RSA y ECCDH (cofactor de curva elíptica Diffie Hellman). En el caso de ECCDH, solo se pueden usar cifrados con un cofactor de 1, lo que limita las opciones de curva a las siguientes: P-224, P-256, P384, P-521, K-233, K-283, K-409, K-571, B-233, B-283, B-409 y B-571. Consulte el borrador de internet del NIST sobre los valores JSON de las capacidades de los componentes ECC CDH .
Por razones arquitectónicas, cuando se utiliza el archivo de claves, el cifrado de la clave de entidad final debe coincidir con el de las claves de firma y cifrado; en otras palabras, solo las claves de entidad final EC pueden ser archivadas por una CA EC (aunque pueden tener curvas diferentes), y solo las claves de entidad final RSA pueden ser archivadas por una CA RSA.
Algoritmo de firma
El algoritmo de firma que se utilizará para emitir certificados, firmar CRL, etc. La elección del algoritmo debe corresponder a los tipos de pares de claves disponibles en el token criptográfico. Por lo tanto, SHA256WithRSA solo puede utilizarse junto con claves RSA.
Certificado CA
Las claves asociadas a una CA no sirven de nada a menos que estén firmadas, y el resultado de esta firma es el Certificado de CA. El certificado puede ser autofirmado ( CA raíz ), firmado por otra CA local (lo que lo convierte en una CA secundaria o CA intermedia ) o firmado externamente (requiere la generación y firma de una CSR antes de que la CA pueda activarse). La elección de un perfil de certificado para la CA no afectará a los certificados emitidos por esta, sino a los certificados para ella.
Aprobaciones y flujos de trabajo
Para obtener más información sobre aprobaciones y flujos de trabajo, consulte Descripción general de aprobaciones .
Algunas operaciones de CA pueden configurarse para requerir aprobaciones adicionales, permitir que administradores de nivel inferior soliciten la realización de ciertas operaciones y que varias personas autoricen una acción. Se pueden configurar las siguientes acciones para su aprobación:
Agregar y editar entidades finales
Realizar operaciones de recuperación de claves
Revocación de certificados
Activación de los servicios de CA
Las aprobaciones se configuran mediante perfiles de aprobación , que actúan como plantillas de flujo de trabajo de aprobación general.
Editores
Para obtener más información sobre los editores existentes y cómo configurarlos, consulte Descripción general de editores .
Firmar y almacenar certificados a menudo no es suficiente; también es necesario publicarlos en varias ubicaciones.
Operaciones editoriales comunes
Los editores pueden ser de diversas formas y tamaños, pero las aplicaciones comunes para los editores son:
Publicación de certificados y CRL de la CA a una VA.
Publicar certificados en una estructura LDAP.
Publicar certificados en un
Varios editores personalizados.
Cola de publicación
Las autoridades de certificación pueden configurarse para publicación directa (instantánea, lo que puede provocar el fallo de la emisión completa del certificado si falla a su vez) o publicación en cola, asincrónica pero mucho más robusta. La publicación en cola se selecciona marcando a un publicador para que la use y configurando un Service Worker para procesarla.
Validadores
Para obtener más información sobre los validadores, qué hacen y cómo ampliarlos, consulte Descripción general de validadores .
Un requisito común entre las Autoridades de Certificación es la capacidad de validar los certificados o su contenido antes, durante o después del proceso de firma, así como antes de su almacenamiento y publicación. Por ello, EJBCA proporciona la construcción Validator, donde los validadores pueden instanciarse y configurarse basándose en plantillas, y configurarse para tener diversos efectos en el proceso de emisión, desde una simple advertencia hasta el rechazo directo del certificado emitido. Ejemplos de operaciones de validación:
Verificar que el tamaño y la seguridad de las claves públicas enviadas se ajusten a las restricciones predefinidas.
Verificación de las claves públicas enviadas contra una lista de bloqueo conocida de claves débiles.
Realizar comprobaciones en línea, como la autorización de la autoridad certificadora.
Los validadores se pueden crear y editar en la interfaz de usuario de CA y son elegidos por cada CA para su uso.
Ciclo de vida de CA
Cada CA en EJBCA tiene un estado:
Sin inicializar : Estado de una CA sin par de claves. Las CA importadas con Statedump o Configdump se inician en este estado. Una vez generado el par de claves para la CA, el estado cambia a Esperando respuesta del certificado .
Esperando respuesta de certificado : Estado de una CA sin cadena de certificados. Es posible generar una CSR y enviarla a otra CA para su firma. Una vez asociada una cadena de certificados a la CA, el estado cambia a Activo .
Activo : Estado de una CA con un par de claves y una cadena de certificados. Una CA activa puede firmar certificados y, si es necesario, desconectarse o revocarse.
Desconectado : Estado de una CA con un par de claves y una cadena de certificados, que se ha desactivado temporalmente (por ejemplo, para evitar accesos no autorizados ). Puede volver a estar en línea si es necesario.
Revocado : El estado terminal de una CA que se ha revocado manualmente. Una vez revocada, no es posible realizar ninguna operación con ella (por ejemplo, firmar certificados o renovarlos).
Caducado : Estado de una CA cuyo certificado ha caducado. Este estado lo establece automáticamente EJBCA. Una vez caducado, se puede reactivar renovándolo.
CA externa : el estado de una CA con una cadena de certificados pero sin un par de claves asociado a ella.
El siguiente diagrama de flujo describe el ciclo de vida de una CA en función de estos estados:
Renovación
Todos los certificados deben caducar en una fecha razonable, al menos para garantizar la implementación universal de algoritmos de seguridad corregidos y actualizados. EJBCA ofrece soporte completo para la renovación e implementación de certificados de las autoridades de certificación, incluyendo el uso de certificados de renovación. Para obtener más información sobre el proceso de renovación, consulte Administración de CA.
Temas de descripción general de la autoridad de certificación