¿Qué es una RSE?

Una solicitud de firma de certificado (CSR) es un archivo que genera un cliente o un dispositivo, que contiene su clave pública e información identificativa, como el nombre común y los nombres alternativos del sujeto, y que se envía a una autoridad de certificación. La autoridad de certificación verifica la solicitud y devuelve un certificado digital firmado que el solicitante puede instalar.

Puntos clave

• Un CSR contiene la clave pública y los campos de identidad de un dispositivo, pero nunca su clave privada.
• El dispositivo firma el CSR con su clave privada para demostrar que posee el par.
• La CA verifica la solicitud y devuelve un certificado digital firmado.
• Los certificados CSR pueden generarse manualmente o de forma automatizada mediante SCEP, CMP o ACME.
• Versa Director, Concerto y VMS generan y envían solicitudes de certificado (CSR) a una autoridad de certificación (CA).

En esta página: Por qué es importante · Cómo funciona · Tipos · RSE y Versa · Preguntas frecuentes

¿Por qué es importante la RSE?

Una CSR es el punto de partida de casi todas las relaciones de confianza basadas en una infraestructura de clave pública (PKI). Para que dos sistemas puedan autenticarse mutuamente a través de TLS, TLS mutuo o IPsec con autenticación basada en certificados, una de las partes necesita un certificado firmado por una autoridad de certificación de confianza, y una CSR es el punto de partida de ese proceso. Generar la CSR en el dispositivo solicitante, en lugar de que sea la CA la que genere el par de claves, significa que la clave privada nunca sale del dispositivo que la va a utilizar, lo que mantiene la parte sensible del par de claves totalmente fuera del tránsito.

Los CSR también son importantes desde el punto de vista operativo, ya que la emisión de certificados debe poder ampliarse a miles de dispositivos, servidores y servicios sin convertirse en un cuello de botella manual. Los protocolos de inscripción automatizada se basan directamente en el formato CSR, de modo que un dispositivo puede solicitar, renovar y sustituir certificados de forma programada, en lugar de tener que esperar a un ciclo manual de exportación e importación. Introducir correctamente los campos de identidad —nombre común, nombres alternativos del sujeto, período de validez— también determina si los clientes TLS confiarán realmente en el certificado resultante, ya que las validaciones modernas comprueban la lista SAN, no solo el nombre común.

¿Qué es una RSE?

Un CSR es un archivo con formato PKCS#10 que se crea en tres pasos. En primer lugar, el cliente o dispositivo solicitante genera localmente un par de claves pública y privada. En segundo lugar, elabora el cuerpo de la solicitud: la clave pública, un nombre distinguido que identifica al solicitante (país, estado, localidad, organización, unidad organizativa y —lo más importante— un nombre común), además de, por lo general, uno o más nombres alternativos del sujeto que abarquen todos los nombres de host o direcciones IP para los que el certificado debe ser válido. En tercer lugar, el dispositivo firma toda la solicitud con su propia clave privada, lo que demuestra a la CA que el solicitante posee realmente la clave privada que coincide con la clave pública de la solicitud, sin enviar en ningún momento dicha clave privada a ningún sitio.

A continuación, la CSR firmada se envía a una autoridad de certificación —ya sea directamente, mediante un proceso manual, o de forma automática, a través de un protocolo de inscripción como SCEP, CMP o ACME—. La autoridad de certificación valida la identidad del solicitante según su propia política y, a continuación, emite un certificado firmado que vincula la clave pública a la identidad solicitada. El solicitante instala ese certificado junto con la clave privada que ya posee, y la propia CSR se descarta.

Tipos de RSE

La forma en que se genera y se envía un CSR varía según la implementación. Generación manual/mediante la interfaz de línea de comandos (CLI) utiliza una herramienta de línea de comandos —OpenSSL— o un script del proveedor, como el de VMS vsh generate-server-csr – generar el par de claves y la CSR de forma interactiva, de modo que un administrador introduzca los campos de identidad y copie el archivo resultante a una CA para su firma. Generación impulsada por Orchestrator Se lleva a cabo a través de una interfaz de usuario de gestión: un administrador rellena los campos de la solicitud de certificado (nombre común, correo electrónico, país, validez y tamaño de la clave) en un flujo de trabajo, y la plataforma genera y envía la solicitud como parte del proceso de incorporación de un dispositivo o un inquilino. Inscripción automatizada mediante protocolo elimina por completo el paso manual: los clientes SCEP, CMP o ACME generan la CSR, la envían automáticamente a un servidor de la CA y se encargan de la renovación antes de que caduque el certificado, el modelo que utilizan la mayoría de las grandes flotas para evitar interrupciones por la caducidad de los certificados.

