4

The following URL redirects to a microsoft.com subdomain: https://tb.rg-adguard.net/dl.php?go=3dd1ce66 Namely to https://software.download.prss.microsoft.com/db/Win10_20H2_v2_EnglishInternational_x64.iso?t=... (... being a random token)

I was able to get the final redirect URL by running:

curl -LsI -o /dev/null -w %{url_effective} "https://tb.rg-adguard.net/dl.php?go=7e583fea

But no matter if I run wget https://tb.rg-adguard.net/dl.php?go=3dd1ce66 or wget https://software.download.prss.microsoft.com/db/Win10_20H2_v2_EnglishInternational_x64.iso?t=...................

I always get certificate errors that I don't get when downloading the file using 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.

Why is the behavior not consistent across different applications (Firefox vs wget). Is there actually reason not to trust that certificate (and if so why is Firefox not catching that) or is wget at fault?

I'm using Fedora 35 x64 with Wget 1.21.2 and Firefox 98.0.

Improve this question
11
  • 1
    Nothing at fault - wget is using Fedora's certificates (from the ca-certificates package), while Firefox uses it's own trust-store.
    – garethTheRed
    Apr 12, 2022 at 15:28
  • 1
    Having checked my system (Debian, not Fedora), I find that the microsoft.com URL works for curl and wget. Have you installed the ca-certificates package?
    – garethTheRed
    Apr 13, 2022 at 6:00
  • 1
    I've just fired up a quick LXC container with Fedora 35 and am seeing the same as you. curl works, but wget fails. I can't even get wget to work with the --ca-certificate={file} option and a copy of the Digicert Global Root G2 certificate. This seems a Fedora wget issue.
    – garethTheRed
    Apr 14, 2022 at 19:16
  • 1
    A little more digging shows that gnutls-cli software.download.prss.microsoft.com works on Debian, but fails on Fedora. wget uses gnutls for TLS...
    – garethTheRed
    Apr 14, 2022 at 19:24
  • 1
    We saw similar weirdness when letsencrypt root ca expired. The dual chain certificate with one expired CA caused some incompatibility letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021 no idea if this is related. To begin tracing what's happening you should use OpenSSL commandline to download the certificate chain sent by Microsoft servers. Then you can begin to analyse precisely what certificate chain is invalid.
    – Philip Couling
    Apr 14, 2022 at 19:39

1 Answer 1

Reset to default
6
+50

What's broken

It looks like you've tripped up on this known issue: https://github.com/dotnet/core/issues/6830 The last comment there reads:

Update from the OneOCSP side: Due to a new CAB forum requirement, OneOCSP will switch the algorithm to SHA-256 by 2022-5-31.

According to that issue, wget (GnuTLS) is refusing to accept a Microsoft certificate because it has an OCSP URL URI:http://oneocsp.microsoft.com/ocsp and oneocsp.microsoft.com is signing its responses with SHA1. SHA1 is depreciated and strongly discouraged for use in signatures.

Arguably wget is doing the right thing by protecting your security. SHA1 has been considered insecure for some years and using it to sign certificates has not been supported for a few years now.

It's actually quite surprising this hasn't been spotted and fixed sooner; but then I guess OCSP is much less visible to users than x509 certificates themselves.

Why is this a problem?

OCSP solves the problem of revoking certificates before they expire. Certificates can contain an OCSP URL pointing to a server. Clients will read this and ask that server to verify the certificate is still valid and has not been revoked.

The server signs a response to say the certificate is valid and this response expires very quickly (seconds or minutes). So even when the certificate itself is valid, the OCSP server still needs to be there to confirm it.

But Microsoft's OCSP server is not behaving well...

Digital signatures actually sign a digital fingerprint for the document and SHA1 was previously used to create the fingerprint. But people have discovered a way to make a new document that matches an existing SHA1 fingerprint so they can fake a document that looks like it matches an existing signature!

So GNUTLS is refusing to trust some Microsoft certificates, because it refuses to trust SHA1 signed responses from Microsoft's OCSP server. Thus it can't be sure whether the certificate itself has been revoked or not.

Showing my working...

I was able to confirm the certificate's OCSP URL with openssl. First by fetching the certificates:

openssl s_client -showcerts -servername software.download.prss.microsoft.com -connect software.download.prss.microsoft.com:443 </dev/null

Then copy-pasting the certificates into files and reading them with with:

openssl x509 -in <filename> -text

In case you're curious how google led me to hat issue:

I ran wget with a gnutls debug option enabled:

GNUTLS_DEBUG_LEVEL=2 wget --verbose https://tb.rg-adguard.net/dl.php?go=3dd1ce66

This gives a really long debug output with this at the end:

gnutls[2]: looking for key purpose '1.3.6.1.5.5.7.3.1', but have '1.3.6.1.5.5.7.3.4'
ERROR: The certificate of ‘software.download.prss.microsoft.com’ is not trusted.

While this error is misleading it gave me a little more to go on with google.

Improve this answer
5
  • Okay thank you, so in the last comment of that GitHub issue it says "Update from the OneOCSP side: Due to a new CAB forum requirement, OneOCSP will switch the algorithm to SHA-256 by 2022-5-31." Does that mean this error will be gone then?
    – Forivin
    Apr 21, 2022 at 8:00
  • @Forivin yes. Obviously I can't speak for whether or not they will live up to the promise, but I would expect it just to go away some time "soon".
    – Philip Couling
    Apr 21, 2022 at 8:13
  • Okay, thank you, that's good to know. I wasn't sure because in that issue they were talking about a different domain, but I guess it all goes back to the same root cause then.
    – Forivin
    Apr 21, 2022 at 9:10
  • 1
    @Forivin Yes the domain is different, although the OCSP URL is the same on both certificates: oneocsp.microsoft.com/ocsp This is the one that's broken and needs fixing :D
    – Philip Couling
    Apr 21, 2022 at 9:24
  • 1
    It's finally fixed, as they promised. Thanks again. :)
    – Forivin
    Jun 2, 2022 at 8:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .