Developer ID Certification Authority vence em 1º de fevereiro de 2027

A Apple anunciou em 1º de outubro de 2026 que a Developer ID Certification Authority original vence em 1º de fevereiro de 2027 e que, a partir dessa data, pacotes de instalação assinados com um certificado emitido por ela “will no longer install” (não serão mais instalados). Apps notarizados são poupados: “Previously signed and notarized Mac software (with a secure timestamp) will keep working.” (software para Mac assinado e notarizado anteriormente, com carimbo de data/hora seguro, continuará funcionando).¹ A autoridade substituta, G2, emite certificados desde 27 de janeiro de 2022, e a Apple continuou oferecendo a original para equipes com versões antigas do Xcode, então uma equipe pode ter um certificado de cada uma.²³ O teste da Apple é a Organizational Unit (unidade organizacional) no nome do emissor do certificado, não a data de vencimento.

A seguir estão os comandos que leem esse campo a partir de um chaveiro (keychain), de um pacote e de um app; o que eles imprimem para os 66 apps Developer ID e os quatro instaladores do meu próprio Mac, onde 49 apps e todos os quatro instaladores se encadeiam à autoridade que vai vencer; uma frase do aviso da Apple que não bate com os certificados que consigo inspecionar; e a ordem em que eu assinaria tudo de novo.⁴

TL;DR

• A data. O certificado da autoridade original termina às 22:12:15 UTC de 1º de fevereiro de 2027, exatamente quinze anos, ao segundo, depois de começar. Apple: “Certificates issued by this authority will stop working on that date.” (certificados emitidos por esta autoridade deixarão de funcionar nessa data).¹⁴
• Pacotes param, apps notarizados não. “.pkg files signed with an affected certificate will no longer install” (arquivos .pkg assinados com um certificado afetado não serão mais instalados), enquanto software notarizado com carimbo de data/hora seguro “will keep working” (continuará funcionando).¹
• Leia o emissor. A Organizational Unit do emissor é “Apple Certification Authority” em um certificado da autoridade original e “G2” em um da autoridade atual. A Apple diz que a data de vencimento “doesn’t prove which authority issued a certificate” (não prova qual autoridade emitiu um certificado).²
• A amostra de um Mac. Todos os quatro instaladores assinados com Developer ID na minha pasta Downloads se encadeiam à autoridade original, e o mais recente foi assinado em 29 de dezembro de 2025. Dos 66 apps Developer ID na minha pasta Aplicativos, 49 se encadeiam a ela e 17 ao G2.⁴
• Até agora, o vencimento não parou software com carimbo de data/hora. Seis dos 49 apps são assinados com certificados que venceram entre 2022 e maio de 2026, e um instalador com um certificado que venceu em 2017. O Gatekeeper aceita os sete hoje. O aviso da Apple diz que o vencimento da própria autoridade encerra isso para pacotes.¹⁴
• Uma divergência. A Apple diz que os certificados G2 “expire annually” (vencem anualmente). Todos os 12 certificados G2 dos meus apps instalados, e o meu próprio, de maio de 2026, valem cinco anos. Nenhuma das duas páginas diz quando os prazos de um ano começaram.¹²⁴

O que a Apple anunciou?

O aviso é curto. Ele começa assim: “The original Developer ID Certification Authority (Sub-CA) expires on February 1, 2027. Certificates issued by this authority will stop working on that date.” (a Developer ID Certification Authority original, ou Sub-CA, vence em 1º de fevereiro de 2027; certificados emitidos por esta autoridade deixarão de funcionar nessa data).¹ Em seguida vêm três passos: verificar se você é afetado, criar um certificado novo e assinar de novo. O terceiro passo depende do que você distribui:

