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

El complemento Certificados en Microsoft Management Console (MMC) puede crear una solicitud de certificado PKCS #10 en un equipo Windows sin necesidad de software adicional. Esta guía recorre ese asistente pantalla por pantalla para un certificado de firma de código, y comienza con la parte que la mayoría de las instrucciones antiguas omiten: las reglas para las claves privadas de firma de código cambiaron el 1 de junio de 2023, y son ellas las que determinan si una solicitud de MMC puede usarse en absoluto.

Lea ese requisito antes de abrir el asistente. El resto de la guía asume que ya sabe qué ruta seguirá su pedido.

Las claves de firma de código deben generarse en hardware

Según los requisitos de referencia de firma de código del CA/Browser Forum, vigentes desde el 1 de junio de 2023, la clave privada de todo certificado de firma de código de confianza pública debe generarse, almacenarse y usarse en un módulo criptográfico de hardware certificado, como mínimo, con FIPS 140-2 Nivel 2, Common Criteria EAL 4+, o un estándar equivalente. Esto abarca tanto los certificados estándar (Validación de Organización y Validación Individual) como los de Validación Extendida. La firma de código EV ya funcionaba así; el cambio de 2023 extendió la misma regla a los productos estándar.

Los requisitos también fijan la clave en sí. Las claves RSA deben tener al menos 3072 bits, las claves ECDSA deben usar NIST P-256, P-384 o P-521, y SHA-1 no está permitido para certificados de firma de código.

Igual de importante, la Autoridad de Certificación debe demostrar que la clave realmente está en hardware, usando uno de los métodos que enumeran los requisitos. En la práctica, estos son los que se encontrará:

• La CA le envía un token de hardware que ya contiene un par de claves que la CA generó en ese dispositivo.
• Usted firma conjuntamente la solicitud con un certificado del fabricante, que es lo que significa la atestación de clave: la prueba de que la clave se creó de forma no exportable dentro de un dispositivo conforme.
• Usa una combinación de biblioteca criptográfica y módulo de hardware que la CA prescribe.
• Aporta una auditoría de TI, un informe de un servicio de protección de claves en la nube, o un acuerdo que firma a través de un servicio de firma conforme.

Ninguna de esas condiciones se cumple con una solicitud que MMC crea contra el Microsoft Software Key Storage Provider. Ese proveedor crea la clave en el almacenamiento de software de Windows, por lo que la solicitud resultante será rechazada para un certificado de firma de código de confianza pública, sin importar cómo se complete el resto del asistente. Las Autoridades de Certificación también dejaron de ofrecer, al mismo tiempo, la generación de claves basada en navegador y la entrega descargable en .pfx para estos productos.

Si su objetivo es un certificado de confianza pública, la ruta se decide en el momento del pedido. O bien la CA genera la clave en un token y se la envía por correo, en cuyo caso no hay CSR que usted deba crear, o bien usted genera la clave en un hardware que ya posee y envía una atestación junto con la solicitud. La guía de métodos de entrega del certificado de firma de código compara ambas opciones, y los pasos específicos de cada dispositivo están aquí:

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

Dónde sigue encajando MMC

El asistente no está obsoleto. Es el proveedor que usted elige dentro de él lo que decide dónde nace la clave, y hay tres situaciones en las que sigue siendo la herramienta correcta.

Una solicitud respaldada por un proveedor de hardware. La lista Cryptographic Service Provider del asistente muestra todos los proveedores instalados en el equipo, no solo los de software de Microsoft. Una vez instalado el controlador de un token o el minicontrolador de una tarjeta inteligente, su proveedor también aparece allí. La diferencia está en dónde nace el par de claves: un proveedor de software lo genera en su equipo, mientras que un proveedor basado en hardware, como una tarjeta inteligente o un proveedor de token, indica al dispositivo que genere el par, y luego el dispositivo conserva la clave privada y controla el acceso a ella. Seleccione un proveedor de hardware y MMC producirá una solicitud para una clave que nunca existió en software.

Dos advertencias antes de confiar en eso. MMC produce una solicitud PKCS #10 y nada más, por lo que no genera el archivo de atestación de clave que la mayoría de las Autoridades de Certificación exigen junto con ella. Eso proviene de las herramientas propias del dispositivo. Y la CA decide qué método de verificación aceptará, y muchas prescriben su propia utilidad para esa tarea. Pregunte a su CA qué ruta admite antes de generar nada, porque una clave creada con la herramienta equivocada no se puede trasladar después.

Una CA interna o empresarial. Los requisitos de referencia rigen los certificados de confianza pública. Un certificado emitido por su propia CA de Active Directory Certificate Services para firma interna queda fuera de ese alcance, por lo que su propia política decide cómo se almacena la clave, y un proveedor de software es una opción legítima. Recuerde lo que obtiene: el código firmado de esta manera solo es de confianza en los equipos que ya confían en su raíz interna, y en cualquier otro lugar Windows seguirá tratando al editor como desconocido.

