Cómo generar un CSR para un certificado de firma de código

Un certificado de firma de código demuestra quién publicó un software y prueba que el código no se ha modificado desde que fue firmado. Para solicitarlo, se crea una CSR (Certificate Signing Request), el bloque de texto codificado que la Autoridad de Certificación (CA) utiliza para identificarlo y emitir el certificado. Las CSR de firma de código siguen reglas distintas a las que se crean para un sitio web, y esas reglas cambiaron en 2023. Esta guía explica el proceso actual y los métodos que todavía aplican.

La clave privada debe residir en hardware

Desde el 1 de junio de 2023, los Requisitos Base de Firma de Código del CA/Browser Forum exigen que la clave privada de todo certificado de firma de código de confianza pública se genere y almacene en hardware que cumpla con FIPS 140-2 Nivel 2, Common Criteria EAL4+, o un estándar equivalente. Esto aplica tanto a los certificados estándar (Validación de Organización y Validación Individual) como a los certificados de Validación Extendida (EV). La firma de código EV ya exigía hardware antes de esta fecha; el cambio de 2023 extendió la misma regla a los certificados estándar.

La consecuencia práctica es importante: una clave privada y una CSR generadas exclusivamente en software, en un navegador, o en un archivo común en una laptop o servidor, ya no se aceptan para un certificado de firma de código de confianza pública. Las CA han dejado de admitir la generación de claves basada en navegador y la entrega descargable en .pfx para estos productos. La clave debe originarse, y permanecer, en un dispositivo compatible. Esto deja dos rutas válidas:

• Un token de hardware preconfigurado por la CA. La CA genera el par de claves y la CSR directamente en un token USB certificado, instala en él el certificado emitido, y le envía el token. Usted firma con el token conectado. Con este método, usted mismo no genera la CSR.
• Su propio HSM o HSM en la nube, con atestación de clave. Si ya cuenta con un Módulo de Seguridad de Hardware (HSM) compatible (o un HSM en la nube como AWS CloudHSM, Azure Dedicated HSM o Google Cloud HSM), usted genera la clave y la CSR en ese dispositivo y proporciona un archivo de atestación que demuestra a la CA que la clave se creó en, y no puede exportarse desde, hardware compatible.

La ruta que siga se define al momento de realizar el pedido. Para una comparación lado a lado, consulte los métodos de entrega del certificado de firma de código.

Opción 1: token más envío (la CA crea la CSR)

Esta es la ruta que eligen la mayoría de las personas y los equipos pequeños, porque no necesita hardware propio. Al seleccionar token más envío al momento de la compra, la CA se encarga de generar la clave y crear la CSR en un token certificado de su lado, y luego le envía por correo el token con el certificado ya cargado. No hay ninguna CSR que usted deba pegar en un formulario de pedido.

Lo que debe hacer en su lugar:

• Completar los pasos de validación que solicite la CA (verificación de organización o de identidad).
• Esperar a que llegue el token físico.
• Instalar los controladores del token (comúnmente SafeNet Authentication Client) y firmar su software con el token conectado.

Opción 2: generar la CSR en su propio HSM o token

Si ya cuenta con hardware compatible, usted genera el par de claves y la CSR en ese dispositivo y proporciona la atestación correspondiente. Los pasos exactos dependen del hardware, así que siga la guía de su dispositivo o la documentación de su proveedor:

• YubiKey 5 FIPS: generación de CSR y atestación
• Luna Network Attached HSM v7.x: guía de CSR y atestación

Para HSM en la nube (AWS CloudHSM, Azure Dedicated HSM, Google Cloud HSM), genere la clave dentro del HSM, exporte la CSR y el archivo de atestación que produce la plataforma, y envíe ambos a su CA durante el pedido.

Algunos detalles aplican en todas las CSR respaldadas por hardware:

• Use una clave RSA de al menos 3072 bits, o una clave ECDSA equivalente, según especifican los Requisitos Base.
• Marque la clave como no exportable para que no pueda salir del dispositivo.
• Genere la atestación al mismo tiempo que la clave. Una CSR sin atestación válida será rechazada.

Dónde encajan ahora los métodos OpenSSL, Java Keytool, MMC, CertReq y Keychain

Es posible que haya visto instrucciones antiguas que crean una CSR de firma de código con OpenSSL, la utilidad keytool de Java, la Consola de Administración de Microsoft (MMC), el comando certreq de Windows, o Acceso a Llaveros en macOS. Por sí solas, estas herramientas generan una clave en software, por lo que una CSR producida de esa manera no es válida hoy para un certificado de firma de código de confianza pública.

Aun así, siguen teniendo un lugar cuando se dirigen hacia hardware compatible en lugar de un almacén de claves de software. Por ejemplo, OpenSSL puede crear una CSR contra un HSM a través de un módulo PKCS#11, y CertReq o MMC pueden construir una solicitud que use un proveedor de almacenamiento de claves de hardware. Use estas referencias solo en ese contexto, y siempre acompañe la solicitud con la atestación del dispositivo:

• Generar una CSR de firma de código con OpenSSL
• Generar una CSR de firma de código con Java Keystore
• Generar una CSR de firma de código con CertReq
• Generar una CSR de firma de código con la Consola de Administración de Microsoft
• Generar una CSR de firma de código con Acceso a Llaveros de macOS

Verifique el contenido de su CSR

Antes de enviar una CSR, confirme que los datos del sujeto sean correctos. Si dispone de OpenSSL, decodifique la solicitud localmente y léala en texto plano:

openssl req -noout -text -in codesigning.csr

Revise la organización o el nombre común y el tamaño de la clave en el resultado. Un verificador estándar de CSR para sitios web no es la herramienta adecuada aquí, porque una CSR de firma de código está vinculada al hardware y se valida mediante atestación en lugar de un escaneo público de HTTPS.

Preguntas frecuentes