HTTP Error 60 for download.microsoft.com

Usage and Config
1

All fixlets I've tested that download from download.microsoft.com have stopped working, displaying

Download error:  "HTTP Error 60: SSL peer certificate or SSH remote key was not OK: SSL certificate problem: unable to get local issuer certificate"

We're running BigFix 11.0.5.203 on Windows Server 2022, and we aren't behind a proxy. Looking at the logs, it seems this started happening ~1 week ago.

Running .\openssl.exe s_client -connect download.microsoft.com:443 -showcerts does seem to fail as well from our root server:

Connecting to 69.192.23.118
CONNECTED(000001F0)
depth=0 C=US, ST=WA, L=Redmond, O=Microsoft Corporation, CN=akamai.download.microsoft.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C=US, ST=WA, L=Redmond, O=Microsoft Corporation, CN=akamai.download.microsoft.com
verify error:num=21:unable to verify the first certificate
verify return:1
depth=0 C=US, ST=WA, L=Redmond, O=Microsoft Corporation, CN=akamai.download.microsoft.com
verify return:1
---
Certificate chain
 0 s:C=US, ST=WA, L=Redmond, O=Microsoft Corporation, CN=akamai.download.microsoft.com
   i:C=US, O=Microsoft Corporation, CN=Microsoft TLS G2 ECC CA OCSP 02
   a:PKEY: EC, (prime256v1); sigalg: ecdsa-with-SHA384
   v:NotBefore: Jan 13 14:38:56 2026 GMT; NotAfter: Jul 12 14:38:56 2026 GMT
-----BEGIN CERTIFICATE-----
<trimmed>
-----END CERTIFICATE-----
---
Server certificate
subject=C=US, ST=WA, L=Redmond, O=Microsoft Corporation, CN=akamai.download.microsoft.com
issuer=C=US, O=Microsoft Corporation, CN=Microsoft TLS G2 ECC CA OCSP 02
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: ecdsa_secp256r1_sha256
Peer Temp Key: ECDH, prime256v1, 256 bits
---
SSL handshake has read 2299 bytes and written 1681 bytes
Verification error: unable to verify the first certificate
---
New, TLSv1.2, Cipher is ECDHE-ECDSA-AES256-GCM-SHA384
Protocol: TLSv1.2
Server public key is 256 bit
Secure Renegotiation IS supported
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-ECDSA-AES256-GCM-SHA384
    Session-ID: DE7896737BA3ABA5394C583654C4723E0A55E812A6E53C8D45EED54D949BF2E0
    Session-ID-ctx:
    Master-Key: B592EDB54D3A34A52C40C7CC01140CD9E94E2CCBD2CB1117F9280E170F7B001E91175C6ED626DCC1565E4C6A88B64FB4
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 83100 (seconds)
    TLS session ticket:
<trimmed>

    Start Time: 1769301713
    Timeout   : 7200 (sec)
    Verify return code: 21 (unable to verify the first certificate)
    Extended master secret: no
---
closed

In a browser on the root server, downloading from download.microsoft.com completes with no problem or complaint about certs, e.g. https://download.microsoft.com/download/78744b7f-00ec-4595-95d1-0863f0ef69e8/excel2016-kb5002820-fullfile-x86-glb.exe from "MS25-DEC: Security Update for Microsoft Excel 2016 - Excel 2016 - KB5002820 (Superseded)"

Setting _BESRelay_Download_UntrustedSites=1 does resolve the issue, but we don't want to have this setting enabled. I'm not quite sure what to do — does anyone have any ideas?

2

What version is your BigFix deployment, and what version is your gathered BES Support site? For reference, my BES Support is at version 1,506 and I'm not able to reproduce your problem downloading from that URL.

Knowing that we may update the list of root certificates by propagating the BES Support site, I wonder whether you may need to gather a site version to get an updated list of Root Authorities to trust Microsoft's new certificates?

3

We're running 11.0.5.203 and our BES Support site is at 1,507.

Is there some way to check the Root Authorities we currently have and see if that's the issue?

4

There are a few things to check, it can vary based on how you've set up some of the custom CA settings on the root server. I think Customizing HTTPS for downloads should be a good starting point though.

1 Like
5

Hi @eg2428, It appears that on approximately January 13th, Microsoft may have made a change that introduced this new certificate. I’ve been working a similar issue for another download package. I have a fixlet (https://bigfix.me/fixlet/details/27404) that adds the certificate to the TrustedDownloadCerts folder on your targeted root server or relay or endpoint. I’ve tested this fixlet in 2 separate BigFix v11.0.5 environments and it appears to resolve this issue. You’re more than welcome to see if this alleviates your issue. If it does, I will discuss this issue internally to see if we can incorporate a fix as the majority of our customers will be impacted by this issue given the significance of this download site (download.microsoft.com).

Thanks, Gus.

Task for creating and downloading the Microsoft TLS G2 ECC CA OCSP 02 certificate.bes (4.1 KB)

4 Likes
6

Thank you, it worked! With _BESRelay_Download_UntrustedSites=0, a previously failing download succeeded after we added the new certificate to the root server.

I'll close my support ticket as well, and point them towards your solution. Much appreciated.

1 Like