• Pacotes de instalação. “Starting February 1, 2027, .pkg files signed with an affected certificate will no longer install. Re-sign all packages with your new certificate before this date.” (a partir de 1º de fevereiro de 2027, arquivos .pkg assinados com um certificado afetado não serão mais instalados; assine de novo todos os pacotes com seu certificado novo antes dessa data).
• Apps para Mac. “Previously signed and notarized Mac software (with a secure timestamp) will keep working” (software para Mac assinado e notarizado anteriormente, com carimbo de data/hora seguro, continuará funcionando), sem nenhuma ação necessária, e “For future updates, sign with your new certificate and include a secure timestamp for notarization.” (para atualizações futuras, assine com seu certificado novo e inclua um carimbo de data/hora seguro para a notarização).¹

A página de ajuda para a qual o aviso aponta descreve o efeito na assinatura: “After that date, certificates issued from the original authority can no longer be used for signing and must be replaced with certificates from the current Developer ID Certification Authority (G2).” (depois dessa data, certificados emitidos pela autoridade original não podem mais ser usados para assinar e precisam ser substituídos por certificados da Developer ID Certification Authority atual, G2). Ela também indica “Required role: Account Holder.” (função exigida: Account Holder).²

A divisão entre apps e pacotes fica perto da orientação permanente da Apple sobre certificados vencidos. Para apps, a página de ajuda de Developer ID da Apple diz: “As long as your Developer ID certificate was valid when you compiled your app, then users can download and run your app, even after the expiration date of the certificate.” (desde que seu certificado Developer ID fosse válido quando você compilou o app, os usuários podem baixá-lo e executá-lo, mesmo depois da data de vencimento do certificado). Para instaladores, as páginas da Apple não concordam, nem consigo mesmas. A mesma página de ajuda diz “Your installer package will only launch if your Developer ID Installer certificate is valid.” (seu pacote de instalação só será aberto se o seu certificado Developer ID Installer for válido). A entrada de Developer ID Installer na visão geral de certificados puxa para os dois lados: os usuários “can still install packages that were signed with this certificate as long as the package includes a trusted timestamp” (ainda podem instalar pacotes assinados com este certificado, desde que o pacote inclua um carimbo de data/hora confiável), mas duas frases depois “new installations won’t be possible until you have re-signed your installer package with a valid Developer ID Installer certificate.” (novas instalações não serão possíveis até que você assine de novo seu pacote de instalação com um certificado Developer ID Installer válido).⁵ O aviso de 1º de outubro não dá aos pacotes nenhuma exceção por carimbo de data/hora.

O aviso fala apenas de instalação. Ele não diz o que acontece com software já instalado a partir de um pacote afetado, nem se instalações enviadas por gerenciamento de dispositivos ou executadas com o comando installer recebem o mesmo tratamento de um pacote que o usuário abre. Também não menciona imagens de disco assinadas. Sobre o primeiro ponto, a entrada da visão geral para um certificado de instalador vencido diz “Previously installed apps will continue to run.” (apps instalados anteriormente continuarão sendo executados).¹⁵

Por que existem duas autoridades?

Um certificado não pode durar mais que a autoridade que o emitiu. A página de suporte da Apple de 2022 coloca isso como regra: “Certificates cannot be issued with a validity period that extends past the intermediate certificate’s expiration date.” (não é possível emitir certificados com um período de validade que ultrapasse a data de vencimento do certificado intermediário).³ Todo certificado Developer ID anterior a 2022 que consigo encontrar vale cinco anos, então a partir de fevereiro de 2022 a autoridade original, com cinco anos restantes, já não podia emitir um de prazo completo. A resposta da Apple foi uma segunda autoridade: “Starting January 27, 2022, the digital certificates you use to sign your software and installer packages on macOS will be issued from the new Developer ID intermediate certificate that expires on September 16, 2031.” (a partir de 27 de janeiro de 2022, os certificados digitais que você usa para assinar seu software e seus pacotes de instalação no macOS serão emitidos a partir do novo certificado intermediário Developer ID, que vence em 16 de setembro de 2031). (O certificado em si termina em 17 de setembro de 2031 às 00:00:00 GMT, que no horário do Pacífico ainda é 16 de setembro.)³⁴

