Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Certificate error on https://nuget.smbsrc.net #6082

Closed
FeodorFitsner opened this issue Oct 23, 2017 · 30 comments
Closed

Certificate error on https://nuget.smbsrc.net #6082

FeodorFitsner opened this issue Oct 23, 2017 · 30 comments
Labels
Functionality:Push Priority:1 High priority issues that must be resolved in the current sprint.
Milestone

Comments

@FeodorFitsner
Copy link

Getting an error while pushing symbols package with NuGet 4.1 command-line client on Windows:

An error was encountered when fetching 'PUT https://nuget.smbsrc.net/'. The request will now be retried.
An error occurred while sending the request.
  The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.
  The remote certificate is invalid according to the validation procedure.

Opening https://nuget.smbsrc.net in the browser confirms the problem with certificate.

@mishra14
Copy link
Contributor

cc @skofman1

@anangaur
Copy link
Member

@FeodorFitsner, thanks for letting us know. We have passed on this information/feedback to SymbolSource.org.

aaronpowell added a commit to aaronpowell/Chauffeur that referenced this issue Oct 24, 2017
@fredericDelaporte
Copy link

fredericDelaporte commented Oct 26, 2017

As written here, it is possible to work around this certificate expiration by going through http instead...

nuget push dist/MyPackage.1.0.0.symbols.nupkg -Source http://nuget.smbsrc.net  -ApiKey [my key]

Of course this then means the thing goes un-encrypted over the Internet, likely the API key too. (Unless some application level ciphering is done by NuGet on it.)

@FeodorFitsner
Copy link
Author

Is there any update guys? I can't believe installing a new certificate could take so long. Is there any way to approach SymbolSource.org maintainers directly?

@pavkam
Copy link

pavkam commented Oct 29, 2017

Still errs out. Any progress?

@rrelyea
Copy link
Contributor

rrelyea commented Oct 30, 2017

We have passed this info to the symbolsource folks, but haven't gotten a response.

@rrelyea rrelyea added this to the Backlog milestone Oct 30, 2017
@rrelyea rrelyea added the Priority:1 High priority issues that must be resolved in the current sprint. label Oct 30, 2017
@mishra14
Copy link
Contributor

Folks, please see #6101 for a potential fix to this problem.

@anangaur
Copy link
Member

@mishra14 that's not a fix to the problem but rather a way out to not fail CI builds on secondary push to SymbolSource.
However, the auto-push experience is not right especially in failure scenarios. There is another proposal to disintegrate the current overloaded push to just do an atomic operation of pushing packages to one source: #6113
If we implement #6113, I feel #6101 would no longer be required.

@FeodorFitsner
Copy link
Author

Looks like the certificate was updated.

@anangaur
Copy link
Member

anangaur commented Nov 9, 2017

Closing this issue now as the cert was renewed. Nevetheless, we plan to stop auto-push of packages to SymbolSource as announced here: NuGet/Announcements#13

@anangaur anangaur closed this as completed Nov 9, 2017
@evadelnuevo
Copy link

It seems the certificate expired again

@bilal-fazlani
Copy link

It's expired again

@FeodorFitsner
Copy link
Author

Yep, publishing of symbol packages from AppVeyor builds is not working.

@skofman1
Copy link
Contributor

skofman1 commented Dec 4, 2018

If you are publishing portable PDBs take a look at the NuGet hosted Symbol server: https://blog.nuget.org/20181116/Improved-debugging-experience-with-the-NuGet-org-symbol-server-and-snupkg.html

@CarlosLanderas
Copy link

We are having trouble as well

@unaizorrilla
Copy link

One year later, certificate is expired again....

jweber added a commit to jweber/SlackBotNet that referenced this issue Dec 8, 2018
@yevhen
Copy link

yevhen commented Dec 12, 2018

C'mon ((

@JoshClose
Copy link

Use @skofman1's suggestion. That worked for me.

@FeodorFitsner
Copy link
Author

@skofman1 Am I correct to assume .snupkg is doable from/with VS 2017 only or is it the latest nuget.exe that works with VS 2015 too?

@skofman1
Copy link
Contributor

