Certificados de firma de código autofirmados para MSIX: Una guía práctica

2026-06-02

Tags: Windows · Microsoft Store · MSIX · Trampas del Store

---

En el artículo anterior, recorrimos el flujo completo de pruebas MSIX previas al envío. Un paso que aparecía repetidamente era la gestión de certificados autofirmados — instalarlos en el almacén Personas de confianza (Trusted People), empaquetar con el certificado correcto, etc. Pero ese artículo pasó por alto una pregunta importante: ¿cómo se crea realmente uno?

Esta guía cubre todo lo que necesita saber sobre los certificados de firma de código autofirmados para empaquetado MSIX: crearlos, exportarlos, usarlos en Visual Studio y gestionarlos en equipo.

Por qué MSIX necesita firma

Los paquetes MSIX deben estar firmados digitalmente antes de poder instalarse. Esto no es opcional — incluso para la descarga lateral (sideloading) y las pruebas locales, el sistema operativo exige una firma válida en cada archivo .msix.

Para la distribución a través del Store, Microsoft firma su paquete con su propio certificado tras la certificación. Pero para las pruebas locales y la descarga lateral, necesita un certificado propio. Aquí es donde entran los certificados autofirmados: le permiten firmar paquetes para desarrollo y pruebas sin adquirir un certificado de firma de código comercial.

El proceso de firma cumple dos propósitos:

• Integridad: Garantiza que el paquete no ha sido manipulado después de la firma
• Identidad: Identifica al publicador (usted) — el CN (Common Name) del certificado debe coincidir con el valor <Publisher> en su Package.appxmanifest

Usando New-SelfSignedCertificate

Windows incluye el cmdlet New-SelfSignedCertificate de PowerShell, que puede generar certificados para fines de prueba. Abra PowerShell como Administrador y pruebe esto:

New-SelfSignedCertificate -Type Custom -Subject "CN=YourCompany" -KeyUsage DigitalSignature -TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.3", "2.5.29.19={text}") -CertStoreLocation "Cert:\CurrentUser\My"

Desglosemos cada parámetro:

Parámetro	Función
-Type Custom	Crea un certificado personalizado en lugar de uno básico
-Subject "CN=YourCompany"	Establece el Common Name — debe coincidir con el Publisher de su aplicación en Package.appxmanifest
-KeyUsage DigitalSignature	Marca el certificado para uso de firma digital
-TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.3", "2.5.29.19={text}")	Extended Key Usage configurado como Code Signing (1.3.6.1.5.5.7.3.3), más Basic Constraints configurado como End Entity (2.5.29.19) — requerido por el motor de implementación de Windows para paquetes de aplicación
-CertStoreLocation "Cert:\CurrentUser\My"	Almacena el certificado en el almacén Personal del usuario actual

Sin ambos valores TextExtension, es posible que el certificado no se reconozca completamente — el OID de Basic Constraints lo marca como Entidad Final (no una CA), algo que el motor de implementación de Windows verifica al procesar paquetes MSIX. Su ausencia puede causar errores de implementación o advertencias del WACK en ciertas versiones de Windows.

Nota: En mis propios proyectos, he usado certificados autofirmados sin la extensión Basic Constraints y han funcionado sin problemas. Esta restricción es una práctica recomendada por Microsoft, pero no es estrictamente necesaria para desarrollo y sideloading.

Creando el certificado con el EKU de Code Signing

Si ya creó un certificado sin el EKU de Code Signing, aún puede verificar si tiene las propiedades correctas. Abra el certificado (a través de certlm.msc) y revise Details → Enhanced Key Usage — debería ver Code Signing listado.

Aquí tiene un script práctico que crea un certificado y lo prepara para su uso con MSIX:

# Crear un certificado de firma de código autofirmado (Code Signing EKU + Basic Constraints)
$cert = New-SelfSignedCertificate -Type Custom -Subject "CN=YourCompany" -KeyUsage DigitalSignature -TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.3", "2.5.29.19={text}") -CertStoreLocation "Cert:\CurrentUser\My"

# Mostrar los detalles del certificado
$cert | Format-List Subject, Thumbprint, NotAfter

# Mostrar la huella digital para referencia rápida
Write-Host "Huella digital del certificado: $($cert.Thumbprint)"

Reemplace "CN=YourCompany" con el nombre real de su publicador. Puede encontrar el nombre de su publicador en Package.appxmanifest, bajo el elemento Identity:

<Identity Name="YourApp" Publisher="CN=YourCompany" Version="1.0.0.0" />

Exportación de PFX vs CER

Después de crear el certificado, normalmente necesitará dos tipos de archivos:

PFX (Personal Information Exchange)

Contiene la clave privada + el certificado. Es lo que Visual Studio utiliza para firmar paquetes. Trátelo como una contraseña — cualquiera que tenga acceso al PFX puede firmar paquetes en su nombre.

