OpenSSL 4.1 no Windows: verificar a revisão 2 do instalador e as assinaturas das DLL

Atualizado em 11 de novembro de 2026. A OpenSSL publicou o instalador Windows 4.1.0-2 em 4 de novembro. A revisão acrescenta assinaturas Authenticode a libcrypto e libssl nos pacotes x86 e ARM64; a biblioteca OpenSSL não mudou. Atenção: a versão apresentada, 4.1.0, não distingue as duas revisões do instalador. Este guia destina-se a administradores e programadores que gerem uma instalação Windows autónoma. [1][2]

O que a revisão 2 realmente corrige

O issue #30 descreve uma aplicação que falhou devido a DLL sem assinatura no pacote x86 original. As notas da versão também identificam ARM64. Isto não comprova uma intrusão nem uma nova correção criptográfica. Nem todas as falhas TLS têm esta causa. Um aviso sobre o certificado de um site é diferente da assinatura de código Windows de uma DLL local. [1][2]

Pré-requisitos e escolha do pacote

Comece por identificar o responsável e as dependências. Se a aplicação incluir a sua própria cópia de OpenSSL, siga o processo do respetivo fabricante, sem substituir DLL individualmente. Nas instalações sob a sua gestão, guarde a configuração, opções de instalação, origem do pacote e valor anterior de PATH; mantenha chaves privadas apenas no sistema de cópias de segurança protegido já existente. Prepare uma recuperação testada e uma janela de manutenção. A escolha x86/x64 depende também da aplicação, não apenas do sistema operativo. VS inclui o runtime Visual C++ correspondente; hybridCRT não depende dele. ARM64 só dispõe de hybridCRT. EXE e MSI são alternativas de empacotamento. No código, C:\Pilot\bin é apenas um exemplo: substitua-o pela pasta de instalação real e verificada antes da execução. [3]

Cinco passos para uma substituição controlada

  1. Faça um inventário sem alterar o sistema. No PowerShell do Windows, use Get-Command openssl -All para localizar os comandos e registar os caminhos completos. A ausência de resultados não exclui cópias integradas noutras aplicações. Relacione aplicação, arquitetura, localização das DLL, instalador anterior e eventuais erros de assinatura nos registos. Não copie chaves privadas nem tokens para relatórios.
  2. Obtenha o pacote adequado na página indicada, com a etiqueta publish/4.1.0-2. Registe etiqueta e nome do ficheiro e compare o SHA-256 calculado com o ficheiro de verificação correspondente do fabricante. Nomes iguais podem pertencer a revisões diferentes. Antes de executar, verifique a assinatura digital do instalador no Windows. O editor esperado é OpenSSL Software Services Czech, s.r.o. Se a assinatura for inválida ou houver divergências inexplicadas, pare; não desative proteções. [1][7]
  3. Apenas se a revisão autónoma 4.1.0-1 estiver realmente instalada: encerre de forma controlada as aplicações afetadas durante a manutenção, desinstale em Definições → Aplicações → OpenSSL Library conforme as instruções do fabricante e instale a revisão 2. Executar o novo pacote sobre a revisão 1 não constitui uma atualização. Não remova indiscriminadamente outros pacotes OpenSSL; assegure primeiro as dependências e a recuperação. [1]
  4. Escolha conscientemente os componentes e a pasta de destino. Não altere PATH sem analisar o efeito: o README indica que o instalador pode colocar a sua pasta no início do PATH do sistema. Use o caminho completo no teste piloto. Após instalar, verifique as assinaturas de libcrypto-4.dll e libssl-4.dll na pasta efetivamente utilizada. O bloco PowerShell abaixo apenas lê dados. O estado Valid e o titular esperado do certificado devem coincidir. [3][4]
  5. Execute version -a através do caminho explícito de openssl.exe e registe plataforma e pastas de configuração e módulos. A indicação 4.1.0, por si só, não comprova a revisão 2. Reinicie a aplicação afetada e repita a operação que falhava com dados de teste não sensíveis. Confirme também a cópia de DLL realmente carregada: o sucesso da linha de comandos não demonstra o sucesso da aplicação. [1][5]
$OpenSslBin = 'C:\Pilot\bin'
'openssl.exe', 'libcrypto-4.dll', 'libssl-4.dll' | ForEach-Object {
    Get-AuthenticodeSignature -LiteralPath (Join-Path $OpenSslBin $_)
} | Format-List Path, Status, StatusMessage, SignerCertificate

Verificação final e recuperação

Só aceite a alteração quando identidade do pacote, assinaturas das DLL, caminhos previstos e teste da aplicação forem coerentes. Se falhar, suspenda a distribuição, preserve o diagnóstico e recupere o estado de pacote/configuração previamente documentado pelo procedimento testado. Voltar a DLL sem assinatura não satisfaz uma exigência de assinatura; mantenha a operação afetada suspensa se necessário. Não misture DLL manualmente nem desative permanentemente as verificações.

Limites destas orientações

A revisão 2 não valida automaticamente uma configuração FIPS. Segundo o README, hybridCRT só oferece o fornecedor atual, não validado FIPS; a opção validada pertence à variante VS correspondente. Para planear o ciclo de vida, 4.1 não é LTS: o suporte indicado termina em 23 de novembro de 2027. Esta orientação baseia-se em fontes, não num teste de instalação Windows ou de criptografia realizado por nós. Sem ligações de afiliados. [3][6]