Probleme mit dem signieren eines Assemblys

Question

allo NG,

ich habe mein Projekt auf einen andern Computer übertragen.

Nun bekomme ich immer die Fehlermeldung:

 BibManthey.pfx. Die Schlüsseldatei ist möglicherweise kennwortgeschützt. Importieren Sie das Zertifikat erneut, oder Installieren Sie das Zertifikat mit dem folgenden Schlüsselcontainernamen im CSP mit starkem Namen, um das Problem zu beheben: "VS_KEY_FAEE60FE46C82D64"  

Ich habe den Schlüssel schon installiert denke ich ich habe jedenfalls doppelt auf den Schlüssel geklickt und der Zertifikat import Assisten hat sich geöffent.



Danke für jeden Hiweis und Tipp.


Grüße  Ingo

Answer 1

Hallo Ingo,

Du hast die PFX-Datei und das Zugangspasswort. Gut. Lösche die Datei aus den Projekteinstellungen, bereinige und speichere das Projekt. Dann geh' wieder zum Reiter "Signierung", klicke auf "Durchsuchen..." und wähle Deine PFX-Datei erneut aus. Erstelle das Projekt neu.

Manchmal hilft es auch, das Passwort über die Schaltfläche 'Kennwort ändern...' in den Projekteinstellungen abzuändern (gleiches Passwort nochmals eingeben).

Wenn das nicht funktioniert, erstelle den Schlüsselcontainer manuell. Wechsle dazu in das Verzeichnis in dem sich die PFX-Datei befindet und gebe folgenden Befehl ein:

sn -i BibManthey.pfx VS_KEY_FAEE60FE46C82D64

[Bist Du denn als Administrator angemeldet und führst VS als Administrator aus? Auf welchem Betriebsystem bzw. mit welcher VS-Version arbeitest Du? Was ist das für eine PFX-Datei (autom. von VS erstellt oder ein exportiertes Zertifikat)?]

P.S. Die PFX-Datei ist nur ein geschützter Container für das Schlüsselpaar (etwas sicherer als eine SNK-Datei). Das Importieren in den Zertifikatsspeicher macht keinen Sinn. Du kannst das importierte Pseudozertifikat (erkennbar über das Datum, bzw. über die GUIDS statt "Ausgestellt für" und "Ausgestellt von" im Zertifikatmanager certmgr.msc) wieder löschen.

Gruß
Marcel

Answer 2

Hallo Marcel,

 

zuerst einmla Dank für die Info werde es gleich morgen testen.

Es handelt sich um Windwos 7 x86  und VS2010.

 

Grüße Ingo

 

Answer 3

Die Datei hatte ic hvor Jahren mit VS2003 erstellt.

Answer 4

Hallo, mal eine Frage, ich hab dasselbe Problem bzw. mittlerweile ein ähnliches, wo liegt denn bitte SN? Bei mir sagt CMD immer, er kennt das nicht... sn gibt es nicht...

Hatte auch versucht zu bereinigen und das Projekt neu zu erstellen, jetzt sagt er mir, ich hätte einen ungültigen Anbietertyp angegeben...

Also die pfx ist passwortgeschützt, mein Rechner vetraut ihr und ich habe damit auch schon Powershellscripte signiert, 

ist für Codesignatur und digitalSignatur... Verstehe das Problem langsam überhaupt nicht mehr...

Dazu eine Idee?

___

Edit: Strong Nametool ok, gefunden, Visual Studio Shell dann läuft das auch, aber die Nachricht über den ungültigen Anbietertyp kommt da dann auch wieder.... grmpf... 

Answer 5

Hallo Nicolai,

PFX-Dateien in Visual Studio werden nur als sichere Container für das kryptographische Schlüsselpaar verwendet (im Unterschied zu den SNK-Dateien, die ungeschützt sind). Aber PFX-Dateien können an sich alles mögliche enthalten, z.B. auch Zertifikate. Ich vermute, dass genau das dein Fall ist (denn: einem Schlüsselpaar kann man nicht vertrauen, nur bei Zertifikaten ist das möglich).

Nun ist es aber leider so, dass Visual Studio keine starken Namen aufgrund von Zertifikaten erstellen kann, alles was es will ist ein kryptographisches Schlüsselpaar.