A original continuou disponível. Para equipes “running Xcode 11.4 or earlier” (que usam o Xcode 11.4 ou anterior), a Apple escreveu que “the Apple Developer website will continue to offer Developer ID certificates associated with the original intermediate certificate. Newly issued certificates from this intermediate certificate will be valid for less than five years” (o site Apple Developer continuará oferecendo certificados Developer ID associados ao certificado intermediário original; certificados recém-emitidos a partir dele valerão por menos de cinco anos), uma opção que “will be available for at least one year, starting January 27, 2022.” (ficará disponível por pelo menos um ano, a partir de 27 de janeiro de 2022).³

Os certificados do meu Mac mostram as duas metades dessa história. Os 49 apps que se encadeiam à autoridade original carregam 27 certificados de assinatura distintos. Os cinco emitidos antes de fevereiro de 2022 valem cinco anos cada. Os 22 emitidos a partir de 8 de fevereiro de 2022 terminam todos no mesmo segundo, 22:12:15 UTC de 1º de fevereiro de 2027, que é o último segundo da própria autoridade, e o mais recente deles foi emitido em 15 de janeiro de 2026. A autoridade original ainda emitia certificados quase quatro anos depois da chegada do G2, cada um mais curto que o anterior.⁴

Como descubro qual autoridade emitiu meu certificado?

A página de ajuda da Apple começa pelo portal de desenvolvedores: “Any certificates expiring on or before February 1, 2027, are likely affected. However, the expiration date alone doesn’t prove which authority issued a certificate.” (qualquer certificado que vença em 1º de fevereiro de 2027 ou antes provavelmente é afetado; porém, a data de vencimento sozinha não prova qual autoridade emitiu um certificado). O motivo que ela dá: “A team can hold a certificate from each authority with identical names, such as the same Developer ID Installer entry twice, differing only in expiration date.” (uma equipe pode ter um certificado de cada autoridade com nomes idênticos, como a mesma entrada Developer ID Installer duas vezes, diferindo apenas na data de vencimento). O teste da Apple fica no Keychain Access: selecione o certificado, “expand the Issuer Name field, and review the Organizational Unit field” (expanda o campo Issuer Name e confira o campo Organizational Unit). “Apple Certification Authority” significa “The certificate was issued from the previous Sub-CA. Replace this certificate.” (o certificado foi emitido pela Sub-CA anterior; substitua-o). “G2” significa “The certificate was issued from the current Sub-CA. No action needed.” (o certificado foi emitido pela Sub-CA atual; nenhuma ação necessária). A página acrescenta um alerta: “Check your own certificate, not the Developer ID Certification Authority entry in your keychain. That entry is the authority itself, and it’s issued by Apple Root CA, whose Organizational Unit is also Apple Certification Authority.” (confira o seu próprio certificado, não a entrada Developer ID Certification Authority do seu chaveiro; essa entrada é a própria autoridade, emitida pela Apple Root CA, cuja Organizational Unit também é Apple Certification Authority).²

O mesmo teste roda a partir de um terminal, em três lugares.

Um certificado no seu chaveiro.

security find-certificate -a -c "Developer ID Installer" -p \
  | openssl crl2pkcs7 -nocrl -certfile /dev/stdin \
  | openssl pkcs7 -print_certs -noout

A flag -a retorna todas as correspondências, o que importa por causa do alerta da Apple sobre nomes idênticos, e o pipeline imprime uma linha de sujeito e uma de emissor para cada uma. Troque por “Developer ID Application” para o certificado de assinatura de apps. Meu Mac tem um certificado Developer ID Application e nenhum certificado Installer, e com o /usr/bin/openssl do sistema a linha de emissor dele diz issuer=/CN=Developer ID Certification Authority/OU=G2/O=Apple Inc./C=US. O OpenSSL 3 do Homebrew imprime os mesmos campos separados por vírgulas. Um nome sem correspondência não imprime nada.⁴

Um pacote que você já distribuiu.

pkgutil --check-signature YourProduct.pkg

