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

Um certificado de assinatura de código comprova quem publicou um determinado software e mostra que o código não foi alterado desde que foi assinado. Para solicitar um, é preciso criar um CSR (Certificate Signing Request), o bloco de texto codificado que a Autoridade Certificadora (CA) usa para identificá-lo e emitir o certificado. Os CSRs de assinatura de código seguem regras diferentes das dos CSRs criados para um site, e essas regras mudaram em 2023. Este guia explica o processo atual e os métodos que ainda se aplicam.

A chave privada precisa estar em um dispositivo de hardware

Desde 1 de junho de 2023, os Requisitos Básicos de Assinatura de Código do CA/Browser Forum exigem que a chave privada de todo certificado de assinatura de código publicamente confiável seja gerada e armazenada em um hardware que atenda ao padrão FIPS 140-2 Nível 2, Common Criteria EAL4+, ou um padrão equivalente. Isso se aplica tanto aos certificados padrão (Validação de Organização e Validação Individual) quanto aos certificados de Validação Estendida (EV). A assinatura de código EV já exigia hardware antes dessa data; a mudança de 2023 estendeu a mesma regra aos certificados padrão.

A consequência prática é importante: uma chave privada e um CSR gerados puramente em software, em um navegador, ou em um arquivo comum em um laptop ou servidor, não são mais aceitos para um certificado de assinatura de código publicamente confiável. As CAs deixaram de oferecer suporte à geração de chaves baseada em navegador e à entrega de arquivos .pfx para download para esses produtos. A chave precisa se originar em um dispositivo compatível e permanecer nele. Isso deixa duas rotas válidas:

• Um token de hardware pré-configurado pela CA. A CA gera o par de chaves e o CSR diretamente em um token USB certificado, instala o certificado emitido nele e envia o token até você. Você assina com o token conectado. Com esse método, você não gera o CSR sozinho.
• Seu próprio HSM ou HSM em nuvem, com atestado de chave. Se você já opera um Módulo de Segurança de Hardware (HSM) compatível (ou um HSM em nuvem, como AWS CloudHSM, Azure Dedicated HSM ou Google Cloud HSM), você gera a chave e o CSR nesse dispositivo e fornece um arquivo de atestado que comprova à CA que a chave foi criada em um hardware compatível e não pode ser exportada dele.

A rota escolhida é definida no momento do pedido. Para uma comparação lado a lado, consulte os métodos de entrega do certificado de assinatura de código.

Opção 1: token com envio físico (a CA cria o CSR)

Essa é a rota escolhida pela maioria dos indivíduos e pequenas equipes, pois não exige hardware próprio. Ao selecionar a opção de token com envio físico no checkout, a CA cuida da geração da chave e da criação do CSR em um token certificado do lado dela, e depois envia o token pelo correio com o certificado já carregado. Não há CSR para você colar em um formulário de pedido.

O que você faz em vez disso:

• Conclua as etapas de validação solicitadas pela CA (verificação de organização ou de identidade).
• Aguarde a chegada do token físico.
• Instale os drivers do token (geralmente o SafeNet Authentication Client) e assine seu software com o token conectado.

Opção 2: gerar o CSR no seu próprio HSM ou token

Se você já possui um hardware compatível, gera o par de chaves e o CSR nesse dispositivo e fornece um atestado correspondente. As etapas exatas dependem do hardware, então siga o guia do seu dispositivo ou a documentação do seu fornecedor:

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

Para HSMs em nuvem (AWS CloudHSM, Azure Dedicated HSM, Google Cloud HSM), gere a chave dentro do HSM, exporte o CSR e o arquivo de atestado produzido pela plataforma, e envie ambos à sua CA durante o pedido.

Alguns detalhes se aplicam a todos os CSRs baseados em hardware:

• Use uma chave RSA de pelo menos 3072 bits, ou uma chave ECDSA equivalente, conforme especificado pelos Requisitos Básicos.
• Marque a chave como não exportável, para que não possa sair do dispositivo.
• Gere o atestado ao mesmo tempo que a chave. Um CSR sem atestado válido será rejeitado.

Onde os métodos OpenSSL, Java Keytool, MMC, CertReq e Keychain se encaixam agora

Você já deve ter visto instruções mais antigas que criam um CSR de assinatura de código com o OpenSSL, o utilitário Java keytool, o Microsoft Management Console (MMC), o comando certreq do Windows, ou o Keychain Access no macOS. Por si só, essas ferramentas geram a chave em software, então um CSR produzido dessa forma não é válido para um certificado de assinatura de código publicamente confiável atualmente.

Elas ainda têm utilidade quando apontadas para um hardware compatível, em vez de um armazenamento de chaves em software. Por exemplo, o OpenSSL pode criar um CSR usando um HSM por meio de um módulo PKCS#11, e o CertReq ou o MMC podem criar uma solicitação que use um provedor de armazenamento de chaves em hardware. Use essas referências apenas nesse contexto, e sempre acompanhe a solicitação com o atestado do dispositivo:

• Gerar um CSR de assinatura de código com OpenSSL
• Gerar um CSR de assinatura de código com Java Keystore
• Gerar um CSR de assinatura de código com CertReq
• Gerar um CSR de assinatura de código com Microsoft Management Console
• Gerar um CSR de assinatura de código com macOS Keychain Access

Verifique o conteúdo do seu CSR

Antes de enviar um CSR, confirme se os dados do assunto estão corretos. Se você tiver o OpenSSL disponível, decodifique a solicitação localmente e leia-a em texto simples:

openssl req -noout -text -in codesigning.csr

Revise a organização ou o nome comum e o tamanho da chave na saída exibida. Um verificador de CSR de site padrão não é a ferramenta adequada aqui, pois um CSR de assinatura de código está vinculado a um hardware e é validado por meio de atestado, e não por uma varredura HTTPS pública.

Perguntas Frequentes