Como Gerar um CSR para um Certificado de Assinatura de Código via MMC

O snap-in Certificados no Microsoft Management Console (MMC) permite criar um pedido de certificado PKCS #10 numa máquina Windows sem qualquer software adicional. Este guia percorre esse assistente ecrã a ecrã para um certificado de assinatura de código, e começa pela parte que a maioria das instruções mais antigas omite: as regras para as chaves privadas de assinatura de código mudaram a 1 de junho de 2023, e são elas que determinam se um pedido feito no MMC é sequer utilizável.

Leia esse requisito antes de abrir o assistente. O resto do guia parte do princípio de que já sabe qual o caminho que a sua encomenda vai seguir.

As chaves de assinatura de código têm de ser geradas em hardware

De acordo com os Requisitos Base de Assinatura de Código do CA/Browser Forum, em vigor desde 1 de junho de 2023, a chave privada de todos os certificados de assinatura de código publicamente confiáveis tem de ser gerada, armazenada e utilizada num módulo criptográfico de hardware certificado, no mínimo, ao nível FIPS 140-2 Level 2, Common Criteria EAL 4+, ou norma equivalente. Isto abrange tanto os certificados padrão (Validação de Organização e Validação Individual) como os de Validação Estendida. A assinatura de código EV já funcionava assim; a alteração de 2023 alargou a mesma regra aos produtos padrão.

Os requisitos também definem as características da própria chave. As chaves RSA têm de ter, no mínimo, 3072 bits, as chaves ECDSA têm de utilizar as curvas NIST P-256, P-384 ou P-521, e o SHA-1 não é permitido para certificados de assinatura de código.

Tão importante quanto isso, a Autoridade Certificadora tem de comprovar que a chave está de facto em hardware, utilizando um dos métodos indicados nos requisitos. Na prática, estes são os que vai encontrar:

• A CA envia-lhe um token de hardware que já contém um par de chaves gerado por ela nesse mesmo dispositivo.
• Contra-assina o pedido com um certificado do fabricante, que é precisamente o que significa atestação de chave: a prova de que a chave foi criada de forma não exportável dentro de um dispositivo compatível.
• Utiliza uma combinação de biblioteca criptográfica e módulo de hardware prescrita pela CA.
• Fornece uma auditoria de TI, um relatório de um serviço de proteção de chaves na nuvem, ou um acordo assinado através de um serviço de assinatura compatível.

Nenhuma destas condições é satisfeita por um pedido criado pelo MMC contra o Microsoft Software Key Storage Provider. Esse fornecedor cria a chave no armazenamento de software do Windows, pelo que o pedido resultante será rejeitado para um certificado de assinatura de código publicamente confiável, independentemente de como o resto do assistente for preenchido. As Autoridades Certificadoras também deixaram de oferecer geração de chaves no navegador e entrega descarregável em .pfx para estes produtos, ao mesmo tempo.

Se o seu objetivo é um certificado publicamente confiável, o caminho é decidido no momento da encomenda. Ou a CA gera a chave num token e envia-lho pelo correio, caso em que não há CSR nenhum para criar, ou gera a chave em hardware que já possui e submete uma atestação juntamente com o pedido. O guia métodos de entrega de certificados de assinatura de código compara as duas opções, e os passos específicos por dispositivo encontram-se aqui:

• YubiKey 5 FIPS: geração de CSR e atestação
• Luna Network Attached HSM v7.x: guia de CSR e atestação

Onde o MMC ainda se encaixa

O assistente não está obsoleto. É o fornecedor que escolhe dentro dele que determina onde a chave nasce, e há três situações em que continua a ser a ferramenta certa.