A saída lista o status da assinatura, o status da notarização, o carimbo de data/hora confiável e a cadeia de certificados. A data a ler é a que aparece sob a segunda entrada, “Developer ID Certification Authority”. Em cada um dos meus quatro instaladores ela é Expires: 2027-02-01 22:12:15 +0000. O certificado do próprio G2 termina em 17 de setembro de 2031 (GMT), então um pacote assinado sob o G2 deveria mostrar essa data nesse lugar. Não tenho nenhum pacote assinado sob o G2 para confirmar.⁴

Um app. codesign -dvv não basta sozinho, porque as duas autoridades compartilham o mesmo nome comum e as linhas Authority= dele ficam iguais para qualquer uma delas. Extraia a cadeia e leia o intermediário:

codesign -d --extract-certificates=/tmp/chain. YourApp.app
openssl x509 -inform DER -in /tmp/chain.1 -noout -subject -enddate

Em um app assinado sob o G2 da minha pasta Aplicativos, o segundo comando imprime OU=G2 no sujeito e notAfter=Sep 17 00:00:00 2031 GMT. Em um app assinado sob a autoridade original, ele imprime OU=Apple Certification Authority e notAfter=Feb 1 22:12:15 2027 GMT.⁴

O que o software de um Mac mostra?

Instaladores. Minha pasta Downloads tem quatro pacotes assinados com Developer ID, de dois fornecedores, e todos os quatro se encadeiam à autoridade original. Três vêm de um mesmo fornecedor, assinados em 28 de setembro, 14 de dezembro e 29 de dezembro de 2025 com um certificado de instalador emitido em 13 de abril de 2022 que termina em 1º de fevereiro de 2027. Esse fornecedor ainda assinava pacotes sob a autoridade original nove meses atrás. O quarto foi assinado em fevereiro de 2014 com um certificado que venceu em 29 de março de 2017.⁴

A avaliação de instalação do Gatekeeper, spctl -a -t install -vv, aceita hoje os quatro como “Notarized Developer ID”, inclusive aquele cujo certificado de assinatura venceu nove anos atrás. Esse resultado bate com a frase sobre o carimbo de data/hora confiável na entrada de instaladores da visão geral de certificados, e não com a frase “new installations won’t be possible” (novas instalações não serão possíveis) dessa mesma entrada nem com a página de ajuda de Developer ID. É também o comportamento que, segundo o aviso da Apple, termina para pacotes em 1º de fevereiro. Não consigo testar fevereiro a partir de outubro, então o que acontecer nesse dia é afirmação da Apple, não observação minha.¹⁴⁵

Apps. Entre os 66 apps da minha pasta Aplicativos assinados com Developer ID, 49 se encadeiam à autoridade original e 17 ao G2. Todas as 66 assinaturas trazem um carimbo de data/hora seguro. O Gatekeeper reporta 63 como “Notarized Developer ID”, que é a combinação que a Apple diz continuar funcionando: 46 dos 49 sob a autoridade original e todos os 17 sob o G2. Dos outros três, todos sob a autoridade original, dois falham na avaliação com “a sealed resource is missing or invalid”, um erro sobre o conteúdo do bundle, e um, assinado em julho de 2018, é aceito como Developer ID sem notarização. A frase da Apple cobre software notarizado, e o aviso não diz o que acontece com um app como esse último.¹⁴

Seis dos 49 são assinados com certificados que já tinham vencido em 1º de outubro de 2026, o primeiro em agosto de 2022 e o último em maio de 2026. O Gatekeeper aceita os seis, cinco deles como notarizados. A regra da Apple para apps, segundo a qual basta um certificado válido no momento da assinatura, já está em ação em software que eu uso.⁴⁵

Qual frase do aviso não bate?

