Assinar um pacote MSIX

A assinatura do pacote do aplicativo é uma etapa necessária no processo de criação de um pacote MSIX que pode ser implantado. Windows requer que os pacotes MSIX sejam assinados com um certificado de assinatura de código válido.

Para instalar com êxito um aplicativo Windows, o pacote não deve apenas ser assinado, mas também ser confiável no dispositivo. Isso significa que o certificado precisa ser encadeado a uma das raízes confiáveis no dispositivo. Por padrão, Windows confia em certificados da maioria das autoridades de certificação que fornecem certificados de assinatura de código.

Além disso, se você estiver criando um bundle MSIX, não será necessário assinar todos os pacotes dentro do bundle individualmente. Somente o pacote precisa ser assinado; a assinatura abrange os pacotes dentro do pacote.

Opções de assinatura

Escolha uma abordagem de assinatura com base em seu cenário:

Cenário Opção Custo
Desenvolvimento e teste local Certificado autoassinado Gratuito
Distribuição de produção (recomendado) Azure Artifact Signing (anteriormente Assinatura Confiável) Básico: ~$10/mês
Distribuição de produção (alternativa) Certificado de assinatura de código OV de uma autoridade certificadora US$ 300 a 500/ano
distribuição da Microsoft Store Assinado pela Loja durante o envio Gratuito

Observação

Azure Artifact Signing (anteriormente conhecido como Assinatura Confiável) é o serviço de assinatura de código gerenciado da Microsoft e é a opção recomendada para assinatura msix de produção. Principais características:

  • Reputação baseada em identidade: a reputação está vinculada à sua identidade de editor verificada em vez de a um certificado específico, portanto, ela se acumula entre builds. No entanto, como toda a distribuição que não seja da Store, novos aplicativos ainda mostrarão avisos do SmartScreen até que haja um histórico de downloads suficiente acumulado, o que normalmente leva várias semanas. Consulte a reputação do SmartScreen para desenvolvedores de aplicativos para Windows.
  • Certificados de curta duração: um novo certificado é emitido diariamente e cada certificado permanece válido por cerca de 3 dias, habilitando a revogação precisa de tempo, se necessário.
  • CI/CD pronto: dá suporte a GitHub Actions (azure/trusted-signing-action) e Azure DevOps prontos para uso.

Qualificação para certificados de confiança pública: disponível para organizações nos EUA, Canadá, União Europeia e Reino Unido, e para desenvolvedores individuais nos EUA e canadá. As organizações devem ter um histórico fiscal verificável de três ou mais anos. Consulte informações importantes para validação de identidade.

Signing com SignTool requer configuração extra: o SignTool funciona com a Assinatura de Artefato somente quando você usa as Ferramentas de Cliente de Assinatura de Artefato, que incluem o plug-in dlib necessário e o runtime .NET 8. Você também deve fornecer um arquivo metadata.json com o endpoint da conta e o perfil de certificado. Uma invocação padrão do SignTool do Windows SDK por si só não funcionará com a Assinatura de Artefatos. A instalação mais fácil é:

winget install -e --id Microsoft.Azure.ArtifactSigningClientTools

Consulte Configurar o SignTool com Assinatura de Artefatos para a configuração completa.

AzureSignTool é uma ferramenta de comunidade separada para assinatura com certificados armazenados em Azure Key Vault. Ele não dá suporte à Assinatura de Artefatos , os dois são serviços distintos. Para assinatura baseada no Azure Key Vault no Visual Studio, veja Assinar pacotes com Azure Key Vault.

WinApp CLI

A CLI do WinApp fornece comandos convenientes para assinatura de desenvolvimento:

  • winapp cert generate — crie um certificado autoassinado para desenvolvimento
  • winapp sign — assinar um pacote MSIX ou executável com um certificado
  • winapp tool signtool — acesse SignTool diretamente do SDK do Windows

Tópicos de assinatura

Tópico Descrição
Pré-requisitos para assinatura Pré-requisitos necessários para assinar um pacote de aplicativo.
Como usar a SignTool Como usar o SignTool do SDK do Windows para assinar um pacote de aplicativos.
Assinar pacotes com o Azure Key Vault Como assinar pacotes usando um certificado armazenado em Azure Key Vault de Visual Studio.
Assinar um pacote MSIX com a assinatura do Device Guard Como assinar seu aplicativo com a assinatura do Device Guard.
Criando pacotes não assinados para teste Como criar um pacote MSIX não assinado para teste.
Azure Artifact Signing O serviço de assinatura gerenciada da Microsoft (antigo Trusted Signing) para pacotes MSIX de produção.