Siehe dazu auch mein Problembericht auf Microsoft Connect. Andreas Klein hatte damals dankenswerterweise ein Workaround gefunden, vielleicht hilft dir das auch. Aber - verzeih mir die Frage - warum möchtest Du deine Assembly mit einem Zertifikat signieren? Möchtest Du nicht vielleicht eher Authenticode verwenden um die Software als vertrauenswürdiger Herausgeber zu signieren (signtool.exe sign /n <Subject-Name aus dem Zertifikat>  <Assembly>)?

Gruß

Marcel

Answer 6

Siehe dazu auch mein Problembericht auf Microsoft Connect. Andreas Klein hatte damals dankenswerterweise ein Workaround gefunden, vielleicht hilft dir das auch. Aber - verzeih mir die Frage - warum möchtest Du deine Assembly mit einem Zertifikat signieren? Möchtest Du nicht vielleicht eher Authenticode verwenden um die Software als vertrauenswürdiger Herausgeber zu signieren (signtool.exe sign /n <Subject-Name aus dem Zertifikat>  <Assembly>)?

Gruß

Marcel

Ja, ich glaube auch! :-D

        Jetzt bin ich schon zu Hause, das mit dem Signtool werde ich Dienstag gleich mal checken. 

        Hatte sogar einen Entwickler gefragt, dem war da der Unterschied genauso wenig klar wie mir.. :-(

        Vielen Dank für die Hilfe, ich werde (spätestens) Dienstag berichten, wie es glelaufen ist. :-D

        

Answer 7

Im Visual Studio 2010 kann man in der Signing-Reiterkarte der Projekteigenschaften “New” auswählen und es wird eine neue Schlüsseldatei generiert.

 

--
Viele Gruesse
Peter

Answer 8

Jetzt bin ich schon zu Hause, das mit dem Signtool werde ich Dienstag gleich mal checken. 

Hatte sogar einen Entwickler gefragt, dem war da der Unterschied genauso wenig klar wie mir.. :-(

Es gibt bezogen auf das .NET-Framework zwei Arten von Signaturen:

1. Strong-Name-Signatur: Ein kryptographisches Schlüsselpaar wird erzeugt (über sn.exe oder den Projekteigenschaften-Editor). Bei der Signierung wird ein SHA1-Hash der Assembly berechnet und mit dem privaten Schlüssel verschlüsselt. Der Hash und der öffentliche Schlüssel werden in der Assembly eingebettet. Von nun an ist der Hash Teil der Identität der Assembly. Weil sie eindeutig identifizierbar ist, kann die Assembly im GAC installiert werden und sie kann über das InternalsVisibleToAttribute als "befreundete" Assembly eingesetzt werden. In früheren .NET-Versionen spielte der starke Name eine wesentliche Rolle bei der Integritätsüberprüfung, in .NET 4.0 wurde die Integriätsüberprüfung u.a. aus Performanzgründen ausgesetzt. Der Hash wird beim Signieren Teil des voll qualifizierten Names der Assembly, das ist es worum es dabei geht. Bei der Strong-Name-Signatur geht es also primär um die IDENTITÄT einer Assembly.

2. Authenticode-Signatur: Eine Authenticode-Signatur (über signtool.exe) assoziiert ein authentifiziertes Softwareherstellerzertifikat mit einer Software. Das Zertifikat enthält zwar auch ein Schlüsselpaar, und auch hier wird ein Hash berechnet und mit dem privaten Schlüssel aus dem Zertifikat verschlüsselt, aber die signierte Software enthält weiterführende Informationen über den Softwarehersteller in Form eines eingebetteten Zertifikats. Das Zertifikat wurde von einer CA (certificate authority) ausgestellt und ermöglicht die Bildung und Überprüfung einer Vertrauenskette. Bei der Authenticode-Signatur geht es also primär um AUTHENTIFIZIERUNG, VERTRAUEN und INTEGRITÄT der Daten.

Answer 9

Sorry, bin erst jetzt zum erneuten Testen gekommen,

also, das mit dem Signtool hat wunderbar geklappt, ich kann die .dll zur .vsto signieren, das macht er auch, aber wenn ich die .vsto

installieren will:

meinAddin.vsto /i /s 

klagt er über den unbekannten Verleger, ich habe das Zertifikat importiert (unter eigene, vertrauenswürdige Stamm, vertrauenswürdige Herausgeber, vertrauenswürdige Personen in der Reihenfolge), aber der Verleger bleibt unbekannt. Also das ist doch wirklich lächerlich so langsam.. :-D

Ich hab das fast in jedem Bereich bei Zertifikaten eingefügt, der nach Vertrauen klingt und der "Herausgeber" ist immer noch unbekannt.. 

Könnt ihr mir da noch mal weiterhelfen??

Answer 10

Hallo Nicolai,

Was ist das für ein Zertifikat? Ist das ein selbst signiertes (z.B. über makecert/openssl/crypto4pki)? - Dann ist es nur normal, dass der Verleger unbekannt ist: Du bist ja in diesem Fall sowohl der Aussteller (CA) als auch derjenige für den das Zertifikat erstellt wurde. Von Sicherheit kann hier nicht mehr gesprochen werden (man könnte genausogut den Bock zum Gärtner machen).

Aus der Dokumentation: "You should never use this [test] certificate for actual deployment of a Visual Studio Tools for Office solution. Request a certificate from a certificate authority trusted by both you and the user or request a certificate from one of the well-known commercial certificate authorities."

Das bedeutet also, dass Testzertifikate beim Deployment nicht wie gewünscht funktionieren werden. Dazu mußt Du schon ein richtiges code signing-Zertificat von einer Zertifikatsauthorität erwerben. Ein Zertifikat kostet auch nicht mehr die Welt.

Gruß

Marcel

Answer 11

Das Zertifikat kommt unserer Domain-Zertstelle, die ist intern, aber überall als Vertrauenswürdig angegeben, der Herausgeber bin dann ja ich und es kommt von einer vertrauenswürdigen stelle... (Herausgeber == Verleger?? und wenn ich das Zertifikat importiere dann müsste er es doch akzeptieren..)

Deswegen habe ich in der Firmeninternen CA ein Codesigning Zert erstellt, angefordert, und Passwortgeschützt Exportiert, hiermit würde ich gerne Firmen-Anwendungen aller Art signieren, so dass man eine gewisse Grundsicherheit hat.

Es geht ja darum, das ich für unsere AD-Domäne, Scripts, AddIns und selber Programmierte Tools gerne etwas sicherer machen würde auf lange Sicht. Ich kann das Outlook Addin auch einfach in einen vorgegeben Ordner kopieren und diesen Per Regkey Als vertrauenswürdig angeben, aber das ist ja auch etwas albern, sicherheitstechnisch ist das ein Witz...

Ich kann die Powershell theoretisch "scharf schalten", so dass Sie nur noch signierte Scripts akzeptiert, das würde jetzt schon gehen.

Und ich hätte es gerne, dass ich in MS-Office die Makrosicherheit auch hochregeln kann, dann wäre sichergestellt, dass hier keine Fremdmakros laufen (zumindest, wäre das doch deutlich erschwert). 

Ich bezweifel, dass hier irgendwer Interesse hat, für unsere Paar Makros ein Zertifikat zu kaufen, dass muss doch eigentlich auch mit der MS-Eigenen CA laufen... 

MfG

Answer 12

Mach doch bitte einen neuen Thread auf, sonst kommt die Diskussion hier noch ganz durcheinander und keiner blickt mehr durch.

Schildere dein Problem so genau wie möglich (ich erfahre z.B. erst jetzt von dir, dass es um ein firmenintern zu deployendes Outlook-VSTO-Addin geht!) und gib bitte auch unbedingt die Versionen deiner Tools an: .NET Framework, VSTO, Betriebsystem, Office.

Auch wäre es nett zu erfahren, ob Du außer Authenticodesignierung über signtool.exe der Assembly einen starken Namen gegeben hast und ob Du (abh. von Office-Version) auch das Manifest signiert hast.

Interessant wäre ferner zu wissen, ob - wenn Du dir das Zertifikat im Zertifikatmanager ansiehst - dem ganzen Zertifizierungspfad vertraut wird.

Den Vorgesetzten würde ich fragen, ob er seinen Namen als Herausgebernamen des selbst signierten Zertifikats verwenden würde: Da wäre Verantwortung doch wieder nahe beim Verantwortlichen. So wie es eigentlich sein sollte ;-)

Marcel

Answer 13

http://social.msdn.microsoft.com/Forums/de-DE/visualcsharpde/thread/1883d036-a0e7-49f0-adf7-e22fb7b16877

Ich weiß nicht mal was ein starker Name ist, das Manifest habe ich versucht mit mage.exe zu signieren... aber im Neuen Thread ist alles detailiert angegeben, mittlerweile haben die Fehlermeldungen ja kaum noch was mit diesem Problem hier zu tun, da habt ihr mir ja sehr schnell geholfen. :-)