Una CSR también puede estar dirigida a una autoridad autofirmada —útil para laboratorios y pruebas internas— o a una autoridad firmada por una CA (tercera parte) para cualquier cosa que deba gozar de una confianza generalizada. Los campos que contiene la CSR son los mismos en ambos casos; solo difiere la raíz de confianza.

RSE y Versa

Versa utiliza los CSR en dos capas de la plataforma. En Versa Servicio de mensajería, el vsh generate-server-csr El comando genera un CSR en el nodo principal, solicitando entre cinco y siete nombres alternativos del sujeto que abarquen las interfaces de gestión, elástica y de comunicación hacia el sur, además de la organización y el nombre común; el resultado es server-csr.pem se envía a una autoridad de certificación de confianza para su firma y, a continuación, vuelve a través de vsh import-ca-certs. Implementaciones de HA VMS En su lugar, genera localmente una CA raíz autofirmada y una cadena de CSR con el vms_cert_gen.sh script, que genera certificados raíz, de servidor y de cliente para el clúster.

En lo que respecta a « Secure SD-WAN », la configuración de los inquilinos en Concerto gestiona la generación de CSR íntegramente a través de los campos del flujo de trabajo: un administrador selecciona un tipo de servidor de CA (ACME, CMP o SCEP) y, a continuación, rellena las opciones de la CSR, como el nombre común, la clave compartida, la validez y el tamaño de la clave privada por controlador. Concerto convierte esas entradas en datos de enlace de CSR que los dispositivos envían automáticamente al publicarse, por lo que la autenticación de inquilinos basada en certificados no requiere en absoluto acceder al shell de un dispositivo.

Preguntas frecuentes

¿Qué información contiene un informe de responsabilidad social corporativa (RSC)?

Un CSR contiene la clave pública del solicitante y un nombre distinguido: nombre común y, por lo general, organización, localidad, provincia, país y uno o más nombres alternativos del sujeto. Se firma con la clave privada del solicitante para demostrar su propiedad, pero la clave privada en sí nunca se incluye en el archivo.

¿Incluye un CSR una clave privada?

No. Un CSR incluye únicamente la clave pública del par de claves; la clave privada permanece en el dispositivo solicitante y se utiliza únicamente para firmar la solicitud, lo que demuestra que el dispositivo la posee, sin transmitirla en ningún momento a la CA ni a ningún otro lugar.

¿Cuál es la diferencia entre el «nombre común» y el «nombre alternativo del sujeto» en una CSR?

El «Nombre común» es el campo de identidad único tradicional, que históricamente correspondía al nombre de host. El «Nombre alternativo del sujeto» (SAN) es una extensión más reciente que enumera todos los nombres de host, direcciones IP o identidades que debe cubrir el certificado. Los clientes TLS modernos realizan la validación basándose en la lista SAN, por lo que la mayoría de las solicitudes de certificado (CSR) actuales rellenan ambos campos.

¿Qué relación hay entre un CSR y el SCEP, el CMP y el ACME?

SCEP, CMP y ACME son protocolos de registro que automatizan las tareas que se realizan manualmente en un flujo de trabajo de CSR: generar la CSR, enviarla a una autoridad de certificación (CA) y recuperar el certificado firmado. Los dispositivos « Versa » pueden utilizar cualquiera de estos tipos de servidor en lugar de un archivo CSR copiado manualmente.

¿Se puede reutilizar una CSR para varios certificados?

Normalmente, una solicitud de certificado (CSR) se envía una sola vez y la utiliza la autoridad de certificación (CA) que la firma. Para solicitar un certificado renovado o reemitido —o para modificar campos de identidad, como las entradas SAN—, el solicitante genera una nueva CSR en lugar de volver a enviar la original.

Más información sobre la RSE

Si quieres saber más, estas son algunas fuentes en las que confiamos.

Términos relacionados

Si estás leyendo sobre la RSE, te recomiendo que eches un vistazo a lo siguiente.