O Keychain Access ainda está presente em todos os Mac, e o seu Certificate Assistant continua a gerar pedidos de assinatura de certificado. Se esse pedido é útil para assinatura de código depende inteiramente do certificado que está a encomendar. Para um certificado Apple Developer ID, aquele que permite distribuir software para Mac fora da Mac App Store, o Keychain Access é a ferramenta correta e os passos abaixo estão atualizados. Para um certificado comercial de assinatura de código de uma Autoridade de Certificação pública, o tipo usado para assinar executáveis, instaladores, drivers e aplicações Java do Windows, um pedido gerado no Keychain Access deixou de ser aceite desde 1 de junho de 2023, porque a chave privada tem agora de ser criada em hardware.
Determine primeiro qual dos dois precisa, e depois siga a secção correspondente.
Qual certificado de assinatura de código está realmente a obter?
Ambos os produtos são chamados certificados de assinatura de código e ambos comprovam quem publicou determinado software, mas provêm de emissores diferentes e seguem regras diferentes. Os leitores acabam nesta página porque a Apple e as Autoridades de Certificação públicas usam as mesmas palavras para duas coisas diferentes.
- Certificado Apple Developer ID. Emitido pela Apple, através da sua própria Developer ID Certification Authority, a membros do Apple Developer Program. Assina aplicações Mac, plug-ins e pacotes de instalação que distribui por conta própria, para que o macOS Gatekeeper o reconheça como um developer identificado. O par de chaves é gerado no seu Mac e permanece no seu keychain de login, e o pedido é criado no Keychain Access.
- Certificado de assinatura de código publicamente confiável. Adquirido junto de uma Autoridade de Certificação pública como a Sectigo, DigiCert ou GlobalSign. Assina executáveis do Windows, instaladores MSI, drivers, scripts PowerShell e aplicações Java. É regido pelos CA/Browser Forum Code Signing Baseline Requirements, que exigem que a chave privada seja gerada e permaneça em hardware certificado, pelo que não há nada para o Keychain Access fazer.
A regra prática de decisão: se o software que está a assinar corre em macOS e o está a distribuir fora da Mac App Store, precisa de um certificado Developer ID. Se está a assinar algo para Windows, ou uma aplicação Java, precisa de um certificado comercial de assinatura de código, mesmo que o compile num Mac. Nenhum destes é um certificado SSL/TLS. Se o que pretende realmente é HTTPS num servidor Mac, siga em vez disso como gerar um CSR em servidores macOS.
A via comercial: por que o método do Keychain deixou de se aplicar
Desde 1 de junho de 2023, os CA/Browser Forum Code Signing Baseline Requirements exigem que a chave privada de cada certificado de assinatura de código publicamente confiável, tanto padrão (OV) como Extended Validation (EV), seja gerada e armazenada num módulo criptográfico de hardware que cumpra o FIPS 140-2 Level 2, Common Criteria EAL4+, ou uma norma equivalente, e seja não exportável. A assinatura de código EV sempre exigiu hardware; a alteração de 2023 estendeu a mesma regra aos certificados padrão.
Uma chave criada pelo Certificate Assistant falha esse teste por definição, por três razões distintas:
- A chave é material de chave de software exportável. É escrita no seu keychain de login, e pode selecioná-la e exportá-la como um ficheiro .p12. Essa portabilidade é conveniente para o desenvolvimento Apple e é exatamente a propriedade que o requisito de hardware existe para eliminar.
- O tamanho da chave não é compatível. Os Baseline Requirements definem um mínimo de RSA 3072 bits para assinatura de código, e o menu Key Size do Certificate Assistant não tem a opção de 3072.
- O pedido não transporta praticamente nenhuma identidade. O Certificate Assistant pede apenas um Common Name e endereços de e-mail. Não há onde inserir os detalhes de organização, localidade, distrito ou país que uma Autoridade de Certificação valida para um certificado de assinatura de código validado por organização.
Isso deixa duas formas válidas de obter um certificado de assinatura de código publicamente confiável, e qual delas usa é decidido no momento da encomenda:
- Token mais envio. A Autoridade de Certificação gera o par de chaves e o pedido num token USB certificado do lado dela, carrega o certificado emitido nele, e envia-lhe o token por correio. Não há um CSR para criar ou colar em lado nenhum. Consulte que método de entrega de certificado de assinatura de código escolher.
- O seu próprio token de hardware, HSM ou HSM na cloud, com atestado. Gera a chave dentro do dispositivo, produz o pedido aí, e submete um ficheiro de atestado que comprove que a chave foi criada em hardware compatível e não pode ser exportada. Siga o guia geração de CSR e atestado com YubiKey 5 FIPS ou o guia CSR e atestado com Luna Network Attached HSM v7.x, ou a documentação do seu fornecedor de HSM.
Mais uma alteração que já entrou em vigor: a votação CSC-31 reduziu a validade máxima dos certificados de assinatura de código publicamente confiáveis de 39 meses para 460 dias para certificados emitidos a partir de 1 de março de 2026, pelo que as renovações passam agora a ocorrer aproximadamente a cada 15 meses. Para uma visão mais ampla, consulte como gerar um CSR para um certificado de assinatura de código e a versão OpenSSL do mesmo guia.
Gerar o CSR no Keychain Access para um certificado Apple Developer ID
Se já guardou um ficheiro .certSigningRequest, avance para submetê-lo na sua conta de developer.
Duas coisas a verificar antes de começar. Precisa de uma associação ao Apple Developer Program, e a Apple exige a função de Account Holder para criar um certificado Developer ID. Também tem direito a até cinco certificados Developer ID Application e cinco certificados Developer ID Installer por equipa. O portal pede-lhe para carregar um pedido de cada vez que cria um certificado, por isso percorra este processo uma vez por certificado.
Passo 1: Abra o Keychain Access e inicie o pedido
O Keychain Access já não está onde a maioria dos tutoriais diz que está. Até ao macOS Sonoma, encontrava-se em Applications > Utilities. A partir do macOS Sequoia, a Apple moveu-o para /System/Library/CoreServices/Applications/, uma pasta do sistema que o Finder não mostra quando navega em Applications, pelo que procurar em Utilities já não dá resultado. As formas mais rápidas de o abrir são o Spotlight (prima Command-Space e escreva Keychain Access), ou um único comando no Terminal:
open "/System/Library/CoreServices/Applications/Keychain Access.app"Com a aplicação aberta, escolha Keychain Access > Certificate Assistant > Request a Certificate From a Certificate Authority na barra de menus.
Antes de o fazer, clique numa área vazia da lista de itens para que nada esteja selecionado. Se uma chave ou certificado estiver realçado, o item de menu muda para Request a Certificate From a Certificate Authority With seguido do nome desse item, e cria o pedido em torno da chave existente em vez de criar um novo par. Isso é útil quando pretende deliberadamente reutilizar uma chave, e confuso quando não pretende.
Passo 2: Preencha a janela Certificate Information
O Certificate Assistant abre num painel intitulado Certificate Information. Este pede muito pouco:
- User Email Address: o endereço de e-mail da sua conta Apple Developer.
- Common Name: um rótulo para o par de chaves, por exemplo Developer ID Application Key. Este não é o nome que acaba por constar no certificado. A Apple constrói o assunto do certificado emitido a partir da sua equipa, no formato Developer ID Application: Nome da Sua Equipa (TEAMID), por isso trate este campo como uma referência sua.
- CA Email Address: deixe vazio. É usado apenas pela outra opção de entrega.
- Request is: selecione Saved to disk, não Emailed to the CA. O portal de developer da Apple aceita um ficheiro carregado.
Se também quiser escolher o tamanho da chave ou o algoritmo, marque Let me specify key pair information aqui. Depois clique em Continue.
Passo 3: Escolha as definições do par de chaves, se necessário
Este painel aparece apenas se marcou a caixa no passo 2, e para um certificado Developer ID normalmente pode saltá-lo. Os valores predefinidos são RSA a 2048 bits, que é o que as próprias instruções da Apple usam. Com RSA selecionado, o menu Key Size oferece 2048, 4096 e 8192 bits. O menu Algorithm oferece RSA e ECC, e mudar para ECC substitui esses tamanhos por 256, 384 e 521 bits. Deixe o algoritmo em RSA, a menos que o serviço em que se está a inscrever peça especificamente uma chave de curva elíptica.
Versões anteriores deste guia diziam para selecionar pelo menos 3072 bits neste ponto. Esse valor é o mínimo do CA/Browser Forum para certificados de assinatura de código comerciais. Não se aplica ao Developer ID, e não é oferecido neste menu, pelo que não há nada a selecionar. Clique em Continue.
Passo 4: Guarde o pedido e verifique o que ele contém
Escolha onde guardar o ficheiro e clique em Save. Obtém um ficheiro com a extensão .certSigningRequest, e o Certificate Assistant também coloca o par de chaves correspondente no seu keychain de login. O próprio ficheiro é texto PEM comum, pelo que pode abri-lo no TextEdit e lê-lo, embora o bloco codificado por si só não lhe diga muito.
Para confirmar os detalhes antes de o carregar, descodifique o pedido no Terminal. Isto funciona com o comando openssl já presente no macOS, que é o LibreSSL em vez do OpenSSL propriamente dito, por isso não há nada para instalar:
openssl req -noout -text -in CertificateSigningRequest.certSigningRequestVerifique três coisas na saída: a linha Subject mostra o Common Name e o endereço de e-mail que digitou, a linha da chave pública indica 2048 bit (ou o tamanho que escolheu), e o algoritmo de assinatura é SHA-256. Se preferir não usar o Terminal, cole o conteúdo do ficheiro no nosso descodificador de CSR para ler os mesmos campos.
Passo 5: Submeta o pedido e instale o certificado
Inicie sessão na sua conta Apple Developer e abra Certificates, Identifiers & Profiles. Clique em Certificates na barra lateral, depois no botão de adicionar, e em Software selecione Developer ID. Escolha o tipo de que precisa:
- Developer ID Application assina uma aplicação, plug-in ou pacote Mac.
- Developer ID Installer assina um pacote instalador Mac que contém a sua aplicação assinada.
Clique em Continue, depois em Choose File, selecione o seu ficheiro .certSigningRequest, clique novamente em Continue, e clique em Download. A Apple devolve um ficheiro de certificado com a extensão .cer. Clique duas vezes nele para o instalar, e ele aparece no Keychain Access em My Certificates, emparelhado com a chave privada criada no passo 4.
Assinar com o certificado é apenas metade do que o macOS verifica. O Gatekeeper espera que o software transferido fora da Mac App Store seja assinado com um certificado Developer ID e notarizado pela Apple, por isso submeta a compilação assinada para notarização antes de a distribuir. A notarização não substitui a assinatura, funciona em conjunto com ela.
Encontre a chave privada e faça uma cópia de segurança
O certificado não tem valor sem a chave privada gerada pelo Certificate Assistant, e essa chave existe exatamente num único local até a copiar. Para a encontrar, abra o Keychain Access, selecione o keychain login, depois a categoria Keys, e procure o Common Name que digitou no passo 2. Verá duas entradas sob esse nome, uma chave pública e uma chave privada. Note que a chave pública não é o seu CSR: o CSR é o ficheiro .certSigningRequest que guardou no disco.
Depois de o ficheiro .cer estar instalado, procure em My Certificates. Aí o certificado e a sua chave privada aparecem como uma única entrada, que é a identidade de assinatura usada pelo codesign, Xcode e pelos seus scripts de build. Para mover essa identidade para outro Mac ou para um servidor de build, clique com o botão direito na entrada e escolha Export, o que produz um ficheiro .p12 protegido por uma palavra-passe que define. Guarde esse ficheiro da mesma forma que guardaria qualquer chave de assinatura, porque quem o tiver, juntamente com a palavra-passe, pode assinar software em seu nome.
Faça a cópia de segurança antes de precisar dela. Os certificados Developer ID são válidos por cinco anos e não podem ser renovados: quando um expira, cria-se um substituto. Se perder a chave privada, o certificado nunca mais pode ser usado e tem de criar outro, o que consome um dos seus cinco lugares de Developer ID Application ou cinco de Developer ID Installer. Resista à tentação de revogar o antigo para “arrumar as coisas”. A Apple é explícita ao afirmar que uma aplicação assinada com um certificado Developer ID revogado não será instalada, e não será executada por um utilizador que já a possua, pelo que revogar quebraria todas as cópias já distribuídas. Revogue apenas se a chave tiver sido efetivamente roubada, e faça-o esperando essa quebra.
Uma nota de organização para quem chegou aqui à procura de um certificado comercial: se já gerou um par de chaves no Keychain Access para uma encomenda numa Autoridade de Certificação pública, ele não pode ser usado e nenhuma CA o aceitará. Nada se estraga se o deixar lá, mas há pouca razão para manter material de chave de assinatura exportável guardado num keychain. Selecione a chave pública e a chave privada em Keys e elimine-as, e depois faça a encomenda através de um token ou de um HSM.
Perguntas Frequentes
Para um certificado Apple Developer ID, sim, e é o método documentado pela Apple. Para um certificado de assinatura de código publicamente confiável de uma Autoridade de Certificação comercial, não. Desde 1 de junho de 2023, essas chaves privadas têm de ser geradas e armazenadas num módulo criptográfico de hardware que cumpra o FIPS 140-2 Level 2, Common Criteria EAL4+, ou uma norma equivalente, e uma chave criada no Keychain Access é material de chave de software exportável.
Em /System/Library/CoreServices/Applications/. A Apple moveu-o para lá no macOS Sequoia, pelo que já não está em Applications > Utilities e não aparece quando navega em Applications no Finder. Abra-o com o Spotlight, ou execute open "/System/Library/CoreServices/Applications/Keychain Access.app" no Terminal. A aplicação Passwords, separada e introduzida ao mesmo tempo, trata apenas de palavras-passe, não de certificados e chaves.
RSA de 2048 bits para um certificado Developer ID, que é o valor predefinido, pelo que pode deixar Let me specify key pair information desmarcado. Com RSA selecionado, o menu Key Size oferece 2048, 4096 e 8192 bits, e mudar para ECC substitui-os por 256, 384 e 521 bits. Em nenhuma definição oferece 3072 bits, que é o mínimo do CA/Browser Forum para certificados de assinatura de código comerciais, e essa é uma das várias razões pelas quais esta via não serve para uma encomenda comercial.
Porque o pedido que constrói contém apenas um Common Name e endereços de e-mail. A Apple não precisa de mais: preenche o assunto de um certificado Developer ID a partir da sua conta de developer. Uma Autoridade de Certificação comercial precisa de detalhes da organização, e valida-os face a registos públicos, o que é outra razão pela qual um pedido do Keychain não tem o formato adequado para essa encomenda.
Não. A regra de hardware do CA/Browser Forum aplica-se a certificados de assinatura de código publicamente confiáveis emitidos por Autoridades de Certificação comerciais. Os certificados Developer ID são emitidos pela própria autoridade de certificação da Apple a membros do Apple Developer Program, e a chave é gerada no seu keychain de login pelo Certificate Assistant, exatamente como descrito acima.
Gere um para cada. O portal de developer pede-lhe para carregar um pedido de assinatura de certificado em cada criação de certificado, e dar a cada identidade o seu próprio par de chaves significa que substituir ou revogar uma delas deixa intacto o software assinado com a outra. Dê a cada pedido um Common Name que consiga distinguir mais tarde no Keychain Access.
Verifique a categoria Keys do keychain login, procurando pelo Common Name que digitou, em vez do nome do ficheiro. Se estiver genuinamente ausente, as causas habituais são o par de chaves ter sido criado noutro Mac ou sob outra conta de utilizador, o item do keychain ter sido eliminado, ou o pedido ter sido construído a partir de uma chave existente com a variante Request a Certificate From a Certificate Authority With do item de menu. Sem a chave privada, o pedido não pode ser usado, por isso gere um novo.
Os certificados de assinatura de código publicamente confiáveis emitidos a partir de 1 de março de 2026 têm um limite de 460 dias, reduzido de 39 meses pela votação CSC-31 do CA/Browser Forum. Os certificados Apple Developer ID são válidos por cinco anos e são substituídos em vez de renovados. Em ambos os casos, o software que assinou enquanto o certificado era válido continua a funcionar depois de este expirar, desde que a assinatura tenha sido carimbada com data e hora. A Apple aplica uma exceção: verifica o certificado Developer ID Installer no momento em que um pacote instalador é executado, pelo que um .pkg tem de ser reassinado assim que esse certificado expira, mesmo que a aplicação nele contida não seja afetada.
Para leitura relacionada, consulte os nossos tutoriais de assinatura de código, as outras formas de gerar um CSR, e como assinar um ficheiro EXE usando um certificado de assinatura de código.
Economize 10% em certificados SSL ao fazer seu pedido hoje!
Emissão rápida, criptografia forte, 99,99% de confiança no navegador, suporte dedicado e garantia de reembolso de 25 dias. Código do cupom: SAVE10
