A seguinte URL redireciona para um subdomínio microsoft.com: https://tb.rg-adguard.net/dl.php?go=3dd1ce66
Nomeadamente para https://software.download.prss.microsoft.com/db/Win10_20H2_v2_EnglishInternational_x64.iso?t=...
( ...
sendo um token aleatório)
Consegui obter o URL de redirecionamento final executando:
curl -LsI -o /dev/null -w %{url_effective} "https://tb.rg-adguard.net/dl.php?go=7e583fea
Mas não importa se eu corro wget https://tb.rg-adguard.net/dl.php?go=3dd1ce66
ouwget https://software.download.prss.microsoft.com/db/Win10_20H2_v2_EnglishInternational_x64.iso?t=...................
Sempre recebo erros de certificado que não recebo ao baixar o arquivo usando o Firefox.
wget https://software.download.prss.microsoft.com/db/Win10_20H2_v2_EnglishInternational_x64.iso\?t\=...................
--2022-04-12 14:57:29-- https://software.download.prss.microsoft.com/db/Win10_20H2_v2_EnglishInternational_x64.iso?t=..........................
Resolving software.download.prss.microsoft.com (software.download.prss.microsoft.com)... 152.199.21.175, 2606:2800:233:1cb7:261b:1f9c:2074:3c
Connecting to software.download.prss.microsoft.com (software.download.prss.microsoft.com)|152.199.21.175|:443... connected.
ERROR: The certificate of ‘software.download.prss.microsoft.com’ is not trusted.
Por que o comportamento não é consistente em diferentes aplicativos (Firefox vs wget). Existe realmente razão para não confiar nesse certificado (e, em caso afirmativo, por que o Firefox não está pegando isso) ou o wget é culpado?
Estou usando o Fedora 35 x64 com Wget 1.21.2 e Firefox 98.0.
O que está quebrado
Parece que você tropeçou neste problema conhecido: https://github.com/dotnet/core/issues/6830 O último comentário diz:
De acordo com esse problema,
wget
(GnuTLS) está se recusando a aceitar um certificado da Microsoft porque possui uma URL OCSPURI:http://oneocsp.microsoft.com/ocsp
e oneocsp.microsoft.com está assinando suas respostas com SHA1. SHA1 é depreciado e fortemente desencorajado para uso em assinaturas.Indiscutivelmente, o wget está fazendo a coisa certa, protegendo sua segurança. SHA1 foi considerado inseguro por alguns anos e usá-lo para assinar certificados não tem suporte há alguns anos.
É realmente surpreendente que isso não tenha sido detectado e corrigido antes; mas acho que o OCSP é muito menos visível para os usuários do que os próprios certificados x509.
Por que isso é um problema?
O OCSP resolve o problema de revogar certificados antes que expirem. Os certificados podem conter uma URL OCSP apontando para um servidor. Os clientes lerão isso e solicitarão que o servidor verifique se o certificado ainda é válido e não foi revogado.
O servidor assina uma resposta para dizer que o certificado é válido e essa resposta expira muito rapidamente (segundos ou minutos). Portanto, mesmo quando o próprio certificado é válido, o servidor OCSP ainda precisa estar lá para confirmá-lo.
Mas o servidor OCSP da Microsoft não está se comportando bem...
As assinaturas digitais realmente assinam uma impressão digital para o documento e o SHA1 foi usado anteriormente para criar a impressão digital. Mas as pessoas descobriram uma maneira de criar um novo documento que corresponda a uma impressão digital SHA1 existente, para que possam falsificar um documento que pareça corresponder a uma assinatura existente!
Portanto, o GNUTLS está se recusando a confiar em alguns certificados da Microsoft, porque se recusa a confiar nas respostas assinadas SHA1 do servidor OCSP da Microsoft. Assim, não pode ter certeza se o próprio certificado foi revogado ou não.
Mostrando meu trabalho...
Consegui confirmar o URL OCSP do certificado com openssl. Primeiro, buscando os certificados:
Em seguida, copie e cole os certificados em arquivos e leia-os com:
Caso você esteja curioso para saber como o google me levou a esse problema:
Eu corri
wget
com uma opção de depuração gnutls habilitada:Isso fornece uma saída de depuração muito longa com isso no final:
Embora esse erro seja enganoso, ele me deu um pouco mais para continuar com o google.