*.azureedge.net certificate is expired
Closed this issue · 18 comments
Prerequisites
- Write a descriptive title.
- Make sure you are able to repro it on the latest version
- Search the existing issues.
Steps to reproduce
Cannot install nuget since the certificate is expired.
Expected behavior
Moduled installedActual behavior
Install-PackageProvider : Failed to bootstrap providerError details
WARNING: Unable to download from URI 'https://onegetcdn.azureedge.net/providers/nuget-2.8.5.208.package.swidtag' to ''.
WARNING: Unable to download from URI 'https://onegetcdn.azureedge.net/providers/nuget-2.8.5.207.package.swidtag' to ''.
WARNING: Unable to download from URI 'https://onegetcdn.azureedge.net/providers/nuget-2.8.5.206.package.swidtag' to ''.
WARNING: Unable to download from URI 'https://onegetcdn.azureedge.net/providers/nuget-2.8.5.205.package.swidtag' to ''.
WARNING: Unable to download from URI 'https://onegetcdn.azureedge.net/providers/nuget-2.8.5.204.package.swidtag' to ''.
WARNING: Unable to download from URI 'https://onegetcdn.azureedge.net/providers/nuget-2.8.5.202.package.swidtag' to ''.
WARNING: Unable to download from URI 'https://onegetcdn.azureedge.net/providers/nuget-2.8.5.201.package.swidtag' to ''.
WARNING: Unable to download from URI 'https://onegetcdn.azureedge.net/providers/nuget-2.8.5.127.package.swidtag' to ''.
WARNING: Unable to download from URI 'https://onegetcdn.azureedge.net/providers/nuget-2.8.5.122.package.swidtag' to ''.
WARNING: Unable to download from URI 'https://onegetcdn.azureedge.net/providers/nuget-2.8.5.101.package.swidtag' to ''.
WARNING: Unable to download from URI 'https://onegetcdn.azureedge.net/providers/nuget-2.8.5.24.package.swidtag' to ''.
WARNING: Unable to download from URI 'https://onegetcdn.azureedge.net/providers/Microsoft.PackageManagement.NuGetProvider-2.8.5.208.dll'
to ''.
PackageManagement\Install-PackageProvider : Failed to bootstrap provider
'https://cdn.oneget.org/providers/nuget-2.8.5.208.package.swidtag'.
At C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\1.0.0.1\PSModule.psm1:7468 char:21
+ ... $null = PackageManagement\Install-PackageProvider -Name $script:N ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (https://cdn.one...package.swidtag:String) [Install-PackageProvider], Exception
+ FullyQualifiedErrorId : FailedProviderBootstrap,Microsoft.PowerShell.PackageManagement.Cmdlets.InstallPackageProvider
PackageManagement\Import-PackageProvider : No match was found for the specified search criteria and provider name 'NuGet'. Try
'Get-PackageProvider -ListAvailable' to see if the provider exists on the system.
At C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\1.0.0.1\PSModule.psm1:7474 char:21
+ ... $null = PackageManagement\Import-PackageProvider -Name $script:Nu ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidData: (NuGet:String) [Import-PackageProvider], Exception
+ FullyQualifiedErrorId : NoMatchFoundForCriteria,Microsoft.PowerShell.PackageManagement.Cmdlets.ImportPackageProvideEnvironment data
Name Value
---- -----
PSVersion 5.1.26100.4768
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.26100.4768
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1Version
v2
Visuals
No response
Experiencing the same issue.
Same here
Same issue here
We have been chatting about this in the PowerShell Discord and this should auto-correct itself.
You can
- Update your clock as to bypass the time issue on the cert. Retry and then change the clock back
- you can do this using the
Set-Datecmdlet and thisSet-Date -Date (Get-Date).AddHours(-5)& then to set it back doSet-Date -Date (Get-Date).AddHours(5)
- you can do this using the
- Make use of PSResourceGet instead of PowerShellGet to download modules, as this will be the replacement for PowerShellGet & doesn't have this issue & is recommended going forward (even if it's not a native module at this time)
- You can read more on the PowerShell Blog about PSResourceGet & on the official docs pages too if you have not heard of this or have started using it.
FYI on this @SydneyhSmith @anamnavi
Hey, thanks for the update. I am using ansible to deploy windows servers 2025 (fresh installations) with winrm. It's a huge pain to configure powershell 7 to work with that. Do you have an ETA on the auto-correction?
@formax68 unfortunately I am not on the team (but work closely with them) so can't really say on any ETA sorry.
PSResourceGet doesn't need PowerShell 7 & works fine with PowerShell 5.1 but I totally get the pains of needing to mess around with this in automated deployments like this.
I did update the above comment with another work around which should be usable in Automated deployments, even if it is annoying to need these extra steps at the moment.
Hey @kilasuit, not a problem and thanks a lot for keeping me updated. I could install PSResourceGet on 5.1, but I need Nuget and we are back at square 1 🥲
This is a fresh installation of Server 2025 so nothing is there.
Unless there is a fix within the next few hours, I will just create my own repo and copy the modules manually.
I can confirm previous comment, so the workaround is not working for us. Hopefully someone is creating a new certificate soon.
I am setting up a batch of new computers with the WindowsAutopilotInfo powershell command, which requires nuget to install. I successfully worked around the certificate error impacting nuget, by setting my system time back a day as suggested above.
Not another bug here for PowerShellGallery :(
@formax68 that's becasue you are trying to use Install-Module here & sorry for not replying quicker as I got distracted with other in person things. Unless of course you further down the line are using install-package from the PackageManagement module to install things from the Nuget.org gallery.
My recommendation atm is to not do this and instead use this snippet
Invoke-WebRequest https://cdn.powershellgallery.com/packages/microsoft.powershell.psresourceget.1.1.1.nupkg -OutFile Temp:\microsoft.powershell.psresourceget.1.1.1.nupkg
Unblock-file Temp:\microsoft.powershell.psresourceget.1.1.1.nupkg
Expand-Archive -Path Temp:\microsoft.powershell.psresourceget.1.1.1.nupkg -DestinationPath Temp:\microsoft.powershell.psresourceget.1.1.1\
Remove-Item Temp:\microsoft.powershell.psresourceget.1.1.1.nupkg
Import-Module Temp:\microsoft.powershell.psresourceget.1.1.1\tools\Microsoft.PowerShell.PSResourceGet.psd1 -Forceand then replace your use of Install-Module with Install-PSResource going forward as this does not rely on the nuget dependency so should allow you to proceed.
This issue should however now be resolved as the team have performed neccessary mitigation actions so the above reccomendation is no longer needed.
Other than I would still recommend looking at moving from using PowerShellGet to PSResourceGet instead.
Still seeing the same expired certificate; is it a CDN issue perhaps?
Hi all, this issue is mitigated now. Our OneGet swidtags started pointing to our old CDN, we mitigated the issue by purging the cache and things seem to be stable. We're working with our CDN provider to see if there were any changes on their side.
There is an update on the required hostnames here:
NOTE: These endpoints have changed. The old endpoints that ended with azureedge.net are no longer supported.
It seems to be fixed now.
CDNs were purged. Confirm if it's resolved now.
Can confirm. Many thanks.
@SydneyhSmith @anamnavi @SteveL-MSFT this issue alone is enough of a reason in my eyes to push the Windows team to allow you to add PSResourceGet and the version of PowerShellGet that proxys commmands to it, into future Windows 10/11 & Server versions & start the process for the Inboxing of PowerShell 7 in Windows as per this discussion & to be able to remove 5.1 & PowerShellGet & PackageManagement modules from Windows too, which once that's done we can remove them from PowerShell too, unless it's decided to do so beforehand.
Also added bonus you could retire the oneget cdn so less maintainence overheads for your already stretched teams