$password = ConvertTo-SecureString -String "YourPassword" -Force -AsPlainText
Export-PfxCertificate -Cert $cert -FilePath "codesign.pfx" -Password $password

CER (Certificate file)

Contiene solo el certificado público (sin clave privada). Es lo que distribuye a las máquinas de prueba para que confíen en sus paquetes firmados.

Export-Certificate -Cert $cert -FilePath "codesign.cer"

Referencia rápida

Formato	¿Contiene clave privada?	Uso
.pfx	Sí	Firma de paquetes (Visual Studio, signtool)
.cer	No	Instalación en máquinas de prueba para establecer confianza

Importando el certificado y obteniendo la huella digital

Para instalar paquetes MSIX firmados con su certificado autofirmado en una máquina de prueba, el certificado debe ser de confianza para el sistema.

Instalar el certificado

1. Haga doble clic en el archivo .cer → Install Certificate
2. Seleccione Local Machine → Browse → seleccione Personas de confianza (Trusted People)
3. Complete el asistente

Alternativamente, mediante PowerShell:

Import-Certificate -FilePath "codesign.cer" -CertStoreLocation "Cert:\LocalMachine\TrustedPeople"

Encontrar la huella digital

Necesitará la huella digital (thumbprint) cuando utilice herramientas de firma de línea de comandos:

# Listar todos los certificados de firma de código en el almacén personal
Get-ChildItem -Path "Cert:\CurrentUser\My" -CodeSigningCert | Format-Table Subject, Thumbprint, NotAfter

La huella digital es una cadena hexadecimal de 40 caracteres. Cópiela exactamente — la necesitará para los comandos de firma.

Usando el certificado en Visual Studio

Una vez que tenga un archivo PFX, puede usarlo en el asistente de empaquetado de Visual Studio:

1. Clic derecho en su proyecto → Package and Publish → cree un nuevo perfil de empaquetado
2. En el paso Select Signing Certificate, haga clic en Select from File...
3. Busque su archivo .pfx e introduzca la contraseña
4. Complete el asistente de empaquetado

El certificado se guarda en el perfil de empaquetado, por lo que no es necesario volver a seleccionarlo cada vez. Sin embargo, si el certificado caduca o cambia a uno nuevo, deberá actualizar el perfil.

Usando el certificado desde el almacén de certificados

Si importó el PFX a su almacén de certificados personal, también puede seleccionarlo directamente:

1. En el paso de firma, despliegue el menú desplegable en lugar de hacer clic en "Select from File..."
2. Busque su certificado en la lista (identificado por el CN que especificó)
3. Selecciónelo y continúe

Este enfoque es práctico, pero tenga cuidado — Visual Studio puede almacenar en caché una huella digital específica, y si el certificado se renueva (nuevo par de claves), la referencia almacenada podría quedar invalidada.

Caducidad, renovación y refirma del certificado

Los certificados autofirmados creados con New-SelfSignedCertificate tienen una validez predeterminada de 1 año (algunas versiones usan 3 años por defecto — verifique la propiedad NotAfter).

Lista de verificación

• [ ] Anote la fecha de caducidad de su certificado
• [ ] Antes de la caducidad, cree un nuevo certificado y vuelva a firmar todos los paquetes
• [ ] Distribuya el nuevo .cer a las máquinas de prueba
• [ ] Actualice el perfil de empaquetado en Visual Studio
• [ ] Para los envíos al Store, genere un nuevo paquete Test con el nuevo certificado

Para comprobar la caducidad:

Get-ChildItem -Path "Cert:\CurrentUser\My" -CodeSigningCert | Format-Table Subject, NotAfter

Al renovar, cree un nuevo certificado con el mismo CN, exporte el nuevo PFX/CER y vuelva a firmar sus paquetes. La huella digital cambiará, así que asegúrese de actualizar todas las referencias.

Consejos para el trabajo en equipo

Cuando varios desarrolladores necesiten firmar paquetes con el mismo certificado:

• Almacene el PFX en una ubicación compartida segura — un archivo protegido con contraseña en el almacenamiento del equipo o un gestor de contraseñas que admita archivos adjuntos
• Nunca incluya el PFX en el control de versiones — añada *.pfx a su .gitignore
• Documente la contraseña en el gestor de contraseñas del equipo, no en el código ni en la documentación
• Cada desarrollador importa el PFX en su almacén de certificados personal y luego lo selecciona desde Visual Studio
• Use el mismo CN en todos los certificados si necesita crear certificados por desarrollador (para compilaciones que no sean de distribución)

Para los pipelines de CI/CD, la mayoría de los agentes de compilación admiten la importación de un PFX mediante variables de entorno seguras o secretos — consulte la documentación de su plataforma de CI para conocer el enfoque recomendado.

---

Este artículo es una lectura complementaria de la serie Trampas del Store.