Uso de EJBCA como sistema de gestión de certificados (CMS)
A continuación se incluye información sobre el uso de EJBCA como un sistema de gestión de certificados (CMS), también conocido como gestión del ciclo de vida de los certificados (CLM), y se ofrece una breve descripción general del concepto de CMS/CLM, seguida de un esquema de las áreas de funcionalidad de EJBCA y productos CMS/CLM de terceros.
Descripción general de CMS
El significado del concepto CMS (o CLM) ha cambiado a lo largo de los años, creando la necesidad de describirlo con más detalle, ya que puede significar cosas diferentes para diferentes personas.
Originalmente, CMS era sinónimo de Sistema de Emisión y Gestión de Certificados (CMS), que es la tecnología de CA para una Autoridad de Certificación (CA). Esto es lo que EJBCA significa. A medida que la necesidad aumentó con el paso de los años, se han consolidado más funciones en el término CMS.
Según Gartner un CMS es:
"El software del sistema de gestión de certificados se utiliza para descubrir, identificar, rastrear,
Notificar y, en última instancia, renovar y auditar automáticamente la instalación de X.509
certificados.”(Gartner, 2016)
Actualmente están disponibles las siguientes áreas funcionales principales:
Conocimiento de qué entidades necesitan tener un certificado y por qué.
Control de costes de obtención de certificados.
Descripción general de los certificados activos/utilizados por las entidades finales.
Garantía de que las entidades finales utilicen únicamente los certificados previstos, es decir, que no tengan otros certificados válidos
Aprovisionamiento de certificados
Aprovisionamiento y activación de certificados en entidades finales.
Renovación de certificados de entidades finales.
Una forma eficiente para que las partes confiantes validen los certificados.
Descubrimiento de certificados
No tener una comprensión clara de dónde y cómo se utilizan los certificados puede causar problemas como interrupciones del servicio, violaciones de seguridad, costos no controlados e incumplimiento.
Además, muchos casos de uso de CMS implican la ejecución de la funcionalidad anterior con varias CA separadas lógica y físicamente. Por ejemplo, varias CA públicas para emitir certificados de servidor web de confianza pública y varias CA internas instaladas con productos de diferentes proveedores.
La gestión de certificados puede realizarse mediante EJBCA o mediante un CMS de terceros que se integre con EJBCA. EJBCA admite las cuatro primeras funciones descritas anteriormente. La diferencia entre usar EJBCA y un CMS de terceros radica en que EJBCA gestiona los certificados emitidos y gestionados dentro de la instancia de EJBCA, por lo que cada instancia de EJBCA constituye su propio sistema de gestión de certificados. Un CMS de terceros se utiliza normalmente para gestionar varias PKI lógica y físicamente separadas; por ejemplo, certificados emitidos por una (o más) instancias internas de EJBCA, así como certificados emitidos por una (o varias) PKI externas, como las CA de confianza pública.
Las siguientes secciones cubren las áreas de funcionalidad de EJBCA CMS y luego la sección Integración de productos CMS describe los productos CMS de terceros.
Funcionalidad del CMS EJBCA
Las siguientes secciones describen la funcionalidad de CMS ofrecida dentro de una instancia EJBCA:
Propiedad del certificado
Con EJBCA, controla las entidades a las que se les emiten certificados. La configuración flexible de perfiles de certificado, autorización y protocolos le permite controlar estrictamente lo que debe controlarse y automatizar lo que debe automatizarse.
La configuración de diferentes tipos de certificados para distintos tipos y grupos de entidades finales se controla mediante Autoridades de certificación , Operaciones de perfil de entidad final y Perfiles de certificado .
El control de acceso basado en roles se utiliza para controlar en detalle quién o qué tiene acceso para administrar los distintos tipos de certificados y grupos de entidades finales.
Las aprobaciones se pueden utilizar opcionalmente para aplicar controles a varias personas antes de emitir un certificado.
Las notificaciones por correo electrónico se pueden utilizar para notificar a los titulares de certificados y a los administradores sobre el estado del flujo de trabajo de emisión, revocación y aprobación .
Los siguientes ejemplos ofrecen una descripción general de un pequeño subconjunto de opciones para controlar la emisión de certificados.
Gestionar manualmente las solicitudes de certificados que requieren aprobación.
Gestión manual de solicitudes de certificado
Aprobar manualmente solicitudes de certificados en un flujo de trabajo de aprobación.
Aprobación manual de solicitudes de certificado
Descarga inmediata del certificado solicitado.
Informes de certificados
Tras la emisión de certificados, también es necesario investigar, entre otras cosas, qué certificados se han emitido y cuándo caducan. EJBCA ofrece funciones de búsqueda y notificación para obtener información sobre el uso de los certificados.
Tenga en cuenta que las siguientes capturas de pantalla solo brindan una descripción general de un pequeño subconjunto de opciones para buscar e informar.
La RA de EJBCA proporciona amplias capacidades de búsqueda para buscar certificados y entidades finales, entre otras cosas para ver:
¿Qué certificados se emiten para una entidad final específica (por ejemplo, un dispositivo, un usuario o un servidor)?
¿Qué certificados se han emitido con un nombre específico, número de serie, nombre de host, etc.?
¿Qué entidades finales únicas se han registrado con un nombre específico, número de serie, nombre de host, etc.?
Qué certificados están a punto de expirar dentro de un intervalo de tiempo específico.
También puede configurar un Servicio para informar, por correo electrónico, un período de tiempo definido antes de que los certificados expiren.
La centralización de las funciones de generación de informes se puede realizar mediante la integración con una herramienta de análisis de registros. Para más información, consulte Integración de EJBCA con Graylog .
Aprovisionamiento de certificados
El aprovisionamiento de certificados es el proceso de registrar un dispositivo, generar claves, generar una solicitud de certificado, emitirlo y, finalmente, instalarlo en el dispositivo. La forma de hacerlo depende en gran medida del caso de uso y puede variar desde procesos manuales que requieren mucho tiempo hasta procesos altamente automatizados en la industria, el IoT o la nube. El aprovisionamiento suele referirse más al proceso del dispositivo que al de la CA. Naturalmente, la forma de hacerlo del lado del cliente varía considerablemente. En general, las opciones son:
Funciones integradas del dispositivo, por ejemplo, en su firewall, enrutador, etc.
SDK del lado del cliente cuando desarrolla su propio software en el dispositivo.
Herramientas de cliente instaladas en el dispositivo.
Agentes de administración de certificados instalados en el dispositivo.
Durante el proceso de aprovisionamiento, el dispositivo utiliza un protocolo para comunicarse con la CA o RA y solicitar certificados. EJBCA ofrece amplia compatibilidad con los siguientes protocolos comunes:
Los protocolos disponibles se configuran en la configuración del sistema EJBCA.
Dependiendo del cliente, se utilizan diferentes protocolos, y muchos dispositivos tienen compatibilidad integrada con uno de ellos. ACME es un nuevo protocolo que se utiliza para automatizar la emisión y renovación de certificados de servidor. Existen diversas herramientas de cliente disponibles para instalar en servidores y dispositivos para gestionar el aprovisionamiento. En cuanto a los SDK, también existen diversas opciones, por ejemplo:
La API de Java de BouncyCastle funciona en todos los dispositivos Java (incluido Android) y admite varios de los protocolos anteriores.
y muchos más
El SDK que más apoyamos es BouncyCastle, que también es el SDK que utiliza EJBCA.
A continuación se muestra un ejemplo del protocolo basado en REST de ACME.
Los agentes de administración de certificados generalmente son parte de un producto CMS y se utilizan en combinación con él, consulte a continuación.
Validación de certificados
La validación de certificados se puede dividir en dos partes: verificar la cadena de certificados y comprobar si un certificado está revocado o no.
La validación de revocación es compatible con EJBCA a través de los medios más comunes para validar si un certificado está revocado o no:
Al verificar si un certificado está revocado, los clientes validan contra el servicio OCSP en línea (consulta por certificado) o descargan la CRL (lista de todos los certificados revocados) para determinar el estado de revocación de un certificado.
La capacidad de validar la cadena de certificados depende de que el cliente disponga de la cadena completa para verificarla. En algunos protocolos, como TLS, la cadena de certificados se transfiere normalmente durante el protocolo de enlace, pero en algunos casos, el cliente puede necesitar obtener los certificados de la CA del servidor.
En EJBCA, los servicios de validación se integran en la Autoridad de Validación (VA), una oferta única que incluye el servicio OCSP y la descarga de CRL, así como la descarga de certificados de CA. La VA de EJBCA contiene la información que necesita una parte confiada para verificar y validar certificados (siempre que haya establecido confianza en la CA raíz).
En muchos casos, el soporte del cliente para la validación de certificados está integrado en los clientes y está presente en los SDK comunes como Bouncy Castle, OpenSSL y otros.
Descubrimiento de certificados
En organizaciones grandes, es muy difícil realizar un seguimiento y controlar el uso de certificados. La caducidad de certificados puede provocar interrupciones en servicios empresariales importantes cuando una unidad de negocio específica no los ha gestionado correctamente. Las herramientas de descubrimiento de certificados ayudan a identificar y localizar certificados y ofrecen funciones de generación de informes. El descubrimiento se realiza normalmente mediante el análisis de redes, sistemas y aplicaciones, y el registro de los certificados encontrados. Esto permite encontrar fácilmente certificados públicos , como los de servidor. En muchos casos, los certificados de cliente no son accesibles mediante el análisis de red y deben detectarse mediante el análisis de aplicaciones y registros, por ejemplo, Active Directory.
EJBCA no ofrece la función de escaneo para detectar certificados no administrados por la propia instancia. EJBCA tiene control total y conocimiento sobre todos los certificados emitidos por ella misma cuando se utiliza como CA.
Integración de productos CMS/CLM
Existen múltiples productos CMS de terceros disponibles para detectar y controlar certificados emitidos por diversas CA. Los productos de este sector ofrecen diferentes funcionalidades: algunos se centran exclusivamente en el descubrimiento y otros en la gestión completa del ciclo de vida, con compatibilidad para la integración con otros sistemas de TI, como balanceadores de carga, sistemas EMM y MdM, dispositivos IoT, etc.
Factor clave
La plataforma de automatización y gestión del ciclo de vida de los certificados de Keyfactor le permite administrar el ciclo de vida de las claves y los certificados digitales en toda su empresa.
KeyFactor se integra de forma nativa con EJBCA mediante la API REST. Para más información, consulte el comunicado de prensa de PrimeKey: Keyfactor y PrimeKey se asocian para habilitar una PKI altamente escalable para implementaciones empresariales y de IoT modernas .
Vista de aplicación X
La plataforma AppViewX es una aplicación modular que permite la automatización y orquestación de la infraestructura de red mediante un flujo de trabajo visual, intuitivo y contextual. Es de bucle cerrado y consciente del estado, capaz de verificar el cumplimiento de la intención y proporcionar información práctica y soluciones automatizadas.
AppViewX se integra de forma nativa con EJBCA mediante la API REST. Para más información, consulte el comunicado de prensa de PrimeKey: AppViewX y la solución de gestión de certificados integrada con EJBCA de PrimeKey .
Compañía 3Key
3Key Company desarrolla y mantiene varios complementos para EJBCA Enterprise. El complemento 3Key DMR ofrece funciones adicionales de panel de control, monitorización e informes para EJBCA, lo que ayuda a las organizaciones a sacar el máximo provecho de su PKI de vanguardia.
Para obtener más información, consulte el complemento 3Key Dashboarding, Monitoring and Reporting y el complemento 3Key RA Profiles o el comunicado de prensa de PrimeKey PrimeKey y 3Key Company anuncian una nueva asociación para ofrecer soluciones de PKI y firma para proteger los activos digitales críticos para el negocio .
Digitalberry
El software BerryCert de Digitalberry automatiza la gestión del ciclo de vida de los certificados digitales. BerryCert detecta y gestiona automáticamente la renovación de certificados antes de su fecha de vencimiento.
BerryCert se integra de forma nativa con EJBCA mediante la API de WS. Para más información, consulte la documentación de Digitalberry sobre la integración de PrimeKey EJBCA.
Lémur
Lemur es un proyecto CLM de código abierto desarrollado originalmente por Netflix. Lemur gestiona la creación de certificados TLS. Si bien no puede emitir certificados por sí mismo, Lemur actúa como intermediario entre las CA y los entornos, proporcionando un portal central para que los desarrolladores emitan certificados TLS con valores predeterminados adecuados.
PrimeKey ha desarrollado un complemento Lemur EJBCA que permite la integración nativa entre Lemur y EJBCA, lo que permite a Lemur utilizar EJBCA como PKI de backend sin problemas.
Venafi
La plataforma Venafi es una plataforma de gestión de ciclo de vida completo que descubre, administra y automatiza el uso de certificados en grandes organizaciones.
Controlador de integración EJBCA
La plataforma Venafi se integra de forma nativa con EJBCA mediante un controlador de CA adaptable , que se conecta a EJBCA mediante la API de servicios web. Gracias a esta integración, la plataforma Venafi gestiona automáticamente las funciones de gestión en EJBCA y, desde la perspectiva de la CA, puede considerarse una RA avanzada. Esto permitió a una organización gestionar el uso de todos sus certificados, incluyendo las PKI externas e internas, desde una única plataforma.
Las funciones disponibles en la integración Venafi-EJBCA incluyen:
Recuperación de certificados de CA
Solicitud y emisión de certificados
Renovación de certificados
Revocación de certificados
La instalación del controlador Adaptable CA de integración Venafi-EJBCA se realiza fácilmente colocando el script del controlador (EJBCA.ps1) y WSDL (ejbcaws.wsdl) en su instalación de la plataforma Venafi, configure algunas variables en el controlador incluida la dirección del servidor EJBCA, configure el controlador Adaptable en la plataforma Venafi y configure la autenticación y, finalmente, asocie las plantillas y la política de CA del controlador dentro de su interfaz de administración de Venafi.
Importación de certificados EJBCA existentes
Si está configurando un sistema nuevo, configurar la integración de Venafi con EJBCA desde el principio le proporciona todo lo necesario. Si instala Venafi después de haber ejecutado EJBCA durante un tiempo, puede que desee importar todos los certificados emitidos desde EJBCA a Venafi.
Venafi cuenta con un método para importar certificados desde el sistema de archivos, y se pueden exportar los certificados emitidos desde EJBCA mediante una consulta a la base de datos. Tras exportar todos los certificados desde EJBCA, se puede usar esta función para importarlos a la plataforma Venafi.
Los datos codificados en Base64 de los certificados se almacenan en la columna base64Cert de la tabla CertificateData. Puede obtenerlos mediante SQL de la siguiente manera:
select base64Cert from CertificateData where issuerDN= 'CN=MyCA,O=MyOrg,C=SE' ;Para exportar todos los certificados de la base de datos en formato PEM (por ejemplo, como zip) con el estado (activo, revocado) de todas las CA con un período de tiempo para la selección, utilice un script como el siguiente:
#/bin/shhost=localhostuser=ejbcadatabase=ejbcaissuerdn= "CN=MyCA,O=MyOrg,C=SE"outputDirectory=.read -s -p "Enter database password: " passwordmysql -u$user -p$password -h $host $database -s -e "SELECT serialNumber, CertificateData.status, base64Cert, name FROM CertificateData JOIN CAData ON CertificateData.issuerDN=CAData.subjectDN WHERE CertificateData.issuerDN='$issuerdn';" | while IFS=$ '\t' read -r serialNumber status base64Cert issuerName; domkdir -p $outputDirectory/ejbca_certificate_export/ "$issuerName" / "$status"file=$outputDirectory/ejbca_certificate_export/ "$issuerName" / "$status" / "$serialNumber" .pemecho "-----BEGIN CERTIFICATE-----" >> "$file"echo "$base64Cert" | sed 's/\\n/\n/g' >> "$file"echo "-----END CERTIFICATE-----" >> "$file" ;doneif [[ -d $outputDirectory/ejbca_certificate_export ]]; thenzip -rq certificate_export.zip $outputDirectory/ejbca_certificate_exportrm -rf $outputDirectory/ejbca_certificate_exportfiEsto da como resultado un archivo zip donde se crean directorios para la CA (nombre común) y en el siguiente nivel de estado (20 = activo, 40 = revocado).
También puede hacerlo para todas las CA eliminando la cláusula WHERE CertificateData.issuerDN='$issuerdn'.