O aviso diz sobre o G2: “This certificate authority is valid until 2031, but the certificates issued by the certificate authority expire annually and must be renewed each year.” (esta autoridade de certificação é válida até 2031, mas os certificados emitidos por ela vencem anualmente e precisam ser renovados a cada ano). A página de ajuda diz o mesmo: “Certificates issued from G2 are valid for one year and must be renewed annually.” (certificados emitidos pelo G2 valem por um ano e precisam ser renovados anualmente).¹²

Os certificados G2 que consigo inspecionar não são certificados de um ano. Os 17 apps assinados sob o G2 no meu Mac carregam 12 certificados de assinatura distintos, emitidos entre fevereiro de 2023 e 29 de maio de 2026, e todos valem cinco anos. Três deles foram emitidos em abril e maio de 2026. Meu próprio certificado Developer ID Application, emitido em 10 de maio de 2026, termina em 11 de maio de 2031.⁴

Nenhuma das duas páginas diz quando começou a validade de um ano, e não criei nenhum certificado desde o aviso, então não sei dizer com que prazo vem um certificado emitido hoje. Planeje uma renovação anual e leia as datas do certificado que for de fato emitido para você. Se certificados de um ano forem a regra daqui em diante, a divergência entre as páginas da Apple, e dentro da própria entrada da visão geral, sobre certificados de instalador vencidos passa a importar mais: se a frase do carimbo de data/hora confiável valer, um pacote sobrevive ao seu certificado, e se as outras valerem, não. O único dado que tenho é o pacote de 2014 citado acima, que o Gatekeeper ainda aceita. Como essas frases pesam umas contra as outras é leitura minha, não da Apple.

O que eu faria, em ordem?

1. Inventário. Rode a verificação do chaveiro para os dois tipos de certificado, e pkgutil --check-signature em cada pacote que você ainda oferece para download, inclusive versões antigas. A verificação de pacotes também funciona em instaladores de outros fornecedores, e é assim que se encontram os que sua equipe implanta e que precisam de um build assinado de novo pelo fornecedor.
2. Substitua. Se um emissor mostrar “Apple Certification Authority”, crie um certificado G2. Os passos da página de ajuda dizem que, se pedirem para selecionar um “Developer ID Certificate Intermediary” (o certificado intermediário do Developer ID), você deve escolher “G2 Sub-CA (Xcode 11.4.1 or later)”, porque “Any other option might issue a certificate from the expiring Certificate Authority” (qualquer outra opção pode emitir um certificado da autoridade de certificação que está vencendo), e o aviso alerta que “Choosing another option may issue a certificate that also expires in 2027.” (escolher outra opção pode emitir um certificado que também vence em 2027). Se você tem os dois tipos, “repeat these steps for each, since one certificate does not cover the other.” (repita estes passos para cada um, já que um certificado não cobre o outro). O aviso acrescenta uma pré-condição: “If you’re using Xcode 11.4 or earlier, update before creating your new certificate.” (se você usa o Xcode 11.4 ou anterior, atualize antes de criar seu certificado novo).¹²
3. Teste antes que o antigo vá embora. Apple: “Because you can hold up to five Developer ID Application and five Developer ID Installer certificates at a time, you can create and test a replacement before your current certificate expires.” (como você pode ter até cinco certificados Developer ID Application e cinco Developer ID Installer ao mesmo tempo, é possível criar e testar um substituto antes que seu certificado atual vença).²
4. Assine os pacotes de novo. O manual do productsign diz: “If you run productsign on a product archive that was previously signed, the existing signature will be replaced,” (se você rodar o productsign em um arquivo de produto já assinado, a assinatura existente será substituída), e que um carimbo de data/hora confiável “is enabled by default when signing with a Developer ID identity.” (vem ativado por padrão ao assinar com uma identidade Developer ID). Ele também incorpora “any intermediate certificates that are found in the keychain” (quaisquer certificados intermediários encontrados no chaveiro), então o intermediário G2 deve estar no chaveiro antes (a opção --cert do manual indica um intermediário pelo nome comum, e as duas autoridades têm o mesmo nome, então eu não confiaria nela para escolher entre elas): a página da Apple de 2022 diz que o Xcode 13.2 ou posterior o baixa automaticamente e, caso contrário, “you can download it from the Certificate Authority page.” (você pode baixá-lo na página Certificate Authority). O pipeline do chaveiro mostrado acima, rodado com o nome “Developer ID Certification Authority”, lista as autoridades que um Mac tem; o meu mostra as duas. Depois, notarize e grampeie (staple) o resultado de novo. A etapa de notarização é leitura minha, não uma frase da Apple: um pacote assinado de novo é um arquivo diferente. Não tenho nenhum certificado Developer ID Installer, então não executei esta etapa.³⁴
5. Confira o resultado. pkgutil --check-signature no arquivo assinado de novo não deveria mais mostrar a data de 2027 sob a autoridade, e spctl -a -t install -vv deveria continuar dizendo “Notarized Developer ID”.
6. Mantenha carimbo de data/hora nas assinaturas dos apps. Um carimbo de data/hora seguro é a propriedade que a Apple aponta para o software que continua funcionando, e a instrução dela para o que vem a seguir é “sign with your new certificate and include a secure timestamp for notarization.” (assinar com seu certificado novo e incluir um carimbo de data/hora seguro para a notarização).¹