Firma de prueba y preparación. Una solicitud de software es adecuada para un certificado de prueba, y también para determinar los valores exactos del sujeto que reutilizará cuando genere la solicitud real contra su hardware.

Paso 1: Abrir el complemento Certificados

Pulse la tecla Windows + R, escriba mmc y presione Intro. También puede escribir mmc en el cuadro de búsqueda de la barra de tareas y abrirlo desde allí. Acepte el aviso de Control de cuentas de usuario. Se abrirá una ventana Consola1 vacía.

Haga clic en Archivo, luego en Agregar o quitar complemento. En la lista Complementos disponibles, seleccione Certificados y haga clic en Agregar.

Windows pregunta ahora qué almacén de certificados debe administrar el complemento: Mi cuenta de usuario, Cuenta de servicio o Cuenta de equipo. Esta elección importa más para un certificado de firma de código que para un certificado de servidor web, porque decide dónde reside la clave y en qué almacén busca su herramienta de firma:

• Mi cuenta de usuario coloca la clave en el almacén personal del usuario que ha iniciado sesión. Esta es la opción habitual cuando un desarrollador firma de forma interactiva, porque la herramienta signtool de Microsoft abre por defecto el almacén My del usuario actual.
• Cuenta de equipo coloca la clave en el almacén del equipo, lo cual conviene a un servidor de compilación donde la firma se ejecuta bajo una cuenta de servicio. Hay que indicar a las herramientas de firma que busquen allí: signtool utiliza el modificador /sm para el almacén del equipo.

Si elige Mi cuenta de usuario, haga clic en Finalizar. Si elige Cuenta de equipo, haga clic en Siguiente, deje seleccionado Equipo local (el equipo en el que se está ejecutando esta consola) y haga clic en Finalizar. En cualquier caso, haga clic en Aceptar para cerrar la ventana Agregar o quitar complementos.

Dos atajos evitan por completo el paso del complemento cuando no necesita una consola guardada: certmgr.msc abre directamente los almacenes de certificados del usuario actual, y certlm.msc abre los almacenes del equipo local. Si creó la consola manualmente y prevé volver a usarla, utilice Archivo y luego Guardar para conservarla.

Paso 2: Iniciar una solicitud personalizada

En el árbol de la consola, expanda Certificados y haga clic con el botón derecho en la carpeta Personal (o en la carpeta Certificados que está debajo, si el almacén ya contiene certificados). Elija Todas las tareas, luego Operaciones avanzadas, y después Crear solicitud personalizada. Los mismos comandos están en el menú Acción si lo prefiere.

Se abre el asistente Inscripción de certificados en la pantalla Antes de comenzar. Haga clic en Siguiente.

En Seleccionar directiva de inscripción de certificados, busque bajo el encabezado Solicitud personalizada y seleccione Continuar sin directiva de inscripción, luego haga clic en Siguiente. Esto le indica a Windows que cree una solicitud independiente para una CA externa en lugar de inscribirse contra una plantilla de Active Directory.

La página Solicitud personalizada tiene tres opciones:

• Plantilla. Elija (Sin plantilla) Clave CNG. Esto usa un proveedor de almacenamiento de claves (Key Storage Provider), que es como se registran los proveedores de hardware modernos. (Sin plantilla) Clave heredada usa los proveedores CryptoAPI más antiguos y solo se necesita cuando un dispositivo o aplicación específico lo requiere.
• Suprimir extensiones predeterminadas. Déjelo desmarcado, a menos que quiera enviar únicamente las extensiones que configura manualmente.
• Formato de la solicitud. Seleccione PKCS #10. Todas las CA lo aceptan. CMC se usa para solicitudes dirigidas a sistemas que lo exigen específicamente.

Haga clic en Siguiente. En la página Información del certificado verá una sola fila con la etiqueta Solicitud personalizada y un estado Disponible. Haga clic en la flecha Detalles a la derecha de esa fila para expandirla, y luego haga clic en el botón Propiedades que aparece. Se abre el cuadro de diálogo Propiedades del certificado con cuatro pestañas: General, Sujeto, Extensiones y Clave privada.

Paso 3: Introducir los detalles del sujeto

En la pestaña General, escriba un Nombre descriptivo y, si lo desea, una Descripción. Ambos son etiquetas locales que le ayudan a encontrar el certificado en el almacén más adelante. Ninguna de las dos forma parte de la solicitud, ni se valida.

