Operaciones del CMP 3GPP
Esta página describe cómo configurar CMP para 3GPP y operaciones y pruebas comunes.
Configuración de EJBCA para la comunicación directa entre CA y estación base
Configuración de EJBCA para CA: comunicación de estación base a través de una RA
Esta página describe la configuración y las operaciones para usar EJBCA con 3GPP. Para obtener más información sobre el estándar CMP 3GPP y la integración de EJBCA con él, consulte la página "Descripción general de 3GPP" .
Configuración de EJBCA para la comunicación directa entre CA y estación base
Para configurar EJBCA para la comunicación directa entre CA y estación base, haga clic en Configuración de CMP en Funciones del sistema y configure un alias de CMP con la siguiente configuración:
Opción de configuración | Configuración |
Modo operativo CMP | Modo cliente |
Modo de autenticación CMP | Certificado de entidad final |
Modo de certificado de proveedor | Utilice y especifique el nombre de la CA del proveedor |
Permitir actualización automática de claves | Permitir |
Permitir la renovación del certificado con las mismas claves | Permitir |
El modo cliente del modo operativo CMP funciona como cualquier otra inscripción en EJBCA. Cuando se recibe una solicitud, EJBCA la verifica (consulte Autenticación de mensajes CMP ) y emite un certificado a un usuario previamente registrado en EJBCA. Para obtener más información sobre los modos operativos CMP, consulte CMP .
A continuación se muestran las configuraciones en la página Editar alias de CMP:
Tenga en cuenta que EJBCA siempre autentica una solicitud de actualización utilizando únicamente el módulo EndEntityCertificate, independientemente de cuántos módulos de autenticación estén configurados. Sin embargo, para que la solicitud de actualización se autentique correctamente, el módulo EndEntityCertificate debe estar configurado como uno de los módulos de autenticación utilizados.
Configuración de EJBCA para CA: comunicación de estación base a través de una RA
El estándar 3GPP CMP especifica un perfil utilizable para la comunicación directa entre CA y dispositivo. Si bien este es el caso de uso principal de la especificación 3GPP, a menudo se encuentran soluciones cuando un punto central de confianza, una autoridad de registro o una pasarela de seguridad necesita emitir certificados a entidades finales bajo su control. Para estos casos, se puede utilizar CMP en modo RA, un perfil de CMP no descrito en el estándar 3GPP.
Para configurar EJBCA para la comunicación directa entre CA y estación base a través de una RA, haga clic en Configuración de CMP en Funciones del sistema y configure un alias de CMP con la siguiente configuración:
Opción de configuración | Configuración |
Modo operativo CMP | Modo RA |
Modo de autenticación CMP | EndEntityCertificate y especifique el emisor del certificado en extraCerts |
Esquema de generación de nombres de RA | DN y especifique la parte DN que se utilizará como nombre de usuario |
Permitir actualización automática de claves | Permitir |
Perfil de entidad final de RA | El nombre del perfil de entidad final que se utilizará al agregar entidades que representan las subestaciones |
Perfil del certificado RA | ProfileDefault o el nombre del perfil de certificado que se utilizará al crear certificados para las subestaciones |
Nombre de RA CA | ProfileDefault o el nombre de la CA que se utilizará al crear entidades finales y certificados para las subestaciones |
Permitir actualización automática de claves | Permitir |
Permitir la renovación del certificado con las mismas claves | Permitir |
El modo operativo CMP ( RA) se utiliza cuando el cliente CMP actúa como RA para EJBCA (la RA envía una solicitud de certificado a EJBCA). Ningún usuario se prerregistra en EJBCA, pero cuando llegan mensajes CMP de RA autenticados, se crea un usuario en EJBCA y se emite un certificado. Para obtener más información sobre los modos operativos CMP, consulte CMP .
A continuación se muestran las configuraciones en la página Editar alias de CMP:
Inscripción de dispositivo con certificado de proveedor
Un flujo de trabajo PKI, según lo especificado en el estándar 3GPP, utiliza CMP para inscribir un dispositivo, autenticando la solicitud inicial mediante un certificado de proveedor añadido al dispositivo durante la fabricación. Tras la inscripción inicial, el dispositivo puede renovar automáticamente el certificado cuando esté a punto de caducar.
Hay una CA raíz de proveedor y una CA secundaria de proveedor que emite un certificado de proveedor para el dispositivo, que viene preaprovisionado de fábrica.
La CA raíz del proveedor es confiable para la inscripción inicial, para dispositivos registrados previamente en EJBCA con partes del DN (generalmente el número de serie del dispositivo).
Queremos generar dos certificados para el dispositivo, uno para IPSEC y otro para TLS, y así el Certificado del Proveedor se utiliza para múltiples autenticaciones a diferentes entidades finales.
Generar dos nuevos pares de claves en el dispositivo
La inscripción inicial de un certificado IPSEC para la nueva clave en el dispositivo utiliza la autenticación de certificado con el certificado del proveedor en el dispositivo.
La inscripción inicial de un certificado TLS para la nueva clave en el dispositivo utiliza la autenticación de certificado con el certificado del proveedor en el dispositivo.
Generar dos nuevos pares de claves en el dispositivo
Renovar el certificado IPSEC para el nuevo par de claves, autenticado utilizando el par de claves y el certificado antiguos
Renovar el certificado TLS para el nuevo par de claves, autenticado utilizando el par de claves y el certificado antiguos
Los pasos anteriores se pueden simular en la realidad utilizando el cliente cmpforopenssl , pero también utilizando el EJBCA cmpclient .
En este ejemplo, mostramos cómo emitir certificados IPSec y TLS. Dependiendo de su caso, es posible que solo necesite uno de ellos, no ambos.
Esto funciona con dos cmpaliases configuradas con parámetros:
CMP Alias: aliasIPSECCMP Operational Mode: ClientCMP Authentication Module : EndEntityCertificateExtract Username Component : CNRA Name Generation Postfix : _IPSECVendor Certificate Mode: UseList Of Vendor CAs: Add Vendor Root CA (imported as External CA in EJBCA)CMP Alias: aliasTLSCMP Operational Mode: ClientCMP Authentication Module : EndEntityCertificateExtract Username Component : CNRA Name Generation Postfix : _TLSVendor Certificate Mode: UseList Of Vendor CAs: Add Vendor Root CA (imported as External CA in EJBCAEl certificado del proveedor se emite (se sugiere como un almacén de claves con la clave privada) desde la CA secundaria del proveedor con subjectDN: CN=1234.primekey.com,O=PrimeKey,C=SE
Generar pares de claves:
$ ./opensslgenrsa -out certs/ipsec_key.pem 2048$ ./opensslgenrsa -out certs/tls_key.pem 2048Inscripción inicial:
Antes de la inscripción inicial, agregue dos nuevas entidades finales en EJBCA, en este ejemplo con el nombre de usuario 1234.primekey.com_IPSEC y 1234.primekey.com_TLS con DN de asunto 'CN=ipsec1234' o 'CN=hostname1234'.$ opensslcmp-cmd ir -server localhost:8080 -path ejbca/publicweb/cmp/aliasIPSEC\-cert VendorDeviceCert.pem -key VendorDeviceKey.pem -certout operator_ipsec_cert.pem -newkey ipsec_key.pem \-subject"/CN=ipsec1234"-extracerts VendorExtraCerts.pem -trusted IPSECROOTRSA.cacert.pem \-implicit_confirm$ opensslcmp-cmd ir -server localhost:8080 -path ejbca/publicweb/cmp/aliasTLS\-cert VendorDeviceCert.pem -key VendorDeviceKey.pem -certout operator_tls_cert.pem -newkey tls_key.pem \-subject"/CN=hostname1234"-extracerts VendorExtraCerts.pem -trusted TLSROOTRSA.cacert.pem \-implicit_confirmGenerar nuevos pares de claves:
$ ./opensslgenrsa -out certs/ipsec_new_key.pem 2048$ ./opensslgenrsa -out certs/tls_new_key.pem 2048Renovar con nuevos certificados:
$ opensslcmp-cmd kur -server localhost:8080 -path ejbca/publicweb/cmp/aliasIPSEC\-cert ipsec_cert.pem -key ipsec_key.pem -certout ipsec_new_cert.pem -newkey ipsec_new_key.pem \-subject"/CN=ipsec1234"-extracerts IPSECCAcerts.pem -trusted IPSECROOTRSA.cacert.pem \-implicit_confirm$ opensslcmp-cmd kur -server localhost:8080 -path ejbca/publicweb/cmp/aliasTLS\-cert tls_cert.pem -key tls_key.pem -certout tls_new_cert.pem -newkey tls_new_key.pem \-subject"/CN=hostname1234"-extracerts TLSCAcerts.pem -trusted TLSROOTRSA.cacert.pem \-implicit_confirm
Jerarquía de PKI de proveedores de tres niveles
Las jerarquías de CA del proveedor pueden ser de dos o tres niveles (o incluso de cuatro), es decir, CA raíz → ID de dispositivo o CA raíz → Sub CA → ID de dispositivo. La sección 9.5.4.2 de 3GPP 33.310 indica que en una jerarquía de tres niveles, el certificado de la estación base y el certificado intermedio deben incluirse en el campo extraCerts de la solicitud CMP.
A continuación se muestra un ejemplo del comando cmpforopenssl para probar la autenticación de CA de proveedor con una PKI de CA de proveedor de tres niveles:
. /cmpclient --server 127.0.0.1 --port 8080 --path ejbca /publicweb/cmp/vendor --srvcert 3GPPCA.cacert.pem --ir --subject "C=SE,O=Test,CN=Network Element 32" --clcert nevcert.pem --newclcert nev- op -crt.der --newkey nev- op -key.pem --key nevkey.pem --extracert casubnevcert.pem Ejemplo de inscripción de eNodeB
Para ayudar a configurar la inscripción de eNodeB de acuerdo con 3GPP 33.310 , a continuación se proporciona un ejemplo completo de funcionamiento de una configuración EJBCA, así como mensajes de inscripción de eNodeB simulados utilizando OpenSSL v3 (OpenSSL v3 incluye el cliente CMP).
Prerrequisitos
Para completar la configuración de PKI 3GPP y la inscripción de eNodeB, se deben cumplir los siguientes requisitos previos:
Una CA de operador creada en EJBCA
La jerarquía de la CA de operador puede tener uno o dos niveles de profundidad (o incluso más) y puede usar cualquier algoritmo compatible con las capacidades del eNodeB. En el siguiente ejemplo, se crea una CA raíz de operador que emite certificados de entidad final directamente, utilizando una clave EC prime256r1 y SHA256WithECDSA.
Un perfil de certificado y un perfil de entidad final creados en EJBCA para emitir los certificados de eNodeB (entidad final)
El perfil de certificado está configurado para emitir certificados de entidad final compatibles con conexiones de cliente TLS. Esto significa que el uso de clave es adecuado para el tipo de clave (diferente para RSA y EC) y el uso extendido de clave clientAuthentication. Se deben especificar otros campos según lo requiera la política de certificados.
El perfil de entidad final está configurado para permitir que los eNodeB se inscriban con:
CN: Por ejemplo 210305854210K8002536.vendor.com.
OU: Por ejemplo, línea de productos de redes inalámbricas.
O: Por ejemplo Vendedor.
C: Por ejemplo SE.
DnsNames: por ejemplo 210305854210K8002536.vendor.com.
Y debe tener la CA 3GPP configurada y el perfil de certificado seleccionado como CA disponibles.
No seleccione otras CA y perfiles aquí, ya que eso afecta las posibles reglas de acceso necesarias; consulte Uso de una RA externa sobre pares .
El certificado de CA raíz del proveedor del proveedor eNodeB importado en EJBCA
A continuación, se muestra un ejemplo de una jerarquía de CA de proveedor de tres niveles con la CA raíz. El siguiente ejemplo utiliza ECDSA para acortar el certificado al copiar y pegar, pero RSA funciona igual de bien.
Tenga en cuenta que los proveedores no están restringidos a tener solo una CA raíz de proveedor, sino que pueden tener diferentes jerarquías de CA de proveedor para diferentes líneas de productos, por ejemplo, eNodeB vs SecGW.
Aquí está el certificado VendorRootCAEC384.cacert.pem para nuestro ejemplo.
-----BEGIN CERTIFICATE-----MIIB5zCCAY2gAwIBAgIIfIFBpHsapFAwCgYIKoZIzj0EAwMwRzELMAkGA1UEBhMCU0UxGTAXBgNVBAoMEFByaW1lS2V5IEZhY3RvcnkxHTAbBgNVBAMMFFZlbmRvciBSb290IENBIEVDMzg0MB4XDTIwMTAxOTA2MjExMloXDTQwMTAxNDA2MjExMlowRzELMAkGA1UEBhMCU0UxGTAXBgNVBAoMEFByaW1lS2V5IEZhY3RvcnkxHTAbBgNVBAMMFFZlbmRvciBSb290IENBIEVDMzg0MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEPg1gVL60dcs+pI0xqdt+ZxFsi0z0PM/++tXy3CTN1MIL+UL7hjIbHZoKHDydDjvXJh2wNEvR1uby3XIwg0+zVaNjMGEwDwYDVR0TAQH /BAUwAwEB/zAfBgNVHSMEGDAWgBSK0LnIltrD+4XTciuLinXtYpk /yzAdBgNVHQ4EFgQUitC5yJbaw/uF03Iri4p17WKZP8swDgYDVR0PAQH /BAQDAgGGMAoGCCqGSM49BAMDA0gAMEUCIQDsFbCpZbxAtPYrCaNm+8viymtxgW59rrUqbi4GweEqBQIgMvS0OeKVASGAeBIUoI3GBgszzVgjM6MzBjOO586jzSs=-----END CERTIFICATE-----cat > VendorRootCAEC384.cacert.pem En algunos casos, también se debe importar un certificado intermedio (Sub CA) del proveedor, consulte Variaciones .
Alias de CMP
Se debe agregar un alias CMP de acuerdo con lo siguiente:
Nombre: 5GeNodeB (etiqueta de libre elección, pero es parte de la URL utilizada por los eNodeB)
Modo cliente CMP
Módulo de autenticación CMP: EndEntityCertificate
Extraer componente de nombre de usuario: CN
Modo de certificado de proveedor: verdadero
Agregar la CA raíz del proveedor como CA del proveedor
CA predeterminada: 5GCA
Actualización automática de clave: verdadero
Preinscripción de eNodeB
El eNodeB que se autorizará para la inscripción debe agregarse a EJBCA para que este eNodeB específico reciba un certificado de operador y pueda comunicarse en la red del operador. La entidad final puede agregarse mediante la CLI, la interfaz web de RA o la API de WS o REST.
El CN suele coincidir con el número de serie del dispositivo que se va a registrar. Con frecuencia, también se añade un nombre DNS, en caso de que el eNodeB deba actuar como servidor en la comunicación TLS. La contraseña proporcionada en la línea de comandos no es necesaria para la inscripción y puede configurarse con un valor aleatorio o, si no se requiere en el perfil de la entidad final, puede configurarse como "null".
bin /ejbca .sh ra addendentity --username 1234.primekey.com --dn "CN=1234.primekey.com,O=PrimeKey Mobile Operator,C=SE" --altname "DNSName=1234.primekey.com" --caname 5GCA --eeprofile=3GPP --certprofile=3GPP -- type 1 --token USERGENERATED --password ZUhgGPuu-doesnt-matter-randomize 
Operación del eNodoB
Para inscribirse en un certificado de operador, el eNodeB debe enviar los certificados del proveedor, eNodeB y la sub CA, en el campo extraCerts de la solicitud CMP, el certificado del eNodeB debe ser el primero en la cadena de acuerdo con 3GPP 33.310 sección 9.5.4.2.
A continuación, se proporcionan eNodeBVendorKey.pem (clave privada del proveedor del dispositivo), eNodeBVendorCert.pem (certificado del proveedor del dispositivo) y VendorSubCAEC384.cacert.pem (certificado de sub CA del proveedor).
En la terminal eNodeB, cree los archivos de certificado necesarios:
cat > eNodeBVendorKey.pem-----BEGIN PRIVATE KEY-----MIGTAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBHkwdwIBAQQgUmy7YVUMGuemV637Vcq91ZNL9WAnF56fC1dThaGy5T6gCgYIKoZIzj0DAQehRANCAASyrEYCkTX4ApjDR9E36V63cUgkZwD4raKpGMZ6jO2RnfPjtcalGK1sDdlF+GSh9XpLul9GibPiDLIXTen4Un2I-----END PRIVATE KEY-----cat > eNodeBVendorCert.pem-----BEGIN CERTIFICATE-----MIIB2DCCAX2gAwIBAgIIVZHqvoM7h7wwCgYIKoZIzj0EAwMwRTELMAkGA1UEBhMCU0UxGTAXBgNVBAoMEFByaW1lS2V5IEZhY3RvcnkxGzAZBgNVBAMMElZlbmRvciBTdWJDQSBFQzM4NDAeFw0yMDEwMTkwNjIyNTlaFw00MDEwMTQwNjIxMTJaMDwxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhQcmltZUtleTEaMBgGA1UEAwwRMTIzNC5wcmltZWtleS5jb20wWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAASyrEYCkTX4ApjDR9E36V63cUgkZwD4raKpGMZ6jO2RnfPjtcalGK1sDdlF+GSh9XpLul9GibPiDLIXTen4Un2Io2AwXjAMBgNVHRMBAf8EAjAAMB8GA1UdIwQYMBaAFOAbHblwsKqYhl4u5DX9hBpNKAAWMB0GA1UdDgQWBBRln9C8ctMywHZ+Azk4IsZnu0HmXzAOBgNVHQ8BAf8EBAMCB4AwCgYIKoZIzj0EAwMDSQAwRgIhAImjJNNR2LkSWBBmThF3SrhErXtFB5t6T9AZPqRXnuGQAiEAt9RUxTqGc0d4olxtsMU7O /yJ/L2OayUruRjOOZZHLcc =-----END CERTIFICATE-----cat > VendorSubCAEC384.cacert.pem-----BEGIN CERTIFICATE-----MIIB5jCCAYugAwIBAgIIc8lyzz9D+tQwCgYIKoZIzj0EAwMwRzELMAkGA1UEBhMCU0UxGTAXBgNVBAoMEFByaW1lS2V5IEZhY3RvcnkxHTAbBgNVBAMMFFZlbmRvciBSb290IENBIEVDMzg0MB4XDTIwMTAxOTA2MjE0MVoXDTQwMTAxNDA2MjExMlowRTELMAkGA1UEBhMCU0UxGTAXBgNVBAoMEFByaW1lS2V5IEZhY3RvcnkxGzAZBgNVBAMMElZlbmRvciBTdWJDQSBFQzM4NDBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABP4c764FiC2EPqHqkHmRn7OdQoinqWe73yKfBSdTxppnQntMW1oq4kkO1A9qxWgiBN4fnvx /oByN38Pe1Sl0w1yjYzBhMA8GA1UdEwEB/wQFMAMBAf8wHwYDVR0jBBgwFoAUitC5yJbaw /uF03Iri4p17WKZP8swHQYDVR0OBBYEFOAbHblwsKqYhl4u5DX9hBpNKAAWMA4GA1UdDwEB /wQEAwIBhjAKBggqhkjOPQQDAwNJADBGAiEAhWK79GK75Y ++uVLcF6TK2+FWvF0bN820Fwsdmzqsk1ACIQCkwGxvCmZ5RBclq3aWS37wnfucxqeU6efhzZTOTcKwGA==-----END CERTIFICATE-----cat eNodeBVendorCert.pem VendorSubCAEC384.cacert.pem > VendorExtraCerts.pemPara la inscripción inicial, el eNodeB necesita el certificado de la CA del operador, CA 3GPP. Al usar OpenSSL para simulación, lo necesita de antemano, pero al controlar el código en el eNodeB, este puede obtenerlo del campo caCerts de la respuesta CMP. Consulte la documentación del eNodeB para obtener más información.
cat > Operator5GCA.cacert.pem-----BEGIN CERTIFICATE-----MIIB1TCCAXugAwIBAgIUdVQacClwDaymDHvc4Jur3EgSZ7QwCgYIKoZIzj0EAwIwODELMAkGA1UEBhMCU0UxGjAYBgNVBAoMEVByaW1lS2V5IE9wZXJhdG9yMQ0wCwYDVQQDDAQ1R0NBMB4XDTIwMTAxOTA3NDk0NVoXDTMwMTAxNzA3NDk0NVowODELMAkGA1UEBhMCU0UxGjAYBgNVBAoMEVByaW1lS2V5IE9wZXJhdG9yMQ0wCwYDVQQDDAQ1R0NBMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEIv0auwTmMXCfj3nCsVJAIRCUiC55jCLaKwoRu9Pa2S1ugeh66LbAV80A5WGiq+NkzJdr8c9lE /Hyz2W/KldoCKNjMGEwDwYDVR0TAQH /BAUwAwEB/zAfBgNVHSMEGDAWgBQC57BXQLTWiCCPlaDY5QBA1dpC7jAdBgNVHQ4EFgQUAuewV0C01oggj5Wg2OUAQNXaQu4wDgYDVR0PAQH /BAQDAgGGMAoGCCqGSM49BAMCA0gAMEUCIC7J67 /LLFW65QD5W1WP/SLD2ZhUVUTV2 ++k31gbEYvwAiEA95pLBSW9gRD2zHVve6WCGO0JNq+AGWdHqUynR9SMVtE=-----END CERTIFICATE-----El eNodeB genera un nuevo par de claves para emitir en la solicitud inicial de CMP.
openssl ecparam -name prime256v1 -genkey -noout -out eNodeBOperatorKey.pemRealice la solicitud a la CA (con nombre de host ejbca.example.com) y reciba el certificado de operador emitido:
openssl cmp -cmd ir -server ejbca.example.com:8080 -path ejbca /publicweb/cmp/5GeNodeB \-cert eNodeBVendorCert.pem -key eNodeBVendorKey.pem -certout eNodeBOperatorCert.pem -newkey eNodeBOperatorKey.pem \-subject "/CN=1234.primekey.com/O=PrimeKey Mobile Operator/C=SE" sans "DNS=1234.primekey.com" -extracerts VendorExtraCerts.pem -srvcert Operator5GCA.cacert.pem -trusted Operator5GCA.cacert.pem \-implicit_confirmSe muestra una salida de línea de comando similar a la siguiente cuando el eNodeB (simulado) almacena el certificado del operador.
user@host:~/cmp$ openssl cmp -cmd ir -server ejbca.example.com:8080 -path ejbca/publicweb/cmp/5GeNodeB -cert eNodeBVendorCert.pem -key eNodeBVendorKey.pem -certout eNodeBOperatorCert.pem -newkey eNodeBOperatorKey.pem -subject "/CN=1234.primekey.com/O=PrimeKey Mobile Operator/C=SE" -extracerts VendorExtraCerts.pem -svrcert Operator5GCA.cacert.pem -srvcert Operator5GCA.cacert.pem -trusted Operator5GCA.cacert.pem -implicit_confirmsetup_client_ctx:apps/cmp.c:1980:CMP info: will contact http://ejbca.example.com:8080/ejbca/publicweb/cmp/5GeNodeBCMP info: sending IRCMP info: received IPsave_free_certs:apps/cmp.c:2029:CMP info: received 1 enrolled certificate(s), saving to file 'eNodeBOperatorCert.pem' Puede especificar diferentes altNames mediante la opción -sans , pero a menos que se especifiquen opciones de anulación en el perfil del certificado, estas se ignoran y solo se utilizan los valores registrados en la entidad final de EJBCA. Por razones de seguridad, los valores enviados desde el cliente no son de confianza por defecto.
Renovación
Al renovar el certificado de operador del eNodoB, este genera un nuevo par de claves y emite una solicitud de renovación de CMP, firmada con el certificado de operador anterior. En este caso, el certificado de operador anterior y el certificado de la sub-CA del operador se utilizan como extraCerts (véase la sección "TODO" de 3GPP). Dado que la CA raíz del operador nos firma directamente, solo necesitamos incluir el certificado TLS anterior en extraCerts; el servidor ya confía en la CA raíz.
openssl ecparam -name prime256v1 -genkey -noout -out eNodeBOperatorKey-new.pemAl renovar el certificado, el eNodeB (simulado) envía una solicitud CMP KeyUpdate, firmada con la clave del operador y el certificado anteriores.
openssl cmp -cmd kur -server ejbca.example.com:8080 -path ejbca /publicweb/cmp/5GeNodeB \-cert eNodeBOperatorCert.pem -key eNodeBOperatorKey.pem -certout eNodeBOperatorCert-new.pem -newkey eNodeBOperatorKey-new.pem \-extracerts eNodeBOperatorCert.pem -trusted Operator5GCA.cacert.pem \-implicit_confirmEsto debería generar un resultado similar a este en la línea de comando, cuando el eNodeB (simulado) almacena el certificado del operador.
user@host:~/cmp$ openssl cmp -cmd kur -server ejbca.example.com:8080 -path ejbca/publicweb/cmp/5GeNodeB -cert eNodeBOperatorCert.pem -key eNodeBOperatorKey.pem -certout eNodeBOperatorCert-new.pem -newkey eNodeBOperatorKey-new.pem -extracerts eNodeBOperatorCert.pem -trusted Operator5GCA.cacert.pem -implicit_confirmsetup_client_ctx:apps/cmp.c:1980:CMP info: will contact http://ejbca.example.com:8080/ejbca/publicweb/cmp/5GeNodeBCMP info: sending KURCMP info: received KUPsave_free_certs:apps/cmp.c:2029:CMP info: received 1 enrolled certificate(s), saving to file 'eNodeBOperatorCert-new.pem' Ni CMP (RFC4210) ni 3GPP 33.310 establecen horarios específicos para la actualización de claves. Por lo tanto, un eNodoB puede enviar una Solicitud de Actualización de Clave (kur) en cualquier momento, siempre que esté autenticado con el certificado o la clave antiguos.
Confirmación implícita
Los ejemplos anteriores utilizan la opción Implicit_confirm, que permite al cliente (eNodeB) obtener el certificado del operador sin enviar un mensaje de confirmación CMP a la CA. Independientemente de si el eNodeB utiliza implicit_confirm o no, EJCBA responderá correctamente. Por lo tanto, es importante proporcionar el parámetro -srvcert del comando openssl, ya que, de lo contrario, el mensaje CertConf se dirigirá a la CA incorrecta.
Uso de un RA externo sobre pares
Al usar una RA externa frente a EJBCA, con conectores de pares de la CA, el certificado de conexión de pares de la RA limita las capacidades de la RA mediante roles y reglas de acceso. Para completar la inscripción de certificados de eNodeB a través de una conexión de pares, el rol de conectores de pares debe incluir reglas de acceso para:
Operador emisor de CA
Perfiles de entidad final emisora
Las CA de proveedores se agregaron como CA externas en EJBCA
Si faltan reglas de acceso, obtendrá entradas de registro como la siguiente en el registro de CA:
2020-10-15 13:05:55,593 INFO[org.cesecore.authorization.AuthorizationSessionBean] (EJB default -34) Authorization failed for 10.11.96.4 [via] CN=primepki-peer1,C=SE of type AlwaysAllowLocalAuthenticationToken for resource/ca/1471073378 A partir de EJBCA 7.4.3, no se puede agregar una CA externa mediante la configuración de reglas de acceso simple en Sistemas Pares > Solicitud Autorizada , sino que debe agregarse al rol en las reglas de acceso del Modo Avanzado. Existe un riesgo al usar el botón " Solicitud Autorizada " para eliminar las reglas de acceso avanzadas, por lo que este botón no se puede usar hasta que se puedan agregar CA externas en este modo de configuración simplificado.
Variaciones descubiertas
Jerarquías de CA de proveedores en extraCerts
Las jerarquías de CA de proveedor pueden ser de dos o tres niveles, es decir, CA raíz → ID de dispositivo o CA raíz → Sub CA → ID de dispositivo. La sección 9.5.4.2 de 3GPP 33.310 establece que, en una jerarquía de tres niveles, el certificado de la estación base y el certificado intermedio deben incluirse en el campo extraCerts de la solicitud CMP. Si bien esto se estipula en el estándar, existen algunas variaciones.
Fortinet SecGW solo incluye el certificado de entidad final en el campo extraCerts de la solicitud. Esto significa que la subautoridad de certificación del proveedor debe agregarse como tal en el alias de CMP para verificar la cadena de certificados de entidad final.
Esto significa que tanto la CA raíz del proveedor como la CA secundaria del proveedor deben importarse en EJBCA como CA externas, y solo la CA secundaria debe agregarse como CA del proveedor en el alias de CMP.Los eNodeB de Huawei también incluyen el certificado de la CA raíz, así como los certificados de la entidad final y de la subCA, en el campo extraCerts de la solicitud. El certificado de la CA raíz es redundante, pero funciona bien al configurar la CA raíz como CA del proveedor en el alias CMP (ya que el certificado de la CA raíz puede verificarse mediante el certificado de la CA raíz).
Esto significa que solo la CA raíz del proveedor debe importarse en EJBCA como CA externa, y solo la CA raíz del proveedor debe agregarse como CA del proveedor en el alias de CMP.Ericsson utiliza una jerarquía de cuatro niveles y los envía todos en el campo extraCerts. Esto funciona (a partir de EJBCA 7.4.3.2) por la misma razón que la anterior.
Esto significa que solo la CA raíz del proveedor debe importarse en EJBCA como CA externa, y solo la CA raíz del proveedor debe agregarse como CA del proveedor en el alias CMP en EJBCA.
Si tiene una CA operadora con una CA raíz y una CA secundaria, en la BBU (unidad de banda base) configure el DN del sujeto de la CA secundaria como enrollmentAuthorityName (destinatario de CMP y emisor del certificado de entidad final) y la huella digital de la CA raíz (SHA-1) como enrollmentCaFingerprint (ancla de confianza).
La configuración de enrollmentAuthorityName en la BBU debe coincidir con la forma en que el cliente PKI interno muestra el DN, que suele contener espacios, por ejemplo: "CN = ranCA,OU = RAN,O = PrimeKey,C = SE". Si este formato no es correcto, la BBU mostrará el error "No se encontró un certificado RA válido".
Nombre común de los certificados de operador emitidos
El CN del certificado de proveedor del eNodoB puede ser, por ejemplo, 210305854210K8002536.vendor.com, pero el CN deseado del certificado del eNodoB emitido por el operador es solo 210305854210K8002536. Esto se puede lograr prerregistrando la entidad final con el CN 210305854210K8002536, pero estableciendo el nombre de usuario de la entidad final en 210305854210K8002536.vendor.com. Cuando llega una solicitud de registro, la entidad final se busca según el subjecDN completo de la solicitud (que coincide con el nombre deseado por los operadores) y, por lo tanto, se encuentra el nombre de usuario independientemente de si coincide con este CN o no. Sin embargo, al verificar el certificado del proveedor, el nombre de usuario se asigna desde el CN en el certificado del proveedor y, por lo tanto, el nombre de usuario coincide con el CN del certificado del proveedor.
Se pueden usar otros campos además del CN para hacer coincidir un certificado de proveedor con un nombre de usuario de entidad final, pero el uso de CN es el más común y el que se utiliza en este ejemplo.
Lista de proveedores
Constantemente se lanzan nuevos dispositivos al mercado, que los operadores prueban continuamente con EJBCA. A modo de ejemplo, la gama de proveedores y dispositivos probados incluye una pequeña lista de dispositivos utilizados en redes a mediados de 2020 (esta lista no se actualiza continuamente, sino que es un resumen):
Airspan AirHarmony 1000 ENB (CMP)
Airvana/Commscope OneCell (CMP)
Alcatel Lucent 9412 (CMP)
Enrutadores Cisco de la serie 7600 con SAMI (CMP)
Ericsson RBS6000 (SCEP)
Ericsson RBS6201 (CMP)
Banda base Ericsson 6630/6648 BBU (CMP)
Firewall de próxima generación Fortinet Fortigate (SCEP, CMP)
Huawei ENB (CMP) (por ejemplo, versión SRAN 17.1 y 18.1 verificada en 2022)
Huawei Femtocell BTS3202H, 3202E (CMP)
Juniper SRX (SCEP)
NEC eNB.
Nokia Networks ENB (CMP) (por ejemplo, versión SRAN 21A verificada en 2022)
Nokia Networks Flexi Zone micro (CMP)
Puerta de enlace de seguridad Casa y unidades gNodeB/CBSD Airspan (4G y 5G)
Temas relacionados
Para preguntas y respuestas sobre el uso según 3GPP 33.310, consulte Preguntas y respuestas de 3GPP CMP .