Esse prazo é a segunda mudança em instaladores da temporada. A primeira está no próprio macOS 27, onde um pacote que não indica nenhuma arquitetura de host agora assume arm64 por padrão; o post sobre o Golden Gate mostra quais pacotes isso afeta, e uma equipe que vai assinar seus instaladores de novo de qualquer forma pode verificar as duas coisas de uma vez. O post sobre as notas de versão do macOS 27 traz o resto dessa versão para desenvolvedores de Mac, o post sobre o Xcode 27 e o post sobre Intel cobrem o lado das ferramentas, o post sobre acesso a contêineres entre equipes cobre uma mudança que faz apps para Mac já publicados falharem no momento da leitura, sem nenhum aviso, e o post sobre o ld64 cobre duas mudanças nas ferramentas que interrompem builds para Mac.

FAQ

Quando vence a Developer ID Certification Authority?

Em 1º de fevereiro de 2027. O certificado da autoridade original termina às 22:12:15 UTC desse dia. A autoridade atual, G2, termina em setembro de 2031; a página de suporte da Apple informa 16 de setembro, e o próprio certificado indica 17 de setembro às 00:00:00 GMT.¹³⁴

Meu app Developer ID vai parar de abrir em 1º de fevereiro de 2027?

A Apple diz que não para software que foi notarizado e assinado com carimbo de data/hora seguro: ele “will keep working” (continuará funcionando), sem nenhuma ação necessária. codesign -dvv YourApp.app imprime uma linha Timestamp= quando a assinatura tem um carimbo, e spctl -a -t exec -vv YourApp.app reporta “source=Notarized Developer ID” para um app notarizado.¹⁴

O que acontece com instaladores .pkg assinados sob a autoridade original?

Apple: “Starting February 1, 2027, .pkg files signed with an affected certificate will no longer install. Re-sign all packages with your new certificate before this date.” (a partir de 1º de fevereiro de 2027, arquivos .pkg assinados com um certificado afetado não serão mais instalados; assine de novo todos os pacotes com seu certificado novo antes dessa data).¹

Como verifico qual autoridade assinou um pacote?

Rode pkgutil --check-signature nele e leia a data sob a entrada “Developer ID Certification Authority” da cadeia. Expires: 2027-02-01 22:12:15 +0000 indica a autoridade original.⁴

Certificados G2 valem um ano ou cinco?

O aviso da Apple e a página de ajuda dizem um ano. Todos os certificados G2 que pude inspecionar em 1º de outubro de 2026, o mais recente emitido em 29 de maio de 2026, valem cinco anos. Nenhuma das duas páginas diz quando o prazo de um ano começou.¹²⁴

Quem na equipe pode criar o substituto?

A página de ajuda indica “Required role: Account Holder.” (função exigida: Account Holder).²

Fontes