Warum verwenden Sie SSL für die NuGet-repository?
Hatten wir ein Problem mit unserer automatisierten build-Maschine von gestern. Wir sind mit einem TFS-Build-server, und wenn es versucht automatisch herunterladen NuGet-Pakete haben wir die berühmt-berüchtigte "Die zugrunde liegende Verbindung wurde geschlossen: Konnte keine Vertrauensstellung für den sicheren SSL/TLS-Kanal" Fehler.
Gibt es eine Menge threads rund um die 'net über, warum dies geschieht. Das ist nicht meine Frage. Es kann behoben werden, leicht genug, indem Sie Ihre NuGet-repository von
https://nuget.org/api/v2/
zu
http://nuget.org/api/v2/
oder
http://packages.nuget.org/v1/FeedService.svc/
Was ich wissen möchte ist, warum das repository wird mithilfe von SSL in den ersten Platz? Ich nehme an, es ist es für einen Grund, aber ich kann nicht herausfinden, was. Es ist keine Anmeldung erfordern würde, dass die Sicherheit. Ich kann nicht glauben, dass irgendwelche Informationen gesendet, die Sie brauchen würden, um sicher zu sein. Ich möchte nur sicherstellen, dass durch die Verwendung einer ungesicherten Verbindung (die funktioniert Prima) wir sind nicht irgendwie dass wir unsere build-Maschine.
Kann mir jemand erklären, was ist gewonnen, wenn eine Verbindung zu NuGet über eine gesicherte Verbindung?
Du musst angemeldet sein, um einen Kommentar abzugeben.
Ist es nicht unbedingt, weil die Informationen, die Sie mit nuget.org enthält alles, was geheim und somit muss sicher sein. Durch die Verwendung von SSL verwenden, werden Sie sicher sein, dass es tatsächlich ist nuget.org Sie reden mit. Ohne SSL, jemand könnte in der Theorie sein, die Fütterung kann man gefälschte Pakete, und das könnte ein Sicherheitsproblem sein.
Als für das Problem, das Sie erlebt haben mit "es Konnte keine Vertrauensstellung für den sicheren SSL/TLS-Kanal", wir hatten ein ähnliches problem, wenn wir begonnen haben, mit einem neuen build-server:
Wenn man sich das SSL-Zertifikat, das vom https://nuget.org/, der Zertifizierungspfad: GeoTrust Global CA > RapidSSL CA > *.nuget.org
GeoTrust Global CA fehlte als Vertrauenswürdige ZERTIFIZIERUNGSSTELLE auf unserem neuen server zu bauen, so wurde das problem einfach gelöst, indem Sie den build-Server die Liste der vertrauenswürdigen root-CAs (über die MMC-Konsole, mit dem Zertifikate-snap-in).
Update:
Auf einer späteren service, den ich erfahren habe das gleiche SSL-Problem, und das hinzufügen von GeoTrust als Vertrauenswürdige ZERTIFIZIERUNGSSTELLE allein nicht das problem lösen. In neben, war der server auch fehlt der root-CA für https://go.microsoft.com/, die Baltimore CyberTrust Root (gehen Sie zu https://microsoft.com, und Sie werden in der Lage sein zu Ansicht und download des Zertifikats). Das hinzufügen dieser zu der Liste der vertrauenswürdigen root-CAs gelöst, das Problem.