Cambie a la pestaña Sujeto. Aquí se ensambla la identidad que aparecerá como el editor del software. En Nombre del sujeto, elija una entrada en el menú desplegable Tipo, escriba el texto correspondiente en el cuadro Valor, y haga clic en Agregar >. Cada entrada se traslada a la lista de la derecha, donde Windows la muestra en forma abreviada (CN=, O=, OU=, L=, S=, C=). Repita para cada uno de los siguientes:

• Nombre común (CN): el nombre registrado de su organización, o el nombre legal completo de la persona en el caso de un certificado individual. Es la identidad que ven los usuarios cuando Windows nombra al editor.
• Organización (O): el nombre registrado de la organización a la que pertenece el certificado. Si el nombre contiene un símbolo como el ampersand, escríbalo con letras o elimínelo, ya que estos caracteres no se aceptan en el campo. «AB & C Corporation» se convierte en «AB and C Corporation» o «ABC Corporation».
• Unidad organizativa (OU): el departamento que gestiona la inscripción, por ejemplo IT. Opcional.
• Localidad (L): la ciudad donde está registrada la organización.
• Estado (S): el estado o provincia, escrito de forma completa. Use Florida, no FL.
• País (C): el código ISO de dos letras del país donde está registrada la organización, por ejemplo US.

Introduzca datos que coincidan exactamente con sus registros legales, porque la CA los valida contra fuentes públicas y oficiales antes de emitir nada. Una discrepancia es la razón más común por la que un pedido de firma de código se detiene.

Deje vacío el cuadro Nombre alternativo. Los nombres alternativos del sujeto identifican servidores por nombre de host, y un certificado de firma de código identifica a un editor en lugar de un equipo, por lo que no lleva entradas DNS.

Paso 4: Elegir el proveedor, el tamaño de clave y el hash

Abra la pestaña Clave privada. Contiene varios grupos desplegables: Proveedor de servicios criptográficos, Opciones de claves, Seleccionar algoritmo de hash, Seleccionar formato de firma y Permisos de la clave. Haga clic en un encabezado para expandirlo.

Expanda primero Proveedor de servicios criptográficos, porque este es el ajuste que activan los requisitos de referencia. La lista muestra todos los proveedores instalados en el equipo, cada uno con una casilla de verificación. Asegúrese de que la única marcada sea el proveedor que realmente desea:

• Para un certificado de firma de código de confianza pública, seleccione el proveedor que pertenece a su token o HSM. Solo aparece en esta lista después de instalar el controlador o minicontrolador del dispositivo, así que conecte el dispositivo e instale su software primero.
• RSA, Microsoft Software Key Storage Provider es la opción de software. Úsela solo para una CA interna o un certificado de prueba.
• La lista también incluye entradas ECDSA como ECDSA_P256, Microsoft Software Key Storage Provider. Confirme que su CA admite ECDSA para firma de código antes de elegir una, porque no todos los productos lo hacen.

Expanda Opciones de claves. Configure Tamaño de clave en 3072 o 4096. RSA 3072 es el mínimo para firma de código, y una solicitud creada con 2048 será rechazada. Si el menú desplegable no ofrece 3072 para el proveedor que eligió, use 4096.

En el mismo grupo, deje sin marcar Hacer exportable la clave privada. Esta es la corrección más importante frente a las instrucciones antiguas de MMC. Una clave exportable puede copiarse fuera del equipo como archivo .pfx, que es exactamente lo que el requisito de hardware busca impedir, y la vía de atestación certifica explícitamente que la clave se creó de forma no exportable. El único caso para marcarla es una configuración de firma interna donde deba trasladar el certificado y la clave a otro equipo, e incluso entonces debilita la clave. Deje también sin marcar Permitir que la clave privada se archive. La Protección de clave privada segura es opcional y hace que Windows solicite confirmación cada vez que se usa la clave, lo cual es razonable para una clave de firma en una estación de trabajo compartida.

Expanda Seleccionar algoritmo de hash y configure Algoritmo de hash en sha256. SHA-1 no está permitido para certificados de firma de código.

La pestaña Extensiones merece una mirada si va a inscribirse en una CA interna. Expanda Uso de la clave y agregue Firma digital, luego expanda Uso de clave extendido (directivas de aplicación) y agregue Firma de código. Una CA pública construye el certificado a partir del producto que usted pidió, en lugar de a partir de las extensiones de su solicitud, por lo que para un pedido público esta pestaña no cambia nada. Una CA interna puede tenerla en cuenta.

Haga clic en Aceptar para cerrar Propiedades del certificado, y luego en Siguiente.

Paso 5: Guardar la solicitud

El asistente pregunta ¿Dónde desea guardar la solicitud sin conexión? Haga clic en Examinar, elija una carpeta que controle, asigne al archivo un nombre como codesigning.req y confirme. Navegue siempre hasta una carpeta en lugar de escribir un nombre de archivo a secas: sin una ruta, la solicitud termina en la carpeta desde la que se está ejecutando la consola, que rara vez es donde la quiere y resulta difícil de encontrar después.