Um pedido apoiado por um fornecedor de hardware. A lista Cryptographic Service Provider no assistente mostra todos os fornecedores instalados na máquina, não apenas os fornecedores de software da Microsoft. Assim que o controlador de um token ou o minidriver de um cartão inteligente é instalado, o respetivo fornecedor também aparece aí. A diferença está em onde o par de chaves nasce: um fornecedor de software gera-o no seu computador, enquanto um fornecedor baseado em hardware, como um cartão inteligente ou fornecedor de token, instrui o dispositivo a gerar o par, e o dispositivo passa então a guardar a chave privada e a controlar o acesso a ela. Ao selecionar um fornecedor de hardware, o MMC produz um pedido para uma chave que nunca existiu em software.

Duas ressalvas antes de confiar nisso. O MMC produz apenas um pedido PKCS #10 e mais nada, pelo que não gera o ficheiro de atestação de chave que a maioria das Autoridades Certificadoras exige em conjunto com ele. Esse ficheiro provém da própria ferramenta do dispositivo. E é a CA que decide qual o método de verificação que aceita, sendo comum prescreverem o seu próprio utilitário para o efeito. Pergunte à sua CA qual o caminho que suporta antes de gerar seja o que for, porque uma chave criada com a ferramenta errada não pode ser transferida posteriormente.

Uma CA interna ou empresarial. Os Requisitos Base regem os certificados publicamente confiáveis. Um certificado emitido pela sua própria CA de Active Directory Certificate Services para assinatura interna está fora desse âmbito, pelo que é a sua própria política que decide como a chave é armazenada, sendo um fornecedor de software uma escolha legítima. Lembre-se do que obtém: o código assinado desta forma só é confiável em máquinas que já confiam na sua raiz interna, e em qualquer outro lugar o Windows continua a tratar o editor como desconhecido.

Assinatura de teste e preparação. Um pedido em software é aceitável para um certificado de teste, e para trabalhar os valores exatos do assunto (subject) que voltará a utilizar quando gerar o pedido real contra o seu hardware.

Passo 1: Abrir o snap-in Certificados

Prima a tecla Windows + R, digite mmc e prima Enter. Também pode digitar mmc na caixa de pesquisa da barra de tarefas e abri-lo a partir daí. Aceite o pedido do Controlo de Contas de Utilizador. Abre-se uma janela vazia chamada Console1.

Clique em Ficheiro, depois em Adicionar/Remover Snap-in. Na lista Snap-ins disponíveis, selecione Certificados e clique em Adicionar.

O Windows pergunta agora qual o repositório de certificados que o snap-in deve gerir: A minha conta de utilizador, Conta de serviço ou Conta de computador. Esta escolha é mais relevante para um certificado de assinatura de código do que para um certificado de servidor web, porque determina onde a chave reside e em que repositório a sua ferramenta de assinatura vai procurar:

• A minha conta de utilizador coloca a chave no repositório pessoal do utilizador com sessão iniciada. É a escolha habitual quando um programador assina de forma interativa, porque a ferramenta signtool da Microsoft abre por predefinição o repositório My do utilizador atual.
• Conta de computador coloca a chave no repositório da máquina, o que é adequado para um servidor de compilação onde a assinatura é executada sob uma conta de serviço. As ferramentas de assinatura precisam de ser instruídas a procurar aí: o signtool aceita o parâmetro /sm para o repositório da máquina.

Se escolher A minha conta de utilizador, clique em Concluir. Se escolher Conta de computador, clique em Seguinte, deixe selecionado Computador local (o computador onde esta consola está a ser executada) e clique em Concluir. De qualquer forma, clique em OK para fechar a janela Adicionar ou Remover Snap-ins.

Dois atalhos permitem saltar totalmente o passo do snap-in quando não precisa de guardar uma consola: certmgr.msc abre diretamente os repositórios de certificados do utilizador atual, e certlm.msc abre os repositórios do computador local. Se construiu a consola manualmente e prevê voltar a utilizá-la, use Ficheiro e depois Guardar para a preservar.

Passo 2: Iniciar um pedido personalizado

Na árvore da consola, expanda Certificados e clique com o botão direito na pasta Pessoal (ou na pasta Certificados por baixo dela, caso o repositório já contenha certificados). Escolha Todas as Tarefas, depois Operações Avançadas, e por fim Criar Pedido Personalizado. Os mesmos comandos encontram-se também no menu Ação, se preferir.

Abre-se o assistente Registo de Certificados no ecrã Antes de Começar. Clique em Seguinte.

Em Selecionar Política de Registo de Certificados, procure a secção Pedido Personalizado e selecione Prosseguir sem política de registo, depois clique em Seguinte. Isto indica ao Windows para construir um pedido autónomo para uma CA externa, em vez de se registar contra um modelo do Active Directory.

A página Pedido personalizado tem três definições:

• Modelo. Escolha (Sem modelo) Chave CNG. Isto utiliza um Fornecedor de Armazenamento de Chaves (Key Storage Provider), que é o modo como os fornecedores de hardware modernos se registam. (Sem modelo) Chave Legada utiliza os fornecedores CryptoAPI mais antigos e só é necessária quando um dispositivo ou aplicação específica a exige.
• Suprimir extensões predefinidas. Deixe desmarcado, a menos que pretenda enviar apenas as extensões que definir manualmente.
• Formato do pedido. Selecione PKCS #10. Todas as CAs o aceitam. CMC destina-se a pedidos dirigidos a sistemas que especificamente o exigem.

Clique em Seguinte. Na página Informações do Certificado, verá uma única linha designada Pedido personalizado com o estado Disponível. Clique na seta Detalhes à direita dessa linha para a expandir e, em seguida, clique no botão Propriedades que aparece. Abre-se a caixa de diálogo Propriedades do Certificado com quatro separadores: Geral, Assunto, Extensões e Chave Privada.

Passo 3: Introduzir os detalhes do assunto (subject)

No separador Geral, digite um Nome amigável e, se quiser, uma Descrição. Ambos são etiquetas locais que o ajudam a encontrar o certificado no repositório mais tarde. Nenhum deles faz parte do pedido, nem é validado.

Mude para o separador Assunto. É aqui que se monta a identidade que aparecerá como o editor do software. Em Nome do assunto, escolha uma entrada na lista pendente Tipo, digite o texto correspondente na caixa Valor e clique em Adicionar >. Cada entrada passa para a lista à direita, onde o Windows a mostra de forma abreviada (CN=, O=, OU=, L=, S=, C=). Repita para cada um dos seguintes:

• Nome comum (CN): o nome registado da sua organização, ou o nome legal completo do indivíduo no caso de um certificado individual. Esta é a identidade que os utilizadores veem quando o Windows indica o editor.
• Organização (O): o nome registado da organização a que o certificado pertence. Se o nome contiver um símbolo, como um “e” comercial (&), escreva-o por extenso ou remova-o, já que estes caracteres não são aceites neste campo. “AB & C Corporation” passa a ser “AB and C Corporation” ou “ABC Corporation”.
• Unidade organizacional (OU): o departamento responsável pelo registo, por exemplo TI. Opcional.
• Localidade (L): a cidade onde a organização está registada.
• Estado (S): o estado ou província, escrito por extenso. Use Florida, não FL.
• País (C): o código de país ISO de duas letras do local onde a organização está registada, por exemplo US.

Introduza os detalhes de forma a corresponderem exatamente aos seus registos legais, porque a CA valida-os face a fontes públicas e oficiais antes de emitir seja o que for. Uma incongruência é a razão mais comum para uma encomenda de assinatura de código ficar parada.

Deixe a caixa Nome alternativo vazia. Os Nomes Alternativos do Assunto (SAN) identificam servidores pelo nome do anfitrião, e um certificado de assinatura de código identifica um editor e não uma máquina, pelo que não contém entradas DNS.

Passo 4: Escolher o fornecedor, o tamanho da chave e o hash

Abra o separador Chave Privada. Contém vários grupos expansíveis: Fornecedor de Serviços Criptográficos, Opções de chave, Selecionar Algoritmo de Hash, Selecionar Formato de Assinatura e Permissões de chave. Clique num título para o expandir.