Carimbo de data/hora

É altamente recomendável que o carimbo de data/hora seja usado ao assinar o seu aplicativo com um certificado. O carimbo de data/hora preserva a assinatura, permitindo que o pacote do aplicativo seja aceito pela plataforma de implantação do aplicativo mesmo depois que o certificado tiver expirado. No momento da inspeção do pacote, o carimbo de data/hora permite que a assinatura do pacote seja validada em relação ao momento em que foi assinado. Isso permite que os pacotes sejam aceitos mesmo depois que o certificado não for mais válido. Pacotes que não estiverem com carimbo de data/hora serão avaliados com base no tempo atual e, se o certificado não for mais válido, o Windows não aceitará o pacote.

Os seguintes são os diferentes cenários sobre a assinatura de aplicativo com/sem carimbo de data/hora:

Cenário O aplicativo é assinado sem o carimbo de data/hora O aplicativo é assinado com o carimbo de data/hora
O certificado é válido O aplicativo será instalado O aplicativo será instalado
O certificado é inválido(expirado) O aplicativo falhará ao instalar O aplicativo será instalado, pois a autenticidade do certificado foi verificada durante a assinatura pela autoridade de carimbo de data/hora

Observação

Se o aplicativo for instalado com êxito em um dispositivo, ele continuará a ser executado mesmo após a expiração do certificado, independentemente de estar carimbado com data/hora ou não.

Garantia de integridade do pacote

Além de garantir que apenas aplicativos confiáveis sejam instalados em um dispositivo, um benefício adicional da assinatura de um pacote MSIX é que ele permite que Windows imponha a integridade do seu pacote e seu conteúdo depois que ele é implantado em um dispositivo. Encadeando o AppxBlockMap.xml e AppxSignature.p7x em um pacote assinado, o Windows é capaz de executar verificações de validação sobre a integridade de um pacote e seu conteúdo em tempo de execução e durante as verificações do Windows Defender. Se um pacote for considerado adulterado Windows bloqueará a inicialização do aplicativo e iniciará um fluxo de trabalho de correção para que o pacote seja reparado ou reinstalado. Para pacotes não distribuídos por meio do Microsoft Store, a integridade do pacote será imposta se o pacote declarar o elemento uap10:PackageIntegrity e for implantado em builds Windows 2004 e posteriores. Abaixo está um exemplo de declaração para garantir a integridade do pacote no AppxManifest.xml:

<Package ...
xmlns:uap10="http://schemas.microsoft.com/appx/manifest/uap/windows10/10"  
IgnorableNamespaces="uap10">
...
  <Properties>
    <uap10:PackageIntegrity>
      <uap10:Content Enforcement="on" />
    </uap10:PackageIntegrity>
  </Properties>
...
</Package>

Modo de dispositivo

Windows 10 permite que os usuários selecionem o modo no qual executar seu dispositivo no aplicativo Configurações. Os modos são aplicativos da Microsoft Store, aplicativos de Sideload e modo de desenvolvedor.

Microsoft Store aplicativos é o mais seguro, pois só permite a instalação de aplicativos do Microsoft Store. Os aplicativos no Microsoft Store passam pelo processo de certificação para garantir que os aplicativos sejam seguros para uso.

Aplicativos de sideload e Modo do desenvolvedor são mais permissivos de aplicativos que são assinados por outros certificados, desde que esses certificados sejam confiáveis e encadeiem uma das raízes confiáveis no dispositivo. Selecione apenas o modo desenvolvedor se você for um desenvolvedor e estiver desenvolvendo ou depurando aplicativos do Windows 10. Mais informações sobre o modo desenvolvedor e o que ele fornece podem ser encontradas aqui.

Observação

A partir do Windows 10 versão 2004, a opção Sideload é ativada por padrão. Como resultado, o Modo do desenvolvedor agora é uma alternância. As empresas ainda podem desativar o sideload por meio da política.

  • Last updated on