@FeodorFitsner , the blog provides all the details on this. You will need to build your code using VS 2017 15.9 to generate the PDBs. There were changes to the compiler in 15.9 that are required.

@FeodorFitsner
Copy link
Author

OK, what about VS 2015 support with "old" symbol packages?

@JoshClose
Copy link

I'm using VS 2015 but building with dotnet pack using the latest dotnet core.

@FeodorFitsner
Copy link
Author

Right, but I'm talking about "traditional" .NET Framework apps.

@JoshClose
Copy link

I build netstandard2.0 and net 45 using dotnet pack

<TargetFrameworks>netstandard2.0;net45</TargetFrameworks>

leekelleher added a commit to skttl/umbraco-doc-type-grid-editor that referenced this issue Dec 13, 2018
Apparently the SSL certificate for SymbolSource has expired, throwing a
build error for our NuGet deploy.
 re: NuGet/Home#6082 (comment)
leekelleher added a commit to umco/umbraco-stacked-content that referenced this issue Dec 13, 2018
Apparently the SSL certificate for SymbolSource has expired, throwing a
build error for our NuGet deploy.
 re: NuGet/Home#6082 (comment)
leekelleher added a commit to umco/umbraco-vorto that referenced this issue Dec 13, 2018
Apparently the SSL certificate for SymbolSource has expired, throwing a
build error for our NuGet deploy.
 re: NuGet/Home#6082 (comment)
RomainMuller added a commit to aws/jsii that referenced this issue Sep 30, 2019
The legacy format is not supported by NuGet's own symbols server, and the
SymbolSource server is currently experiencing a certificate expiration event,
which seems to be a somewhat recurring issue (NuGet/Home#6082).

More info: https://docs.microsoft.com/en-us/nuget/create-packages/symbol-packages-snupkg
mergify bot pushed a commit to aws/jsii that referenced this issue Sep 30, 2019
The legacy format is not supported by NuGet's own symbols server, and the
SymbolSource server is currently experiencing a certificate expiration event,
which seems to be a somewhat recurring issue (NuGet/Home#6082).

More info: https://docs.microsoft.com/en-us/nuget/create-packages/symbol-packages-snupkg
RomainMuller added a commit to aws/jsii that referenced this issue Sep 30, 2019
The legacy format is not supported by NuGet's own symbols server, and the
SymbolSource server is currently experiencing a certificate expiration event,
which seems to be a somewhat recurring issue (NuGet/Home#6082).

More info: https://docs.microsoft.com/en-us/nuget/create-packages/symbol-packages-snupkg
RomainMuller added a commit to aws/jsii that referenced this issue Sep 30, 2019
The legacy format is not supported by NuGet's own symbols server, and the
SymbolSource server is currently experiencing a certificate expiration event,
which seems to be a somewhat recurring issue (NuGet/Home#6082).

More info: https://docs.microsoft.com/en-us/nuget/create-packages/symbol-packages-snupkg
@weitzhandler
Copy link

Same problem here.

@fredericDelaporte
Copy link

In other words, the certificate has expired again. That is the third time it expires without being renewed on time. Isn't this slightly deceptive?

@anangaur
Copy link
Member

anangaur commented Oct 2, 2019

@FeodorFitsner
Copy link
Author

...and if you are deploying from AppVeyor .snupkg publishing was implemented in AppVeyor long time ago.

@fredericDelaporte
Copy link

@anangaur, @FeodorFitsner , the new symbol system is very likely to be well known by most people here, and that is not the subject.

Letting a certificate expiring without renewing it is no way of obsoleting a feature previous version.
Beside, there is also legacy versions of software which may need some new release, notably for fixing security issues, while the code base of those legacy versions is very likely not updated to be able to publish snupkg.

@FeodorFitsner
Copy link
Author

@fredericDelaporte I agree. I'm not sure I understand who is standing behind that web site, who is responsible for its maintenance?

aniongithub added a commit to aniongithub/devcontainer-tools that referenced this issue Oct 22, 2019
Poltuu added a commit to Poltuu/KeySmith that referenced this issue Oct 22, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Functionality:Push Priority:1 High priority issues that must be resolved in the current sprint.
Projects
None yet
Development

No branches or pull requests