Expanda primeiro Fornecedor de Serviços Criptográficos, porque é esta a definição que os Requisitos Base ativam. A lista mostra todos os fornecedores instalados na máquina, cada um com uma caixa de verificação. Certifique-se de que o único selecionado é o fornecedor que realmente pretende:

• Para um certificado de assinatura de código publicamente confiável, selecione o fornecedor pertencente ao seu token ou HSM. Só aparece nesta lista depois de o controlador ou minidriver do dispositivo estar instalado, portanto ligue o dispositivo e instale o respetivo software primeiro.
• RSA, Microsoft Software Key Storage Provider é a opção de software. Utilize-a apenas para uma CA interna ou um certificado de teste.
• A lista também apresenta entradas ECDSA, como ECDSA_P256, Microsoft Software Key Storage Provider. Confirme que a sua CA suporta ECDSA para assinatura de código antes de escolher uma, pois nem todos os produtos o fazem.

Expanda Opções de chave. Defina Tamanho da chave como 3072 ou 4096. RSA 3072 é o mínimo para assinatura de código, e um pedido criado com 2048 será recusado. Se a lista pendente não oferecer 3072 para o fornecedor escolhido, use 4096.

No mesmo grupo, deixe desmarcada a opção Tornar a chave privada exportável. Esta é a correção mais importante a fazer relativamente às instruções mais antigas do MMC. Uma chave exportável pode ser copiada da máquina como um ficheiro .pfx, que é exatamente o que o requisito de hardware existe para impedir, e a via de atestação certifica explicitamente que a chave foi criada de forma não exportável. O único caso para a marcar é uma configuração de assinatura interna em que o certificado e a chave têm mesmo de ser transferidos para outra máquina, e mesmo assim isso enfraquece a chave. Deixe também desmarcada a opção Permitir que a chave privada seja arquivada. A Proteção forte da chave privada é opcional e faz com que o Windows peça confirmação sempre que a chave é utilizada, o que é razoável para uma chave de assinatura numa estação de trabalho partilhada.

Expanda Selecionar Algoritmo de Hash e defina Algoritmo de Hash como sha256. O SHA-1 não é permitido para certificados de assinatura de código.

Vale a pena olhar para o separador Extensões se estiver a registar-se junto de uma CA interna. Expanda Uso da chave e adicione Assinatura digital, depois expanda Uso Estendido da Chave (políticas de aplicação) e adicione Assinatura de Código. Uma CA pública constrói o certificado a partir do produto que encomendou, e não a partir das extensões do seu pedido, pelo que, numa encomenda pública, este separador não altera nada. Uma CA interna pode respeitá-lo.

Clique em OK para fechar Propriedades do Certificado e depois em Seguinte.

Passo 5: Guardar o pedido

O assistente pergunta Onde pretende guardar o pedido offline? Clique em Procurar, escolha uma pasta sob o seu controlo, dê ao ficheiro um nome como codesigning.req e confirme. Procure sempre uma pasta em vez de digitar apenas um nome de ficheiro: sem um caminho, o pedido acaba na pasta em que a consola estiver a ser executada, o que raramente é onde deseja e é difícil de encontrar novamente.

Em Formato do ficheiro, deixe selecionado Base 64. Essa é a forma de texto que as CAs colam numa caixa de registo. Binário escreve o DER em bruto, que a maioria dos formulários de encomenda rejeita. Clique em Concluir.

Abra o ficheiro em qualquer editor de texto simples, como o Bloco de Notas, e copie o bloco inteiro, incluindo a primeira e a última linha:

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

