A data passou; a verificação continua a ser importante

Em 24 de setembro de 2026, esta transição já não é um aviso sobre uma data futura: o certificado Microsoft Corporation UEFI CA 2011 deixou de ser utilizado para novas assinaturas em 26 de junho. A Microsoft transferiu a assinatura de aplicações UEFI de terceiros para as autoridades de 2023, incluindo Microsoft UEFI CA 2023; as Option ROM têm uma autoridade de 2023 separada. A data exata importa porque algumas notícias anteriores davam a entender que o próprio Secure Boot tinha uma data de validade. Não é esse o caso: expiram certificados específicos utilizados para assinar determinados componentes. (Orientações da Microsoft para distribuições Linux)

O Secure Boot é uma funcionalidade do firmware UEFI que verifica as assinaturas dos programas de arranque antes de permitir a sua execução. A cadeia pode incluir o gestor de arranque do sistema operativo, carregadores intermédios e controladores UEFI, incluindo componentes de firmware conhecidos como Option ROM. A base de dados de confiança db contém certificados ou imagens autorizados; a base de revogação dbx identifica elementos que não devem ser carregados. Assim, o estado de um PC depende das chaves registadas no firmware e das assinaturas concretas dos componentes que tenta iniciar, não simplesmente da idade do computador. (Descrição da Microsoft sobre OEM Secure Boot)

Expiração não é o mesmo que revogação

A distinção essencial é entre deixar de emitir novas assinaturas com um certificado e revogar a confiança nesse certificado ou num programa assinado com ele. A expiração do certificado de 2011 impede a sua utilização para assinar novos componentes através do processo da Microsoft; por si só, não elimina a chave da base db do firmware nem invalida automaticamente todos os ficheiros assinados anteriormente. A Microsoft indica que um shim Linux já assinado pela autoridade de 2011 pode continuar a arrancar se o firmware mantiver essa autoridade e se o shim ou o respetivo nível SBAT não tiver sido revogado. (Orientações da Microsoft para distribuições Linux)

A revogação é uma ação diferente: as entradas de dbx podem bloquear certificados ou componentes específicos. Se uma imagem estiver tanto na lista de confiança como na lista de revogação, prevalece a revogação. Por isso, um computador pode continuar hoje a iniciar um carregador antigo e, ao mesmo tempo, não estar preparado para receber no futuro uma versão corrigida assinada apenas com a autoridade de 2023. O facto de arrancar não prova que a cadeia esteja atualizada: confirma apenas que o firmware aceita o caminho de arranque usado naquela inicialização. (Descrição da Microsoft sobre OEM Secure Boot)

O que se pode notar no Windows e num computador de secretária comum

No caso do Windows, a Microsoft afirma que um dispositivo sem os novos certificados pode continuar a arrancar e a instalar atualizações normais. A principal consequência é futura: o PC poderá não receber ou validar proteções e atualizações posteriores que afetem o ambiente anterior ao arranque, como o gestor de arranque e outros componentes executados no início. Isto não significa que o Windows deixe de funcionar no dia seguinte à expiração, nem que todos os computadores precisem imediatamente de uma atualização do BIOS. A compatibilidade depende do modelo, do firmware OEM e do estado efetivo das bases de dados de chaves. (Orientações da Microsoft sobre atualizações de certificados)

A página da Microsoft destinada a utilizadores e administradores descreve cenários de maior risco quando o firmware é antigo ou o processo de atualização falha: erros de validação, pedidos de recuperação do BitLocker, bloqueios no arranque ou impossibilidade de iniciar o sistema. São problemas possíveis em circunstâncias específicas, não uma consequência inevitável de o calendário chegar a determinada data. É sensato manter o Windows e o firmware atualizados através dos canais oficiais do fabricante, sem alterar chaves UEFI por iniciativa própria para tentar antecipar a situação. Se o computador for gerido por uma organização, siga o respetivo procedimento e não faça alterações manuais. (Orientações da Microsoft sobre atualizações de certificados)

Linux e arranque duplo: importa a combinação de assinaturas e chaves

