No Match was Found While Installing the NuGet PackageProvider?

This blog will show you what happens when running Install PackageProvider -Name NuGet gives you the “no match was found” error. This time it wasn’t the network or the source. The real issue was a certificate that expired earlier that day. We’re going to zoom in on how PowerShell handles this, why it fails without providing any helpful information, and how to work around it.

No Match Was Found

When enrolling a device with Windows Autopilot, the hardware hash needs to be uploaded. If the vendor didn’t do it for you, you’ll have to handle it yourself. That usually means running:

Install-Script -Name Get-WindowsAutopilotInfo -Force

This installs the script from the PowerShell Gallery, allowing you to use it to export the hardware hash and upload it to Intune automatically with the -online switch.

But this time, it didn’t work. PowerShell threw an error saying the NuGet package provider was missing. So I decided to install the NuGet package provider manually:

Install-PackageProvider -Name NuGet -Force

That’s where it got annoying. Instead of installing NuGet, PowerShell gave a vague warning:

WARNING: Unable to download from URI ‘https://onegetcdn.azureedge.net/providers/nuget-2.8.5.208.package.swidtag’ to ”.

WARNING: Unable to download the list of available providers. Check your internet connection.

Install-PackageProvider: No match was found for the specified search criteria for the provider ‘NuGet’.

There it is. The no match was found error that shows up when something quietly breaks in the background. No real explanation. Just PowerShell refusing to say what actually went wrong. And yes, it had something to do with trust.

Opening the OneGetCDN AzureEdge URL

I opened the OneGetCDN AzureEdge.net URL manually in the browser. The page didn’t load. Just a certificate warning, mentioning that your connection isn’t private.

Besides the usual “your connection is not private” warning, the real reason was just below the error. NET::ERR_CERT_DATE_INVALID.
The certificate had expired. No surprise everything broke but PowerShell never mentioned it. So we Clicked the padlock –> Certificate details.

There it was: the certificate expired today: June 11, 2025, at 2:11 AM.

Issued by Let’s Encrypt, still being served by the CDN. And well… we all know what happens when the certificate isn’t valid,  no communication, no download, nothing. PowerShell didn’t log anything about the cert, it just failed and showed the generic “no match” error.

Confirming with Fiddler

To be sure, I opened Fiddler and ran the same NuGet install command again. Fiddler confirmed it: A required certificate is not within its validity period when verifying against the current system clock.

To ignore the issue, we clicked “Ignore errors and proceed,” and the NuGet Packageprovider downloaded and installed just fine.

The AzureEdge endpoint was reachable. The swidtag file was valid. The only issue was that the certificate had expired a few hours ago, and PowerShell refused to touch it.

If you want to see how Fiddler helps with issues like this, the first Patch N Rant episode covers it:

Skipping the Cert Check in PowerShell

With Fiddler showing me it was possible to download and install the Nuget Packageprovider, I decided to try to create a workaround for PowerShell. As shown below this PowerShell script will bypass the certificate check:

add-type @"
using System.Net;
using System.Security.Cryptography.X509Certificates;
public class TrustAllCertsPolicy : ICertificatePolicy {
    public bool CheckValidationResult(
        ServicePoint srvPoint, X509Certificate certificate,
        WebRequest request, int certificateProblem) {
        return true;
    }
}
"@
[System.Net.ServicePointManager]::CertificatePolicy = New-Object TrustAllCertsPolicy

Then ran: Install-PackageProvider -Name NuGet -Force

This time it worked. Followed by: Install-Script -Name Get-WindowsAutopilotInfo

The Get-WindowsAutopilotInfo Script downloaded, hash collected, device could now be enrolled with Windows Autopilot.

Why we got No match was Found with NuGet

The certificate expired a few hours earlier.

PowerShell uses System.Net.WebRequest. If TLS validation fails, it doesn’t show a proper error, just a vague output like “unable to download” or “no match found for the provider ‘NuGet’.” No hint it was a certificate problem. No TLS warning. Just silence.

Meanwhile, the browser showed the real issue. Fiddler confirmed it. PowerShell? Nothing.

Microsoft Fixing the Certificate

After posting this blog on X and LinkedIn, it seems Azure Support got out of bed and renewed the certificate! As shown below, Microsoft just renewed the Certificate of azureedge.net.

With the Certificate renewed, downloading and installing the nuget packageprovider was no longer ending up with a package was not found error but succeeded!

Wrap-up

If you’re onboarding a device and PowerShell tells you that “no match was found for the provider ‘NuGet’”, don’t trust the message. It might not be a missing package,  it might be an invalid certificate/Certificate Expired.

The browser showed the cert expired. Fiddler caught and handled the TLS failure by ignoring it. PowerShell ignored both and didn’t show a good error.

Temporarily bypassing the certificate check allowed NuGet to install and the script to run. That was enough to complete the onboarding of the device.