CA raíz

Una CA raíz cuenta con un certificado autofirmado y también se denomina raíz de confianza. La verificación de otros certificados en la PKI finaliza con el certificado autofirmado de la CA raíz. Dado que el certificado de la CA raíz es autofirmado, debe configurarse como raíz de confianza para todos los clientes de la PKI.

Sub CA

Una CA subordinada, o SubCA, es una CA cuyo certificado está firmado por otra CA, que puede ser otra SubCA o una CA raíz. Dado que el certificado de la SubCA está firmado por otra CA, no es necesario configurarlo como raíz de confianza. Forma parte de una cadena de certificados que termina en la CA raíz.

Autoridad de Registro (RA)

Una Autoridad de Registro (AR) es una función administrativa que registra entidades en la PKI. Se confía en la AR para identificar y autenticar entidades según la política de la CA. Puede haber una o más AR conectadas a cada CA de la PKI.

Autoridad de Validación (VA)

Una Autoridad de Validación (AV) es responsable de proporcionar información sobre la validez de un certificado. La AV no emite ni revoca certificados, sino que los valida proporcionando una lista de certificados revocados para una CA, conocida como Lista de Revocación de Certificados (LRC). Otro método compatible con la AV es el Protocolo de Estado de Certificados en Línea (OCSP). Este protocolo permite consultar el estado de un certificado en tiempo real, en comparación con la LRC, que se genera según un calendario establecido. La AV puede responder a las solicitudes del OCSP e indicar si un certificado es válido, revocado o desconocido. Puede haber una o más AV conectadas a cada CA en la PKI.

Autoridad de certificación (CA)

Una autoridad de certificación (CA) emite certificados y garantiza la autenticidad de las entidades.

El nivel de confianza que puede asignar a una CA es individual, por CA, y depende de la Política de la CA (CP) y la Declaración de Prácticas de la CA (CPS).

Para obtener más información, consulte Descripción general de la autoridad de certificación .

Entidad final

Una entidad final es un usuario de la PKI, como un dispositivo, una persona o un servidor. Se denomina entidad final porque, en una jerarquía de certificados de la PKI, siempre es el punto final, ya que no está autorizada a emitir certificados propios.

La entidad final, ya sea individual o dispositivo, solicita un certificado a la CA o RA. Una entidad final puede tener varios certificados, pero todos tendrán los mismos valores de identificación (DN del sujeto, nombre alternativo del sujeto, etc.).

Tenga en cuenta que una Entidad Final no debe confundirse con una persona física. Desde la perspectiva de una CA, una Entidad Final puede ser un usuario físico, pero en realidad es cualquier entidad que posea un certificado. También podría ser un Firmante de OCSP o una Sub CA.

Cada entidad final está inscrita en una sola CA, que será conocida como el emisor de los certificados de esa entidad final.

Para obtener más información, consulte Descripción general de entidades finales .

Perfil de entidad final

Los perfiles de entidad final definen plantillas para las entidades finales. Un perfil de entidad final no es inherentemente necesario, ya que EJBCA proporciona un perfil predeterminado (denominado Empty ) sin restricciones. Sin embargo, para casi todas las PKI es útil, y a menudo necesario, establecer restricciones sobre los valores que los usuarios pueden usar para inscribirse en una entidad final. Los valores definidos en los perfiles de entidad final son los que pertenecen directamente a la entidad final y, por extensión, a los campos de identificación del certificado, excepto los datos sobre claves y firmas, que se definirán en los perfiles de certificado . Los valores típicos definidos, además de los perfiles de certificado y las CA disponibles, serán valores de identificación como el DN del sujeto (país, organización, nombre común, etc.) y los nombres alternativos del sujeto (SAN), como dnsName.

Los valores definidos en los Perfiles de Entidad Final pueden ser predefinidos (no modificables durante la inscripción), con un valor predeterminado pero modificables, sin definir pero críticos (es decir, deben completarse durante la inscripción) o completamente opcionales. Los Perfiles de Entidad Final pueden ser tan específicos o generales como se desee, por lo que pueden abarcar desde una Entidad Final específica hasta un conjunto completo. Cada Entidad Final utiliza un solo perfil, pero el mismo puede ser compartido por varias Entidades Finales.

Para obtener más información, consulte Descripción general de perfiles de entidad final .

Perfil del certificado

Un perfil de certificado se utiliza para configurar determinados contenidos y restricciones de los certificados, como extensiones de certificado, algoritmos disponibles, tamaños de clave, etc. Básicamente, describe a qué se restringirá un certificado emitido.

Las extensiones de certificado permiten definir si una extensión específica está presente y si es crítica o no. Algunas extensiones se rellenan con un valor, que es el mismo para todos los certificados, como CRLDistributionPoint. Para otras extensiones, solo se determina la presencia, donde el valor es específico del usuario o del certificado, como SubjectAlternativeName. Aquí también se determina si estos certificados se publicarán y con qué editor.

Los perfiles de certificado se utilizan en múltiples lugares. Se seleccionan en la configuración de la CA para definir la naturaleza de los certificados de sus propias claves:

Asimismo, se pueden elegir varios al configurar un Perfil de Entidad Final:

El perfil de certificado definido para la CA no afectará a los certificados emitidos a las entidades finales por esa CA; estos certificados se definirán según los perfiles de certificado elegidos en los perfiles de entidad final:

Los perfiles de certificado están diseñados para definirse de forma genérica y compartirse entre diferentes perfiles de entidad final. Esto significa que entidades finales con diferencias suficientes como para justificar perfiles de entidad final independientes pueden compartir el mismo perfil de certificado. Además, los perfiles de entidad final también pueden definir varios perfiles de certificado, lo que permite a una misma entidad final elegir entre diferentes tipos de certificados que se le pueden emitir, o bien, emitir varios tipos de certificados diferentes. Cada certificado se define mediante un único perfil de certificado.

Para obtener más información, consulte Descripción general de perfiles de certificado .

Token criptográfico

El término token criptográfico proviene de su uso en HSM, donde el token criptográfico es la parte de una ranura del módulo de seguridad de hardware (HSM) que contiene las claves criptográficas de dicha ranura. Este concepto se refleja en EJBCA, donde un token criptográfico es la representación de un conjunto de claves criptográficas que pueden estar protegidas por una contraseña y activarse o desactivarse en su totalidad. Los tokens criptográficos se presentan en dos versiones.

• Tokens criptográficos blandos que se almacenan en la base de datos como archivos PKCS#12 protegidos por una contraseña

• Tokens criptográficos PKCS#11 que se almacenan dentro de un HSM y a los que se accede a través de la API PKCS#11.

Cada CA tiene un solo Crypto Token, aunque varias CA podrían compartir el mismo Crypto Token.

Además, los tokens criptográficos también se utilizan para otras construcciones en EJBCA que requieren el uso de claves criptográficas:

• En OCSP Firmantes para firmar respuestas OCSP.

• En las vinculaciones de claves de autenticación para que las instancias de EJBCA se comuniquen a través de TLS.

De la misma manera, los firmantes OCSP y las vinculaciones de claves de autenticación utilizan cada uno un único token criptográfico, aunque varios pueden compartir el mismo.

Para obtener más información, consulte Descripción general de tokens criptográficos .

Editores

Un editor almacena los certificados emitidos en una ubicación central. EJBCA ha implementado compatibilidad con LDAP y Active Directory, pero también es posible crear complementos personalizados.

Vinculación de teclas interna

Un enlace de clave interno permite que las claves de un token criptográfico estén disponibles para otros usos que no sean los de una CA. Es una referencia a un par de claves disponible para la instancia EJBCA, un certificado que no es de una CA, una lista opcional de certificados de confianza y propiedades para su propósito. Puede considerarse un almacén de claves simplificado con propiedades específicas para cada propósito. Por ejemplo, un enlace de clave OcspKeyBinding permite firmar respuestas OCSP en nombre de una CA. Contiene una clave en un HSM accesible desde la instancia EJBCA (mediante un token criptográfico) y un certificado de firma OCSP. Además, los certificados de confianza permiten verificar que las solicitudes OCSP provienen de una fuente confiable, y se pueden usar propiedades adicionales para especificar la validez de una respuesta OCSP.

Conector de pares

Un conector de pares es una representación de un sistema remoto de pares (EJBCA o compatible con EJBCA) y puede utilizarse para la gestión automatizada de dicho sistema. Se utiliza un protocolo propietario a través de un canal HTTPS con doble autenticación (donde las claves de certificado del cliente pueden almacenarse en un HSM). Ejemplo: Si una instancia EJBCA (que actúa como CA) recibe suficiente autorización en otra instancia EJBCA (que actúa como VA), la primera puede publicar información de revocación de certificados en la segunda instancia o realizar la renovación automática de las claves de firma y los certificados de OCSP a través del canal seguro.

RA externa

EMPRESA Esta es una característica de EJBCA Enterprise.

En algunos casos, por razones de seguridad, es preferible denegar todo el tráfico entrante a la CA y, en su lugar, permitir que esta obtenga y procese periódicamente información de fuentes de datos externas de confianza. Por este motivo, la distribución EJBCA Enterprise incluye un módulo adicional llamado externalra ( API de RA externa ).

Protocolo de estado de certificado en línea (OCSP)

Los clientes de PKI utilizan OCSP para verificar la validez de los certificados en tiempo real. OCSP se define en RFC 6960 y RFC 5019.

Protocolo de gestión de certificados (CMP)

CMP es un protocolo de Internet utilizado para obtener certificados digitales X.509 en una infraestructura de clave pública (PKI). Se describe en el RFC 4210 y es uno de los dos protocolos que utilizan el Formato de Mensaje de Solicitud de Certificado (CRMF), descrito en el RFC 4211 .

Inscripción mediante Transporte Seguro (EST)

EST es un protocolo estandarizado de inscripción de certificados que describe un protocolo de gestión de certificados X.509. EJBCA admite el protocolo EST, tal como se define en RFC7030 .

Protocolo simple de inscripción de certificados (SCEP)

SCEP es un protocolo comúnmente utilizado por equipos de red para la inscripción de certificados. En general, SCEP ha sido reemplazado por el protocolo similar Inscripción sobre Transporte Seguro (EST) , que recomendamos como alternativa.

Entorno de gestión automática de certificados (ACME)

ACME es un protocolo que una autoridad de certificación (CA) y un solicitante pueden utilizar para automatizar el proceso de verificación y emisión de certificados.