No Linux, o componente intermédio habitual em muitas distribuições com Secure Boot é o shim: o firmware valida a sua assinatura e o shim verifica os elementos seguintes da cadeia, como o GRUB e o kernel. A Microsoft documenta duas incompatibilidades possíveis: um sistema cujo firmware confia apenas na CA de 2023 não aceitará um shim assinado apenas pela CA de 2011; e um sistema que confia apenas na CA de 2011 não aceitará um shim assinado apenas com a de 2023. Em qualquer dos casos, não basta instalar “a versão mais recente”: o carregador instalado e os certificados em que o firmware confia têm de ser compatíveis. (Orientações da Microsoft para distribuições Linux)

No arranque duplo, o Windows pode servir de canal de distribuição para algumas atualizações em computadores compatíveis, mas isso não prova que o carregador Linux ou todas as distribuições estejam preparadas. Os responsáveis pela manutenção têm de publicar componentes assinados pelas novas autoridades, verificar se o firmware de destino as reconhece e ter em conta as listas de revogação e a política SBAT. A Red Hat, por exemplo, recomenda atualizar a base de confiança do firmware quando existe uma atualização adequada e também o shim da distribuição; alerta ainda que revogar simplesmente o certificado de 2011 pode impedir o arranque de componentes que ainda dependam dele. Não aplique o calendário de uma distribuição a todas as outras. (Orientações da Microsoft para distribuições Linux)

Como verificar o estado sem alterar chaves às cegas

Num PC Windows doméstico, verifique o Windows Update e a secção Segurança do dispositivo > Arranque seguro da aplicação Segurança do Windows, se estiver disponível na sua versão. A Microsoft documenta notificações e estados relativos à atualização dos certificados; em computadores geridos, a visibilidade e a implementação podem ser controladas de outra forma. Para administradores, a documentação indica elementos como o valor de registo UEFICA2023Status e eventos do sistema, incluindo os eventos 1801 e 1795. Estes dados ajudam a distinguir uma atualização pendente de um erro de firmware, mas um utilizador não deve interpretar uma mensagem isolada sem consultar as orientações para a sua edição e equipamento. (Centro de mensagens Microsoft Windows)

Nas distribuições Linux, ferramentas como mokutil permitem verificar se o Secure Boot está ativado e consultar certificados na base de dados do firmware; o guia da Red Hat também mostra como identificar as assinaturas do shim. Os resultados devem ser interpretados com cuidado: a presença de uma CA de 2023 não garante, por si só, que todos os componentes estejam atualizados, e a ausência pode ser relevante para um novo caminho de arranque sem significar que o computador vai falhar agora. Num sistema com encriptação, arranque medido ou desbloqueio automático associado ao TPM, alterar as bases de dados UEFI pode mudar medições como PCR7 e exigir a revisão da configuração. Faça um inventário antes de mudar seja o que for. (Orientações da Red Hat sobre certificados Secure Boot)

O que fazer se o fabricante não disponibilizar uma atualização

Comece por identificar o modelo exato da placa-mãe ou do computador de secretária e consulte a respetiva página de suporte: as atualizações das bases de dados UEFI dependem muitas vezes do fabricante do firmware ou do OEM. No Windows, instale as atualizações disponibilizadas pelo Windows Update e verifique o estado indicado pelo sistema; no Linux, utilize o mecanismo recomendado pela distribuição, como fwupd quando o dispositivo e a atualização forem compatíveis. Em computadores geridos, um teste-piloto e uma implementação gradual são mais prudentes do que aplicar a alteração a toda uma frota sem validação, sobretudo quando existem BitLocker, arranque duplo ou políticas de chaves personalizadas. A Microsoft recomenda verificar primeiro o firmware OEM e testar atualizações representativas antes de alargar a implementação. (Orientações da Microsoft sobre atualizações de certificados)

Se não houver uma atualização de firmware, não existe uma resposta universal que garanta a compatibilidade futura. Peça orientações ao fabricante e à distribuição específica, mantenha disponíveis as informações de recuperação do BitLocker e os dados importantes, e evite eliminar a CA antiga, escrever variáveis UEFI com instruções genéricas ou desativar o Secure Boot como reação automática. A Red Hat alerta que remover ou revogar a autoridade de 2011 pode inutilizar carregadores ou Option ROM que dependam dela; a Microsoft também descreve configurações incompatíveis capazes de impedir o arranque. A conclusão prática é limitada: a expiração, por si só, não desliga o computador de secretária, mas atualizar e verificar a cadeia de confiança ajuda a preservar a capacidade de receber futuras assinaturas e proteções de arranque. (Orientações da Red Hat sobre certificados Secure Boot)