As ferramentas de registo do Windows normalmente escrevem a formulação mais longa mostrada acima, com a palavra NEW nas linhas de marcação, enquanto o OpenSSL escreve BEGIN CERTIFICATE REQUEST e END CERTIFICATE REQUEST. Se o seu ficheiro utilizar a forma mais curta, não há problema: o conteúdo é o mesmo pedido PKCS #10 e as Autoridades Certificadoras aceitam qualquer uma das formas. Copie exatamente o que vê e não reescreva as linhas de marcação.

Uma coisa que o assistente não produz é um ficheiro de chave privada que possa guardar ou copiar, e os guias mais antigos que dizem para guardar em segurança os ficheiros de chave pública e privada estão a descrever uma ferramenta diferente. O MMC mantém a nova chave privada dentro do repositório de chaves do Windows, sob a conta que selecionou no passo 1, apenas nesse computador. O pedido pendente aparece normalmente no snap-in em Pedidos de Registo de Certificados. Daqui resultam três consequências:

• Não elimine o pedido pendente enquanto aguarda a emissão. Eliminá-lo descarta a chave, e o certificado emitido tornar-se-á então inútil.
• Conclua a encomenda no mesmo computador, no mesmo contexto de conta. Um pedido gerado no repositório do utilizador não pode ser concluído no repositório da máquina, nem vice-versa.
• Não reconstrua nem reinstale a imagem da máquina entre a geração do pedido e a instalação do certificado.

Passo 6: Verificar o pedido antes de o submeter

Um pedido não pode ser editado depois de criado, pelo que deve verificá-lo agora, em vez de descobrir um erro de digitação depois de a validação já ter começado. O Windows consegue lê-lo de volta sem software adicional. Abra uma linha de comandos na pasta que contém o ficheiro e execute:

certutil -dump codesigning.req

Se o OpenSSL estiver instalado, este comando lê o mesmo ficheiro e verifica também a assinatura do pedido:

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

Confirme quatro coisas na saída: o assunto lista o país, o estado, a localidade, a organização e o nome comum exatamente como pretende; a chave pública tem 3072 bits ou mais, ou é uma curva ECDSA aprovada; o algoritmo de assinatura é SHA-256; e, com o comando OpenSSL, que aparece uma linha verify OK, confirmando que o pedido foi assinado pela sua chave privada correspondente. Também pode colar o bloco no descodificador de CSR para o ler diretamente no navegador.

Se algo estiver errado, gere um novo pedido a partir do passo 2. Para ver quais fornecedores estão disponíveis na máquina, incluindo quaisquer fornecedores de hardware que tenha instalado, execute:

certutil -csplist

Passo 7: Instalar o certificado emitido na mesma máquina

Submeta o bloco Base 64 durante a sua encomenda de certificado, conclua a validação pedida pela CA e descarregue o certificado emitido quando este chegar. Como a chave privada permaneceu no repositório de chaves do Windows, o certificado tem de regressar ao mesmo repositório para ser utilizável.

No mesmo snap-in, clique com o botão direito em Pessoal, escolha Todas as Tarefas, depois Importar, e indique ao assistente o ficheiro. O Windows associa o certificado à chave que guardou do pedido, e a entrada pendente em Pedidos de Registo de Certificados desaparece. Abra o certificado depois e verifique se o separador Geral indica que tem uma chave privada que corresponde a este certificado. Se essa linha estiver ausente, o emparelhamento não ocorreu, e pode voltar a associá-lo com o número de série do certificado:

certutil -repairstore My <serial-number>

Adicione o parâmetro -user se o certificado pertencer ao utilizador atual em vez de à máquina:

certutil -user -repairstore My <serial-number>

A partir daí, a sua ferramenta de assinatura retira o certificado do repositório. Lembre-se do repositório que escolheu no passo 1: o signtool lê o repositório My do utilizador atual, a menos que passe /sm para o repositório da máquina.

Outras formas de criar o mesmo pedido são abordadas nos guias CertReq, OpenSSL, Java Keystore e macOS Keychain Access. Poderá também consultar os tutoriais de assinatura de código mais abrangentes ou outras formas de gerar um CSR.

Perguntas Frequentes