En Formato de archivo, deje seleccionado Base 64. Esa es la forma de texto que las CA pegan en un cuadro de inscripción. Binario escribe DER sin procesar, que la mayoría de los formularios de pedido rechazan. Haga clic en Finalizar.

Abra el archivo en cualquier editor de texto plano, como el Bloc de notas, y copie el bloque completo, incluyendo la primera y la última línea:

-----BEGIN NEW CERTIFICATE REQUEST-----
MIIEbDCCA1QCAQAwZDELMAkGA1UEBhMCVVMx...
...base64 encoded request...
-----END NEW CERTIFICATE REQUEST-----

Las herramientas de inscripción de Windows normalmente escriben el texto más largo mostrado arriba, con la palabra NEW en las líneas marcadoras, mientras que OpenSSL escribe BEGIN CERTIFICATE REQUEST y END CERTIFICATE REQUEST. Si su archivo usa la forma más corta, no hay ningún problema: el contenido es la misma solicitud PKCS #10 y las Autoridades de Certificación aceptan ambas. Copie exactamente lo que ve y no reescriba las líneas marcadoras.

Algo que el asistente no produce es un archivo de clave privada que pueda guardar o copiar, y las guías antiguas que le indican conservar a salvo los archivos de clave pública y privada están describiendo una herramienta distinta. MMC guarda la nueva clave privada dentro del almacén de claves de Windows, bajo la cuenta que seleccionó en el paso 1, únicamente en ese equipo. La solicitud pendiente normalmente aparece en el complemento bajo Solicitudes de inscripción de certificados. De ello se derivan tres consecuencias:

• No elimine la solicitud pendiente mientras espera la emisión. Eliminarla descarta la clave, y el certificado emitido quedará entonces inservible.
• Complete el pedido en el mismo equipo, en el mismo contexto de cuenta. Una solicitud generada en el almacén de usuario no se puede finalizar en el almacén de equipo, ni viceversa.
• No reconstruya ni reinstale el sistema del equipo entre la generación de la solicitud y la instalación del certificado.

Paso 6: Revisar la solicitud antes de enviarla

Una solicitud no se puede editar después de creada, así que revísela ahora en lugar de descubrir un error tipográfico una vez comenzada la validación. Windows puede leerla de nuevo sin software adicional. Abra un símbolo del sistema en la carpeta que contiene el archivo y ejecute:

certutil -dump codesigning.req

Si tiene OpenSSL instalado, esto lee el mismo archivo y además verifica la firma de la solicitud:

openssl req -noout -text -verify -in codesigning.req

Confirme cuatro cosas en la salida: que el sujeto muestra el país, el estado, la localidad, la organización y el nombre común exactamente como usted quiere; que la clave pública tiene 3072 bits o más, o una curva ECDSA aprobada; que el algoritmo de firma es SHA-256; y, con el comando de OpenSSL, que aparece una línea verify OK, que confirma que la solicitud fue firmada por su clave privada correspondiente. También puede pegar el bloque en el decodificador de CSR para leerlo en un navegador.

Si algo está mal, genere una nueva solicitud desde el paso 2. Para ver qué proveedores están disponibles en el equipo, incluyendo cualquier proveedor de hardware que haya instalado, ejecute:

certutil -csplist

Paso 7: Instalar el certificado emitido en el mismo equipo

Envíe el bloque en Base 64 durante su pedido de certificado, complete la validación que solicite la CA, y descargue el certificado emitido cuando llegue. Como la clave privada permaneció en el almacén de claves de Windows, el certificado debe regresar al mismo almacén para poder usarse.

En el mismo complemento, haga clic con el botón derecho en Personal, elija Todas las tareas, luego Importar, y dirija el asistente al archivo. Windows empareja el certificado con la clave que conservó de la solicitud, y la entrada pendiente bajo Solicitudes de inscripción de certificados desaparece. Abra el certificado después y compruebe que la pestaña General indique que dispone de una clave privada que corresponde a este certificado. Si falta esa línea, el emparejamiento no se produjo, y puede volver a vincularlo con el número de serie del certificado:

certutil -repairstore My <serial-number>

Agregue el modificador -user si el certificado pertenece al usuario actual en lugar de al equipo:

certutil -user -repairstore My <serial-number>

A partir de ahí, su herramienta de firma toma el certificado del almacén. Recuerde el almacén que eligió en el paso 1: signtool lee el almacén My del usuario actual, a menos que pase /sm para el almacén del equipo.

Otras formas de crear la misma solicitud se cubren en las guías de CertReq, OpenSSL, Java Keystore y macOS Keychain Access. También puede consultar los tutoriales de firma de código más amplios u otras formas de generar un CSR.

Preguntas frecuentes