Creación de una CA DV y emisión de certificados del sistema de inspección
A continuación se proporciona información sobre la creación de una CA de verificación de documentos (DV) y la emisión de certificados del sistema de inspección.
Inscripción de un sistema de inspección
Contenido relacionado
Introducción
Crear verificadores de documentos (DV) nacionales es tan sencillo como crear una SubCA para su CVCA, utilizando un perfil de certificado SubCA.
Puede firmar DV externos tratándolos como entidades finales normales, crear una entidad final y seleccionar perfiles de certificado de SubCA al agregarla. A continuación, puede procesar las solicitudes de certificado recibidas por el DV externo como una solicitud de certificado de entidad final normal:
Uso de la interfaz de usuario de RA
Uso del cliente WS CLIToolBox CvcWsRaCli
Usando el método cvcRequest de WS-API desde su propio cliente
También puede crear DV externos como SubCA externos. Sin embargo, tenga en cuenta que una ventaja de gestionar DV externos como entidades finales es que puede procesarlos y renovarlos utilizando la misma WS-API que utiliza para los sistemas de inspección.
Puede crear un DV para que lo firme una CVCA externa creando una nueva CA y seleccionando "Firmado por = CA externa" . Necesita el certificado CVCA de la CVCA externa para crear la solicitud que se va a enviar. Al crear esta CA, se genera una solicitud de certificado CV autofirmado.
Puede crear una solicitud de certificado CV desde una entidad de certificación (DV) en cualquier momento. Para ello, acceda a "Editar autoridades de certificación" y haga clic en "Realizar solicitud de certificado" . Esto genera una CSR creada por el almacén de claves de la CA. Al recibir el certificado firmado, puede enviarlo a su sistema de seguridad. No es necesario importarlo a EJBCA.
Puede renovar un certificado de validación (DV) accediendo a "Editar Autoridades de Certificación" y haciendo clic en "Renovar CA" . Al cargar el certificado de la CA que firmará el certificado, podrá obtener una nueva CSR. Puede importar el certificado recibido haciendo clic en "Recibir Respuesta de Certificado" . Solo tiene que (o puede) importar un certificado emitido para que su DV esté operativo. Si recibe un DV firmado por varias CVCA, puede distribuir el certificado que no sea el principal a los IS (o AT o ST) por otros medios.
Al especificar la contraseña de los tokens de CA y habilitar la opción "Renovar claves" , el DV generará nuevas claves. Esto funciona tanto para tokens de CA de software como para tokens de CA PKCS#11. La CSR de renovación no se firma con las claves antiguas, pero esto puede hacerse manualmente.
Las DV tienen periodos de validez cortos y puede ser útil renovarlas automáticamente. Puede usar el servicio EJBCA "Renovar Servicio de CA" para renovarlas automáticamente. Para más información, consulte "Renovar Servicio de CA" .
Convenciones de nomenclatura de DV
Una característica importante de la PKI de Control de Acceso Extendido (EAC) es la creación de DV para múltiples países extranjeros. Este es el caso cuando un país, para leer las huellas dactilares de los documentos de viaje de otros países, solicita (uno o más) DV firmados por el CVCA del otro país. Los estándares son deliberadamente abiertos en cuanto a cómo implementar esto y qué convenciones de nomenclatura utilizar.
La forma recomendada de configurar esto en EJBCA es crear un DV por cada país extranjero cuyas huellas digitales se deben leer. Es decir, tener un DV (SubCA) por cada país, firmado por la CVCA (CA raíz) de ese país.
Las siguientes dos convenciones de nomenclatura se pueden utilizar para crear DV en EJBCA, donde cada DV está firmado por una CA externa , que es el CVCA (país/mnemónico/secuencia) del otro país, donde el mnemónico puede ser arbitrario.
Mnemónico distinto para cada DV
Todos los DV configurados por su país tendrán el mismo código de país, pero el mnemónico se establece en valores diferentes para mostrar en qué país está firmado el DV respectivo.
Esta es la convención de nomenclatura recomendada en EJBCA, ya que proporciona una separación clara de DV que es fácil de mantener y difícil de equivocar.
Algunos ejemplos:
SE/NDVCA01/GR001 (DV establecido en Suecia, para ser firmado por la CVCA griega)
SE/NDVCA02/NO001 (DV establecido en Suecia, a ser firmado por CVCA noruego)
SE/ESDVCA01/00001 (DV establecido en Suecia, a firmar por CVCA español)
etc.
El mnemotécnico ofrece flexibilidad, ya que puede tener entre 1 y 9 caracteres. La secuencia también ofrece flexibilidad, ya que puede usar secuencias numéricas puras de 5 caracteres (00001, 00002, etc.), o código de país + numérico (SE001, SE002, etc.), o código de país + alfanumérico (hexadecimal) (SEA01, SEB01, SEB0F, etc.). Cada DV (SubCA) debe tener una combinación única de país y mnemotécnico, es decir, C y CN, al crearse.
El mismo mnemónico para todos los DV
Todos los DV configurados por su país tendrán el mismo código de país y la misma mnemotecnia. El código de país en la secuencia de teclas se utiliza para distinguir el país que firma el DV correspondiente.
Esta convención de nomenclatura es utilizada por algunos países y respaldada por EJBCA, aunque consideramos que es preferible utilizar diferentes mnemónicos para cada DV.
Algunos ejemplos:
FI/TDVCA001/GR001 (DV creado en Finlandia, para ser firmado por la CVCA griega, utilizando el formato de código de país + secuencia de clave numérica )
FI/TDVCA001/NO001 (DV configurado en Finlandia, para ser firmado por CVCA noruego, utilizando el formato de código de país + secuencia de clave numérica )
FI/TDVCA001/ESFAA (DV creado en Finlandia, para ser firmado por CVCA español, utilizando el formato de código de país + secuencia de clave alfanumérica )
etc.
Al usar el mismo mnemónico para cada DV, la secuencia ofrece menor flexibilidad. La secuencia nunca puede ser la misma para dos DV, ya que podrían ser idénticos (País + Mnemónico + Secuencia). Por lo tanto, se debe usar un formato de secuencia de Código de País + Numérico o Alfanumérico . Cada DV (SubCA) debe tener una combinación única de país, mnemónico y secuencia al crearse.
Al usar el mismo mnemónico para dos DV, debe agregar el componente OU DN al crear la CA en EJBCA. Ejemplo para crear dos DV en la interfaz de administración (componentes OU resaltados):
Autoridades de certificación > Crear
Nombre: DVCA-FI-SE
Tipo: CVCA
Algoritmos y tokens criptográficos para igualar el CVCA de Suecia
Secuencia de teclas: SE001
CA DN: C=FI,CN=TDVCA001, OU=Suecia
Firmado por: CA externa
Subir cvca-se.cvcert
Realizar solicitud, descargar archivo binario para enviar al CVCA de Suecia para su firma, guardar archivo FITDVCA001SE001.cvreq
Nombre: DVCA-FI-NO
Tipo: CVCA
Algoritmos y tokens criptográficos para igualar el CVCA de Noruega
Secuencia de teclas: NO001
CA DN: C=FI,CN=TDVCA001, OU=Noruega
Firmado por: CA externa
Subir cvca-no.cvcert
Realizar solicitud, descargar archivo binario para enviar al CVCA de Noruega para su firma, guardar archivo FITDVCA001NO001.cvreq
Importar certificados DVCA para activar los DVCA
En DVCA-FI-SE:
Autoridades de certificación->DVCA-FI-SE->Editar CA
En la sección 'Creación/renovación de CA firmada externamente->Paso 2 − Importar certificado'
Busque para cargar el certificado firmado por la CVCA sueca: SECVCA00100000_FITDVCA001SE001.cvcert
Haga clic en Recibir respuesta del certificado
El mensaje debe ser: Respuesta del certificado recibida correctamente, CA activada
En DVCA-FI-NO:
Autoridades de certificación->DVCA-FI-NO->Editar CA
En la sección 'Creación/renovación de CA firmada externamente->Paso 2 − Importar certificado'
Busque para cargar el certificado firmado por Norwegian CVCA: NOCVCA00100000_FITDVCA001NO001.cvcert
Haga clic en Recibir respuesta del certificado
El mensaje debe ser: Respuesta del certificado recibida correctamente, CA activada
Creación de un verificador de documentos
Uso de la interfaz de usuario de CA
Esto proporciona una descripción general de un ejemplo de flujo de trabajo completo sobre cómo crear un DV y emitir certificados IS.
Las instrucciones que se describen a continuación son ejemplos y deben ajustarse a sus condiciones locales. Las mismas operaciones también pueden realizarse de otras maneras o utilizando la API de WS en lugar de CA UI.
Crear nuevo DVCA
Para crear un nuevo DVCA:
En el sistema DV local, haga clic en Autoridades de certificación en Funciones de CA para abrir la página Administrar autoridades de certificación .
En el campo Agregar CA , especifique un nombre para la CA de DV y haga clic en Crear .
En la CA creada, especifique lo siguiente:
Tipo de CA : CA CVC.
Algoritmos y Crypto Token para igualar el CVCA extranjero.
Secuencia de teclas según lo especificado por el mnemónico anterior, consulte Convenciones de nomenclatura DV .
DN del sujeto según lo especificado por el mnemónico anterior, consulte Convenciones de nomenclatura de DV .
Firmado por una CA externa o la CA CVC si existe localmente.
Si la CA DV está firmada por una CA local, haga clic en Crear para finalizar la CA.
Si la CA DV está firmada por una CA externa, entonces:
Subir certificado CVCA.
Haga clic en Realizar solicitud de certificado para descargar el archivo binario para enviar a la CVCA externa y luego seguir el flujo de trabajo estándar para inscribir una sub CA.
Mira la solicitud y verifica que parezca correcta:
./ejbcaClientToolBox.sh CvcWsRaCli cvcprint FITDVCA001NO001.cvreqPrinting CV Certificate: FITDVCA001NO001.cvreq7f21 CV_CERTIFICATE7f4e CERTIFICATE_BODY5f29 PROFILE_IDENTIFIER 0 42 CA_REFERENCE NO/CVCA001/ 000007f49 PUBLIC_KEY 6 OID 0.4 . 0.127 . 0.7 . 2.2 . 2.2 . 4 81 MODULUS FFFFFFFF00000001000000000000000000000000FFFFFFFFFFFFFFFFFFFFFFFF 82 COEFFICIENT_A FFFFFFFF00000001000000000000000000000000FFFFFFFFFFFFFFFFFFFFFFFC 83 COEFFICIENT_B 5AC635D8AA3A93E7B3EBBD55769886BC651D06B0CC53B0F63BCE3C3E27D2604B 84 BASE_POINT_G 046B17D1F2E12C4247F8BCE6E563A440F277037D812DEB33A0F4A13945D898C2964FE342E2FE1A7F9B8EE7EB4A7C0F9E162BCE33576B315ECECBB6406837BF51F5 85 BASE_POINT_R_ORDER FFFFFFFF00000000FFFFFFFFFFFFFFFFBCE6FAADA7179E84F3B9CAC2FC632551 86 PUBLIC_POINT_Y 049050E37BF9A234418846F75B9F4132A8630626A40276DE5A91C5DDE525B8F86FE369C50C5D7CF74EA7BF851D7D0AB79AF92272B9CC37D845A4AA0220A7DD02BD 87 COFACTOR_F 15f20 HOLDER_REFERENCE FI/TDVCA001/NO0015f37 SIGNATURE E7782435454A77E70B2108577BCD83EBBA5A1059A2EF6556E007026D6B81F5330A351D8CA7D5A4DDF2B0A7CE199AEF1445E0267B95691DFA61029A36221FD90C Conviértalo en una solicitud autenticada de su CVCA local
Opcionalmente, cree una solicitud autenticada, firmada por su CVCA local. Si la CVCA extranjera confía en su CVCA, podrá verificar automáticamente la CSR de DV.
Para crear una solicitud autenticada, firmada por su CVCA local:
En el sistema CVCA local, haga clic en Autoridades de certificación en Funciones de CA para abrir la página Administrar autoridades de certificación .
Seleccione CVCA → Crear solicitud de firma de certificado autenticado .
Cargue el CSR creado a partir del DV anterior y haga clic en Firmar solicitud de certificado .
Uso de la CLI de EJBCA
El cliente de línea de comandos (CLI) que utiliza WS-API se puede utilizar como referencia sobre cómo utilizar WS-API.
El cliente tiene las siguientes funciones:
cvcrequest : agrega un nuevo usuario y solicita un certificado CV.
cvcgetchain : recupera la última cadena de certificados de un usuario.
cvcprint : se utiliza para analizar e imprimir certificados CV y solicitudes.
Introduzca el comando para recuperar la información de uso:
$ cd dist /clientToolBox$ dist /clientToolBox > . /ejbcaClientToolBox .sh CvcWsRaCliUsage: cvcrequest cvcgetchain cvcprint cvcpem $ dist /clientToolBox > . /ejbcaClientToolBox .sh CvcWsRaCli cvcrequestUsage : cvcrequest <username> <password> <subjectdn> <sequence> <caname> <signatureAlg> ...... $ dist /clientToolBox > . /ejbcaClientToolBox .sh CvcWsRaCli cvcprintUsage : cvcprint <filename> [verifycert]... Autenticación y privilegios de CLI
La CLI utiliza la autenticación de certificado de cliente, lo que permite realizar tareas administrativas en EJBCA siempre que su certificado de cliente tenga los privilegios de administrador de RA correctos en EJBCA.
Para emitir certificados para una solicitud, primero se debe agregar una entidad final a EJBCA. Las solicitudes no autenticadas introducidas mediante la CLI se autentican mediante una contraseña de un solo uso establecida durante el registro de la entidad.
Sin embargo, las solicitudes autenticadas se verifican, se conceden o se rechazan según la verificación de la firma externa de la solicitud. Si ya existe una entidad final y cuenta con un certificado emitido previamente, este puede autenticar la solicitud y concederla automáticamente.
Para las solicitudes DV autenticadas con un certificado CVCA, el certificado CVCA en lugar de un certificado emitido previamente puede autenticar la solicitud.
Ejemplos de CLI
La CLI es parte de la Caja de herramientas del cliente.
Ejecute lo siguiente para crear el cuadro de herramientas del cliente (que se puede usar desde cualquier computadora remota):
$ ant clientToolBox$ cd dist /clientToolBox Ejemplo 1: Recepción de solicitud de un DV extranjero
A continuación se muestra un comando de ejemplo para recibir una solicitud de un DV externo:
$ . /ejbcaClientToolBox .sh EjbcaWsRaCli edituser dv-de foo123 false "CN=dvca,C=DE" NULL NULL CVCAPK 1 USERGENERATED NEW DV DV $ . /ejbcaClientToolBox .sh CvcWsRaCli cvcrequest dv-de foo123 "CN=dvca,C=DE" SE001 SHA256WithRSA 2048 false dedvDónde
Su CVCA se llama CVCAPK en EJBCA y utiliza el algoritmo SHA256WithRSA con claves de 2048 bits.
Se crea un perfil de entidad final, DV , con CN y C como campos DN obligatorios y DV como perfiles de certificado disponibles.
Se crea un perfil de certificado, DV , del tipo SubCA .
La solicitud recibida se almacena en un archivo dedv.cvreq .
El primer comando agrega la entidad final en EJBCA y solo debe ejecutarse la primera vez. foo123 es la contraseña de un solo uso establecida para autenticar la solicitud.
Si la solicitud es una solicitud autenticada firmada por una CVCA y dicha CVCA se ha importado en EJBCA ( Editar Autoridades de Certificación → Importar certificado de CA ), se verificará y se concederá. En las solicitudes autenticadas, no se utiliza la contraseña de un solo uso.
Ejemplo 2: Generación de claves y solicitud de un IS
A continuación se muestra un comando de ejemplo para generar claves y una solicitud para un IS utilizando SHA256WithECDSA y la curva secp256r1:
$ . /ejbcaClientToolBox .sh EjbcaWsRaCli edituser issecp foo123 false "CN=ISSECP,C=SE" NULL NULL DVCA 1 USERGENERATED NEW IS ISEste comando agrega el IS como entidad final en EJBCA. Solo debe ejecutarse la primera vez o si los certificados previos del IS expiran. Al usar solicitudes autenticadas, se usan estas en lugar de la contraseña de un solo uso; sin embargo, si el certificado anterior expira, se requiere una nueva contraseña de un solo uso para autenticar la solicitud.
$ . /ejbcaClientToolBox .sh CvcWsRaCli cvcrequest issecp foo123 "C=SE,CN=ISSECP" 00005 SHA256WithECDSA secp256r1 true issecpDónde
Su DV se denomina DVCA en EJBCA y utiliza el algoritmo SHA256WithECDSA con curva secp256r1. Se crea un perfil de entidad final, IS , con CN y C como campos DN obligatorios, e IS como perfiles de certificado disponibles.
Se crea un perfil de certificado, IS , del tipo EndEntity .
La solicitud generada se almacena en un archivo issecp.cvreq , la clave privada generada en issecp.pkcs8 .
El certificado IS emitido se almacena en el archivo issecp.cvcert .
Si la solicitud es una solicitud autenticada firmada por un CVCA y ese CVCA se ha importado en EJBCA, la solicitud se verificará y se concederá.
Para crear una solicitud autenticada para este usuario, puede emitir el siguiente comando, que autentica la nueva solicitud con la clave y el certificado antiguos.
$ . /ejbcaClientToolBox .sh CvcWsRaCli cvcrequest issecp foo123 "C=SE,CN=ISSECP" 00006 SHA256WithECDSA secp256r1 true issecpnew issecp.pkcs8 issecp.cvcertLa solicitud se concederá automáticamente (se ignorará la contraseña pasada) y el nuevo certificado se escribirá en issecpnew.cvcert .
Creación de un DV y gestión del ciclo de vida del DV mediante servicios web EJBCA
Puedes crear un DV y gestionar completamente su ciclo de vida mediante la API de WS. Puedes usar la siguiente secuencia de comandos:
createExternallySignedCa: crea un DV, generando un CSR que será firmado por un CVCA, ya sea un CVCA nacional fuera de línea o un CVCA extranjero.
caCertResponse: Importa el certificado DV recibido, emitido por la CVCA, activando el DV.
caRenewCertRequest: Renovación del DV, generación de nuevas claves y una nueva CSR para enviar a la CVCA. La clave y el certificado del DV antiguos permanecen activos hasta recibir la respuesta de la CVCA.
caCertResponse: Importa el certificado DV recibido, activando la nueva clave de firma y el certificado del DV.
Hay un ejemplo de código Java para el ciclo de vida de DV en la suite de pruebas de EJBCA. Un buen ejemplo que ilustra el uso de los comandos anteriores es, por ejemplo, el caso de prueba EjbcaWSCVCTest.test36MultipleDVWithSameDNECC .
Inscripción de un sistema de inspección
Crear un IS firmado por DVCA-SE (sistema de inspección en SE, lectura de pasaportes del país de la CVCA extranjera).
Uso de la interfaz de usuario de RA
En el sistema DV local, vaya a RA UI → Inscribirse
Seleccionar perfil de entidad final (IS, creado previamente):
Nombre de usuario: TESTISSE1
C:FI
CN: PRUEBA1
Perfil del certificado: USUARIO FINAL
CA: DVCA-SE
Token: generado por el usuario
Uso de la caja de herramientas del cliente de EJBCA
Inscribir certificados (algoritmo de coincidencia y claves con DVCA/CVCA):
. /ejbcaClientToolBox .sh CvcWsRaCli cvcrequest TESTISSE1 enrollment_code "CN=TESTISSE1,C=FI" 00001 SHA256WithECDSA prime256v1 true TESTISSE1Mire el certificado emitido y verifique que parezca correcto:
. /ejbcaClientToolBox .sh CvcWsRaCli cvcprint TESTISSE1.cvcertPrinting CV Certificate: FITDVCA001NO001.cvreqPrinting CV Certificate: TESTISSE1.cvcert7f21 CV_CERTIFICATE7f4e CERTIFICATE_BODY5f29 PROFILE_IDENTIFIER 042 CA_REFERENCE FI /TDVCA001/SE0017f49 PUBLIC_KEY6 OID 0.4.0.127.0.7.2.2.2.2.386 PUBLIC_POINT_Y 047CECB7C2ED8C9C76526D9B73EFF734166ACFA6E30DBF92F6C450042B6C108491AD3AB1FA11709E4B3B74A310C6783C9305623C1F3FFA0E468D1140864658B2DC5f20 HOLDER_REFERENCE FI /TESTISSE1/000017f4c HOLDER_AUTH_TEMPLATE6 OID 0.4.0.127.0.7.3.1.2.153 ROLE_AND_ACCESS_RIGHTS 03: IS /DG3 +DG45f25 EFFECTIVE_DATE 2020-05-155f24 EXPIRATION_DATE 2022-05-155f37 SIGNATURE 98A7456C771FEC77208180FAF74CCDF0FA649CA23C5E4C98FC0524046C122C5C20CB1DBA8EB66ECBBA51C06E9B9C936B6BED2E4D2AD9B493E1304D0807EE9C3B Contenido relacionado
Página: Gestión de CA CVC
Página: CVC CA
Página: Creación de una CA CVC