Best Practices zum Signieren von .NET-Assemblys?

Question

Ich habe eine Lösung, die aus fünf Projekten besteht, die jeweils zu separaten Assemblys kompiliert werden.Im Moment signiere ich sie mit Code, bin mir aber ziemlich sicher, dass ich es falsch mache.Was ist hier die beste Vorgehensweise?

• Unterschreiben Sie jedes mit einem anderen Schlüssel.Stellen Sie sicher, dass die Passwörter unterschiedlich sind
• Unterschreiben Sie jedes mit einem anderen Schlüssel.Verwenden Sie bei Bedarf dasselbe Passwort
• Unterschreiben Sie jeweils mit demselben Schlüssel
• Etwas ganz anderes

Grundsätzlich bin ich mir nicht ganz sicher, was „Signieren“ mit ihnen macht oder welche Best Practices es hier gibt, daher wäre eine allgemeinere Diskussion gut.Das Einzige, was ich wirklich weiß, ist das FxCop schrie mich an, und es war leicht zu beheben, indem man auf das Kontrollkästchen „Diese Assembly signieren“ klickte und mit Visual Studio (2008) eine PFX-Datei generierte.

Answer 1

Wenn Ihr einziges Ziel darin besteht, FxCop davon abzuhalten, Sie anzuschreien, dann haben Sie die beste Vorgehensweise gefunden.

Die beste Vorgehensweise für die Unterzeichnung Ihrer Versammlungen hängt vollständig von Ihren Zielen und Bedürfnissen ab.Wir benötigen weitere Informationen wie Ihren geplanten Einsatz:

• Für den persönlichen Gebrauch
• Zur Verwendung auf Firmennetzwerk-PCs als Client-Anwendung
• Läuft auf einem Webserver
• Läuft in SQL Server
• Über das Internet heruntergeladen
• Verkauft auf einer CD in Schrumpffolie
• Direkt in ein kybernetisches Gehirn hochgeladen
• Usw.

Im Allgemeinen verwenden Sie Code-Signierung, um zu überprüfen, ob die Assemblys von einer bestimmten vertrauenswürdigen Quelle stammen und nicht geändert wurden. Also ist jeder mit dem gleichen Schlüssel in Ordnung. Wie dieses Vertrauen und diese Identität bestimmt werden, ist eine andere Geschichte.

AKTUALISIEREN: Welche Vorteile dies Ihren Endbenutzern bei der Bereitstellung über das Internet bietet, erfahren Sie, wenn Sie eine erworben haben Softwaresignaturzertifikat von einer Zertifizierungsstelle.Wenn sie dann Ihre Baugruppen herunterladen, können sie überprüfen, woher sie stammen Domenics Software Emporium, und sie wurden im Laufe der Zeit weder geändert noch beschädigt.Sie sollten das Installationsprogramm auch signieren, wenn es heruntergeladen wird.Dies verhindert die Warnung einiger Browser, dass die Datei von einer unbekannten Quelle stammt.

Beachten Sie, dass Sie für ein Software-Signaturzertifikat bezahlen.Was Sie erhalten, ist, dass die Zertifizierungsstelle zum vertrauenswürdigen Dritten wird, der überprüft, dass Sie der sind, für den Sie sich ausgeben.Dies funktioniert aufgrund eines Web of Trust, das bis zu einem Stammzertifikat zurückverfolgt, das in ihrem Betriebssystem installiert ist.Es stehen einige Zertifizierungsstellen zur Auswahl, Sie sollten jedoch sicherstellen, dass diese von den Stammzertifikaten auf dem Zielbetriebssystem unterstützt werden.

Answer 2

Der offensichtlichste Unterschied zwischen signierten und nicht signierten Assemblys besteht in einer ClickOnce-Anwendung.Wenn Sie es nicht signieren, erhalten Benutzer beim ersten Ausführen Ihrer Anwendung eine beängstigende Warnmeldung „Unbekannter Herausgeber“.Wenn Sie es mit a unterschrieben haben Zertifikat von einer vertrauenswürdigen Stelle, dann sehen sie einen Dialog, der weniger gruselig ist.Soweit ich weiß, hat das Signieren mit einem selbst generierten Zertifikat keinen Einfluss auf die Warnung „Unbekannter Herausgeber“. Sofortiges SSL von Comodo enthält Beispiele für die Dialoge.

Es gibt einige subtilere Unterschiede.Sie müssen eine Assembly signieren, bevor sie im globalen Assembly-Cache (GAC) installiert werden kann, wo sie von mehreren Anwendungen gemeinsam genutzt werden kann.Das Signieren ist ein wesentlicher Bestandteil der Codezugriffssicherheit (CAS), aber ich habe niemanden gefunden, der CAS zum Laufen bringen könnte.Ich bin mir ziemlich sicher, dass sowohl GAC als auch CAS mit Zertifikaten, die Sie selbst erstellen, gut funktionieren.

Answer 3

Dies ist hilfreich, da die ausführbare Datei eine Assembly mit starkem Namen erwartet.Es verhindert, dass jemand in böswilliger Absicht eine Ihrer Versammlungen in einer anderen Versammlung ersetzt.Außerdem kann der Benutzer einer Assembly CAS-Berechtigungen basierend auf dem starken Namen erteilen.

Ich denke nicht, dass Sie die .pfx-Datei verteilen sollten, Sie bewahren sie sicher auf, um die Assembly aufzugeben.

Answer 4

Es ist wichtig, Ihre PFX-Datei geheim zu halten, da sie den privaten Schlüssel enthält.

Wenn dieser Schlüssel anderen zugänglich gemacht wird, kann jeder Assemblys oder Programme signieren, die sich als Sie ausgeben.

Um Ihren Namen mit Ihren Assemblys zu verknüpfen (in den Augen von Windows), müssen Sie ein digitales Zertifikat (den Teil der PFX-Datei, der Ihren Namen enthält) von einer vertrauenswürdigen Stelle signieren lassen.

Tatsächlich erhalten Sie ein neues Zertifikat, jedoch mit den gleichen Informationen.

Sie müssen für dieses Zertifikat bezahlen (wahrscheinlich jährlich), aber das Zertifizierungsstelle wird effektiv für Ihre Existenz bürgen (nachdem Sie ihnen Kopien Ihres Reisepasses oder Führerscheins und eine inländische Rechnung gefaxt haben).

Answer 5

Die Signatur wird verwendet, um eine Baugruppe eindeutig zu identifizieren.Weitere Details finden Sie hier Wie man:Unterzeichnen einer Baugruppe (Visual Studio).

Im Sinne einer bewährten Methode ist es in Ordnung, denselben Schlüssel zu verwenden, solange die Baugruppen unterschiedliche Namen haben.