Emisión de certificados TLS
La emisión de certificados TLS es un caso de uso común, tanto para proveedores públicos de certificados TLS como para PKI empresariales que necesitan aprovisionar certificados de servidor TLS internamente. En esta solución, se busca obtener certificados de corta duración y la máxima automatización posible, además de tener altos requisitos en la generación de OCSP y CRL.
Dado que esta infraestructura de clave pública (PKI) estará expuesta a internet, la seguridad del dominio es fundamental. EJBCA permite que los nodos externos (Autoridades de Registro [AR] y Autoridades de Validación [AV]) se conecten no solo a la autoridad de certificación (CA) mediante TLS mutuo, sino también con la CA tras un firewall unidireccional. La compatibilidad con multiusuario permite que todas sus suborganizaciones y divisiones compartan la misma infraestructura PKI con una amplia seguridad de dominio implementada para garantizar la integridad de los silos de seguridad.
Probablemente también necesite generar una Declaración de Prácticas de Certificación (DPC) y someterla a una auditoría externa. Las siguientes secciones explican cómo configurar todo esto con EJBCA.
Configurar la infraestructura inicial de CA
Como es común en muchas PKI, es importante contar con una infraestructura de CA sólida. Su CA raíz probablemente estará aislada y sin conexión, con sub-CA agrupadas para brindar resiliencia. Sus nodos externos serán VA y RA, ubicados frente a un firewall robusto que solo permite conexiones salientes (porque... no desea que su infraestructura de CA quede expuesta) y detrás de balanceadores de carga.
Para obtener más información sobre la configuración de la infraestructura de CA inicial, consulte:
→ Cómo instalar EJBCA
→ Cómo agrupar EJBCA
→ Cómo configurar EJBCA como una RA
Seguridad del dominio
La seguridad del dominio es fundamental. Sus VA probablemente deberán estar expuestos a internet para proporcionar CRL y responder a solicitudes OCSP, mientras que sus RA deberán estar expuestos, como mínimo, internamente a su red general para permitir que los usuarios y servidores se registren para obtener certificados, o en el peor de los casos, a internet si planea emitir certificados a terceros. Si bien puede ser tentador tener todas sus instancias en el mismo dominio, es muy recomendable mantener sus CA tras un firewall unidireccional que permita solo conexiones salientes. EJBCA soluciona esto mediante el protocolo Peers , que no solo utiliza TLS con autenticación mutua, sino que también permite que la CA inicie todas las conexiones.
Las siguientes secciones cubren cómo configurar las conexiones necesarias.
Crear CA raíz y CA secundaria
Inicialmente, necesita un mínimo de cuatro instancias de EJBCA: un nodo que actúe como CA raíz , un nodo de subCA , una Autoridad de Registro (RA) y una Autoridad de Validación (VA) . Además, trabajará con tres CA:
Una CA de administración , ubicada en cualquier nodo. Su función es emitir certificados de usuario internos, como el almacén de claves del servidor de aplicaciones, certificados de cliente para administradores, certificados TLS para conexiones entre pares, etc.
Una CA raíz en el nodo de CA raíz, que es la cabeza de la jerarquía.
Una CA emisora en el nodo de la sub-CA, firmada por la CA raíz. El propósito de tener una CA raíz y una CA emisora es doble:
Es posible que desee tener varias CA emisoras diferentes en la misma jerarquía para diferentes inquilinos/propósitos.
Si su CA emisora se ve comprometida de alguna manera, es esencial que la firme una raíz para permitirle recuperar su PKI.
A continuación se describe una jerarquía básica de CA y se proporcionan enlaces a más información sobre cómo configurarla en EJBCA.
Crear CA emisora
A continuación, importe el certificado de la CA raíz en el nodo de la CA secundaria, luego cree la CA emisora y haga que la CA raíz la firme.
Configurar la transparencia del certificado
Si planea que su CA TLS sea reconocida por los almacenes raíz del navegador, la Transparencia de Certificados es una de las tecnologías que necesita respaldar.
→ Cómo agregar registros de transparencia de certificados a EJBCA
Configurar perfiles
En su CA emisora, configure los Perfiles de Certificado y los Perfiles de Entidad Final para sus entidades finales. En resumen, los Perfiles de Certificado describen las características del certificado (claves, algoritmos, extensiones, etc.) que pueden ser comunes entre diferentes entidades finales, mientras que los Perfiles de Entidad Final describen los campos relacionados con la propia entidad final (DN del Sujeto, Nombre Alternativo del Sujeto, etc.) que serían específicos de una entidad final, pero comunes a todos sus certificados.
→ Cómo configurar un perfil de certificado para certificados TLS
Configurar la infraestructura de VA
El siguiente paso es configurar la infraestructura de su VA para que pueda responder a las solicitudes OCSP. Si bien la CA es totalmente capaz de responderlas por sí sola, es poco probable que desee que esté expuesta a solicitudes entrantes de la web, por lo que la tarea se delega en la VA. La función de la VA es responder a las solicitudes OCSP mediante la publicación de la información de revocación por parte de la CA a través de sus pares.
→ Cómo configurar la autenticación TLS entre la CA emisora y una autoridad de verificación
→ Cómo conectar la CA emisora y la autoridad de verificación a través de pares
Configurar la inscripción
En cuanto a la inscripción, dispone de varias opciones, según su caso de uso. ¿Prevé que el titular del certificado lo solicite manualmente, que lo haga a través de su propio equipo de PKI o que se inscriba automáticamente a través de un cliente mediante un protocolo de inscripción?
Establecer una Autoridad de Registro
Cualquiera que sea el caso que pueda aplicarse a su PKI, es probable que desee procesar una solicitud de inscripción a través de un Autoridad de Registro (AR) para evitar exponer su CA al mundo. Al igual que con la VA mencionada anteriormente, sus AR se conectarán a la CA mediante el protocolo Peers. Puede usar la misma instancia EJBCA que la VA y la AR si lo desea.
→ Cómo configurar la autenticación TLS entre la CA emisora y una autoridad de registro
→ Cómo conectar la CA emisora y la autoridad de registro a través de pares
No hay límite para la cantidad de Autoridades de Registro que puede conectar a una instancia de CA. En su lugar, puede escalar para gestionar sus volúmenes y separarlos mediante reglas de acceso para permitir una verdadera multiusuario.
Inscripción manual
La opción más rápida y sencilla para inscribir y emitir un certificado a través de EJBCA es a través de la interfaz de usuario de RA, a la que se puede acceder tanto en la instancia de CA emisora como a través de una autoridad de registro.
La interfaz de usuario de RA funciona de inmediato para usuarios autenticados, pero también puede configurarla como un portal de inscripción para usuarios sin certificados de navegador.
→ Cómo configurar la interfaz de usuario de RA para el acceso público
Protocolos
Si la inscripción va a ser de un cliente fuera de EJBCA, la solución TLS tiene cuatro casos de uso comunes:
CUMBRE
El protocolo ACME está diseñado específicamente para certificados TLS, y se puede encontrar una gran cantidad de clientes externos con excelente soporte en la web. Está diseñado fundamentalmente para la automatización y la renovación automática de certificados de corta duración. EJBCA es compatible con todo el protocolo, incluyendo las vinculaciones de cuentas externas, y, además de la especificación, permite múltiples puntos finales para diferentes tipos de certificados en el mismo servidor.
EST
Para muchos clientes cuyos casos de uso no se ajustan exactamente a ACME, EST es un protocolo moderno y liviano para la inscripción, totalmente compatible con EJBCA.
API REST de EJBCA
La API REST de EJBCA es el protocolo más reciente de nuestra empresa y está diseñada para la automatización. Contiene todas las llamadas API necesarias para que sus clientes personalizados inscriban certificados de forma fácil y automática a través de EJBCA.
API SOAP EJBCA
Nuestra interfaz SOAP (WS) es más antigua, pero aún se usa ampliamente. Al ser más madura, cuenta con un conjunto de funciones más completo.
Control de acceso
Es probable que su organización requiera algún tipo de control de acceso dual (o múltiple) para ciertas funciones, como la aprobación de la emisión de certificados por parte de varios administradores o la verificación de solicitudes de revocación. EJBCA ofrece un potente sistema de aprobaciones, que puede ser acumulativo (p. ej., simplemente requiere que un número determinado de usuarios de confianza aprueben la acción) o más complejo , con secuencias que se ejecutan tanto en paralelo como en serie, y con diferentes roles autorizados para aprobar o revisar diversas instancias.
Validación
Durante todo el proceso de emisión, desde el envío de la clave pública hasta la emisión del certificado, probablemente querrá asegurarse de que la clave que firma supere las comprobaciones de seguridad básicas. Puede hacerlo conectando validadores a las configuraciones de su CA.
A continuación se muestran algunas configuraciones de ejemplo que probablemente necesitará realizar.
Validación de CAA
Si su CA TLS debe cumplir con los requisitos básicos del almacén raíz del navegador, deberá verificar que el dominio solicitado en la solicitud de firma de certificado la haya especificado como permitida. El validador de CAA realizará automáticamente una búsqueda de DNS antes de emitir un certificado para un dominio específico.
Listas de bloqueo de dominios
El Validador de Lista de Bloqueo de Dominios le permite cargar una lista de dominios para los cuales no se emitirán certificados, con el fin de agregar cierta seguridad para no caer en estafas de phishing.
Validación de claves
Los validadores de claves RSA y EC validarán las claves públicas enviadas para detectar vulnerabilidades conocidas y se negarán a firmarlas si no coinciden. Para las CA que cumplen con los requisitos básicos del programa raíz, ambos validadores cuentan con una plantilla CA/Browser-Forum.
<p >
Validación de Linter
Por último, pero no por ello menos importante, proporcione el Validador de Certificado de Comando Externo que le permite enviar precertificados a través de un Linter externo (como ZLint, X509Lint o un Linter de Claves Débiles de Debian) para verificar que se ajustan a sus requisitos y no tiene que correr el riesgo de una emisión incorrecta.
Contenido relacionado
Para profundizar en el funcionamiento interno de EJBCA, consulte la Guía de conceptos de CA de EJBCA y para obtener más información sobre la configuración de CA, perfiles y configuración general de una instancia EJBCA, consulte la Guía de operaciones de CA EJBCA.
Para obtener más información sobre otras áreas de soluciones interesantes y lo que necesita configurar, consulte Áreas de soluciones .
Áreas de solución
Página: Implementación de PKI y servicios de firma en entornos DevOps
Página: Emisión de certificados de identidad electrónica y firma de pasaportes electrónicos
Página: Implementación de PKI híbrida para fabricantes modernos
Página: PKI y servicios de firma para microservicios y entornos DevOps
Página: PKI para 3GPP
Página: Preparación post-cuántica