Code Signing - Grundsatzfragen

[Ares]

Hallo!

Ich beschäftige mich derzeit mit dem Thema Code Signing. Die Theorie hinter dem Ganzen (was ist ein Zertifikat, wie wird ein "Dokument" signiert, PK, etc.) ist mir bekannt, nur am Verständnis der praktischen Nutzung beim Code Signing fehtl es noch :-)

Den Beitrag zur Erstellung eigener Zertifikate fand ich schon einmal sehr hilfreich. Ein paar Fragen habe ich aber noch:

Mein Ziel:
Ich möchte meine Programme (EXE, DLL aus Delphi und Visual Studio) signieren, damit unter Vista und Windows 7 nicht mehr "Herausgeber: Unbekannt" angezeigt, sondern mein Name verwendet wird.

Da ich auch kleine Programme verkaufe möchte ich nicht mit einem selbst erstellten Zertifikat arbeiten sondern mit einem "richtigen" von einem offiziellem Anbieter. Für diesen Zweck gibt es ja einige Anbieter die jeweils verschiedene Zertifikate im Angebot haben. Dazu direkt die erste Frage:

Frage 1:
Warum gibt es für verschieden Zwecke unterschiedliche Zertifikate? Ein Zertifikat ist doch eigentlich nur die Bestätigung, dass hinter der Signatur XYZ die geprüfte reale Person oder Firma ABC steht. Theoretisch kann ich mit den Schlüsseln eines Zertifikates alles signieren egal ob Worddokument, EXE-Datei oder JPG-Bild. Wo liegt der Unterschied in den Zertifikaten für unterschiedliche Zwecke? Ist das nur Produktpolitik ("Für ein bisschen EXE-Signieren bekommst du das Zertifikat für 300 EUR, wenn mehr signiert wird wirds auch teurer"), oder gibt es dazu einen echten technischen Hintergrund?

Frage 2:
Da verschiedene Zertifikate für verschiedene Zwecke angeboten werden muss ich mir das für meine Zwecke richtige aussuchen. Worauf muss ich dabei achten? Gibt es technische Bedienungen die für den Einsatz "EXE und DLLs signieren" zu beachten sind?

Frage 3:
In einem Dokument von VeriSign (Seite 4) ist zu lesen "Authenticode is currently used to sign 32-bit .exe files...". Heißt dass, dass wirklich nur 32bit EXE Dateien signiert werden können und z.B. 64 Bit EXE Dateien nicht?


Die Preisspannen der verschiedenen Anbieter sind teilweise ja sehr deutlich. Soweit ich verstanden habe ist VeriSign der einzige Anbieter der voll mit Microsoft zusammenarbeitet und daher direkt mit seinem Root-Zertifikat in Windows bekannt ist. Das kann man als Argument für die höheren Preise gelten lassen.

Den Webseiten der Anbieter habe ich folgende Preise pro Jahr entnommen:
VeriSign: 399 EUR (499$)
Thawte: 239 EUR (299$)
Comodo: 166 EUR
Certrum.eu: 135 EUR

Frage 4:
...gibt es zwischen den restlichen Anbietern nennenswerte Unterschiede? Gibt es bei einem "Billiganbieter" irgendwelche Nachteile die man berücksichtigen sollte?


Ich habe mir unter einem frischen Windows 7 im Internet Explorer (Internetoptionen\Inhalte\Zertifikate\Vertrausenwü rde Stammzertifizierungstellen) die liste der vorhanden Stammzertifikate angeschaut. Neben verschiedenen Einträgen von Microsoft und VeriSign sind hier auch Einträge von CyberTrust und Thawte enthalten.

Frage 5:
Heißen die Einträge in der Liste der Stammzertifikate, dass CyberTrust und Thawte den gleichen Vorteil haben wie VeriSign?

Frage 6:
Das Zertrifikat von Thawte ist eingetragen als "Zeitstempel". Was hat es damit auf sich?

Frage 7:
Nachdem ich mir das Zertifikat einer EXE angeschaut habe, die mit einem Comodo-Zertifikat signiert ist, stand auch USERTrust (=Comodo) ohne weiteres Zutun in der Liste der Stammzertifikate. Wie ist es dort ohne Nachfrage hinein gekommen? Gehe ich also recht in der Annahme, dass es kein allzu großer Nachteil ist, wenn man einen günstigen Anbieter wählt da dessen Zertifikate bei Bedarf direkt nachgeladen werden?


Frage 8:
Wenn ich mich nun für einen Anbieter entscheide, was erhalte ich dann von diesem? Ich gehe davon aus, dass ich nur eine Datei mit öffentlichem und privaten Schlüssel erhalte so, dass ich dann meine Dateien signieren kann. Oder brauche ich je nach Anbieter spezielle Tools um damit die Signierung durchführen zu können?


(vorerst) Letzte Frage:
Im Moment ist mir Comodo am sympathischen. Hat hiermit jemand konkrete Erfahrungen und kann Vor- und Nachteile nennen?


EDIT: Doch noch eine Frage
Genügen die angebotenen Zertifikate den Anforderungen des Windows Logo Programms?


So, dass soll es erst mal mit Fragen gewesen sein. Schon einmal vielen Dank für die Hilfe!
Ares

[Phoenix]

Zum Vorgehen:
Du erstellst zuerst einen CR (Certificate Request). Das ist ein mit Deinem bei Dir generierten privaten Key signierter Request zusammen mit einem auch von Dir generierten öffentlichen Schlüssel.

Aus diesem erstellt die Stammzertifizierungsstelle dein Zertifikat, Signiert mit ihrem privaten Key (so dass Dein Cert mit deren öffentlichen Schlüssel auf Echtheit geprüft werden kann). Dieses Zertifikat enthält auch Deinen öffentlichen Schlüssel.

Das heisst, also, wenn jemand das Cert. prüft, weiss er, dass Dein öffentlicher Schlüssel zumindest von der Stammzertifizierungsstelle als Deiner geführt wird. Mit Deinem Schlüssel wird dann die Signatur der Datei geprüft, die Du ja mit Deinem privaten Schlüssel machst -> Alles in Butter.

[Bernhard Geyer]

2: Du brauchst Code-Signing nach Microsoft® Authenticode®

3: Geht auch 64-Bit (http://www.verisign.de/code-signing/...ode/index.html)

4: Bei Verisign ist es möglich das bei Anwendungsabstürzen der Callsstack+Umgebung an MS gesendet wird und du es dort abholen kannst um den Fehler nachzuvollziehen. Haben wir bisher nicht gemacht.


5: Wenn die nötigen Root-Zertifikate schon bei "frischen" Windows vorhanden sind das hat du überall die gleichen Vorteile bzgl. Warnmeldung.

8: Die nötigen Tools sind in den SDK's von MS vorhanden. Habe hier das Microsoft Platform SDK for Windows Server 2003 R2 im einsatz (unter Vista). Letztendlich brauchst du die "signtool.exe" welche noch die capicom.dll zieht.

[Ares]

Hallo Phoenix!

Schon mal vielen Dank für die Antwort. Also das Schlüsselpaar wird von mir selbst erstellt und nicht von der Zertifizierungsstelle? Das ist mir schon mal neu. Vielen Dank für den Hinweis.

Die Erstellung des Schlüssels wird dann z.B. mit makecert.exe vorgenommen oder gibt es da besondere Dinge zu beachten?

[Achim Kalwa]

Zitat:

Zitat von Ares

Die Erstellung des Schlüssels wird dann z.B. mit makecert.exe vorgenommen oder gibt es da besondere Dinge zu beachten?

Typischerweise macht das ein Active-X Plugin im Internet-Explorer.
Bei einigen Anbietern geht das wohl auch mit Firefox, aber Comodo unterstützt wohl nur den IE.

Bei Certum.eu wird übrigens öfters mal auf Certum.pl weiter geleitet; ab da musst Du Polnisch können um weiter zu kommen :-( Für mich ein klarer Minuspunkt.

Noch günstiger ist ksoftware.net; ein Reseller von Comodo:
https://secure.ksoftware.net/code_signing.html

Da kostet das benötigte Zertifikat nur 99 US$ für ein Jahr; umrechnen in Euro überlasse ich Dir :-)
Dort habe ich mein Code Signing Certificate bestellt; die gesamte Abwicklung erfolgte aber via Comodo.

Du bekommst eine Datei zurück, die Du gut aufheben solltest :-)

Nach dem Import der Datei in den IE (Zertifikatspeicher) kann man daraus eine PFX-Datei erzeugen (und mit einem Passwort versehen), die dann von SignTool.exe verwendet wird um Deine Exe zu signieren. Dabei muss das zuvor gewählte Password wieder eingegeben werden.

Ich hoffe, das beantwortet schon mal einen Teil Deiner Fragen.

KalwaDOS

[Ares]

Hallo KalwaDOS!

Vielen Dank für deine Antwort! Die Preise von ksoftware.net klingen ja sehr interessant :-)

Das Stammzertifikat von Comodo ist ja nicht automatisch in Windows enthalten. Hast du Erfahrungen damit, wie das Zertifikat dort angezeigt wird? Muss der Nutzer das Zertifikat erst manuell akzeptieren, ein Stammzertifikat-Update installieren oder ähnliches? Oder wird das Zertifikat automatisch (auch in älteren Windows Versionen?) korrekt erkannt und angezeigt?

Gibt es bei diesem "Discount" Zertifikat noch irgendwelche Besonderheiten die man beachten sollte? Oder hast du nur gute Erfahrungen damit gemacht? In dem Fall würde ich die 99$ einfach mal riskieren und versuchen mir die weiteren Fragen in der Praxis selber zu beantworten :-)

Besten Dank
Ares

[Achim Kalwa]

Zitat:

Zitat von Ares

Das Stammzertifikat von Comodo ist ja nicht automatisch in Windows enthalten.

Ist es nicht?
Bei Microsoft ist es aber gelistet:
http://download.microsoft.com/downlo...ber%202009.pdf

Ich werde nachher mal eine frische VM aufsetzen und prüfen, was bei meinen Anwendungen so angezeigt wird.

Updates der Stammzertifikate werden von Microsoft per Windows-Update ausgeliefert.
Man kann das auch manuell nachinstallieren:
http://support.microsoft.com/kb/931125

[rwachtel]

Zitat:

Zitat von Ares

[...] Vielen Dank für deine Antwort! Die Preise von ksoftware.net klingen ja sehr interessant :-) [...]

Noch günstiger (bei gleicher Leistung, da ebenfalls Reseller von Comodo) ist es bei https://author.tucows.com

Nach (kostenfreier) Registrierung als Software-Autor kann man unter Home->Resources->Code Signing Certificates bei Comodo Zertifikate für 75 US$ pro Jahr bestellen (oder 140 US$ für zwei Jahre oder 195 US$ für drei Jahre).

Die Abwicklung geschieht hier genau wie bei ksoftware.net direkt über Comodo.

Ich kann es nur empfehlen - und einen günstigeren Anbieter habe ich bisher auch noch nicht gesehen.

[ak-ac]

ist das dann eingeschränkt für shareware tools oder kann man das auch mit kommerzieller software nutzen? klingt mit der registrierung irgendwie so...

[rwachtel]

Wo klingt das eingeschränkt? Ein Comodo-Zertifikat ist ein Comodo-Zertifikat. Punkt.

[madas]

Als Tipp: Sucht mal bei "Gockel" nach OpenSSL und self signed.

[ak-ac]

Zitat:

Zitat von rwachtel

Wo klingt das eingeschränkt? Ein Comodo-Zertifikat ist ein Comodo-Zertifikat. Punkt.

manchmal gibts doch lieznzbestimmungen nach dem motto, kostenlos nur für private nutzung. dachte nur, dass es das ja auch für nutzung für sharewaretools gibt - weils ja nur per registrierung geht...

[H4ndy]

Zitat:

Zitat von madas

Als Tipp: Sucht mal bei "Gockel" nach OpenSSL und self signed.

Fuer "offizielle" Software kann man keine selbstsignierten Zertifikate nuzten, da das Root-Cert nicht in den Speichern der Anwender ist und somit trotzdem eine Warnung kommt. Sowas kann man fuer Testzwecke mal machen und auf dem eigenen Rechner das generierte Zertifikat installieren. Dafuer braucht man uebrigens auch kein extra OpenSSL, sondern einfach nur die Tool-Suite von Microsoft zur EXE-Signierung.

[madas]

Zitat:

Zitat von H4ndy

Zitat:

Zitat von madas

Als Tipp: Sucht mal bei "Gockel" nach OpenSSL und self signed.

Fuer "offizielle" Software kann man keine selbstsignierten Zertifikate nuzten, da das Root-Cert nicht in den Speichern der Anwender ist und somit trotzdem eine Warnung kommt. Sowas kann man fuer Testzwecke mal machen und auf dem eigenen Rechner das generierte Zertifikat installieren. Dafuer braucht man uebrigens auch kein extra OpenSSL, sondern einfach nur die Tool-Suite von Microsoft zur EXE-Signierung.

Tja dann musste mal richtig suchen. Mit OpenSSL kannste Dein eigenes CA erstellen. Dieses in den Root-Cert Speicher geworfen und schon werden alle
Programme die Du mit deinem Code Signing Zertifikat (das mit dem CA erstellt wurde) signiert hast ohne Warnung ausgeführt.

Grüße.

PS: Das Ganze geht auch für https Zertifikate.

[H4ndy]

Zitat:

Zitat von madas

Tja dann musste mal richtig suchen. Mit OpenSSL kannste Dein eigenes CA erstellen. Dieses in den Root-Cert Speicher geworfen und schon werden alle
Programme die Du mit deinem Code Signing Zertifikat (das mit dem CA erstellt wurde) signiert hast ohne Warnung ausgeführt.

Dein eigenes CA kann auch das MS-Tool ausspucken. Das tut aber nix zur Sache, dass es keine brauchbare Methode ist.
Wenn ich meine EXE signiere, dann soll das auch auf allen Windowsen laufen, OHNE dass man eigenes Rootzertifikate beim User "einschmuggeln" muss. Das ist ja eben der Sinn dahinter, dass die Signierung von einer bekannten Stelle aus zertifikiert wird.

Fuer meinen Webserver hab ich auch alle SSL-Zertifikate selbst erstellt und signiert, aber nur fuer den persoenlichen Gebrauch. Wenn ich was serioeses haben woellte fuer was Leute Geld ausgeben, dann wuerde ich mir auch ein "echtes" SSL-Zertifikat kaufen.

Kurz: Es geht um die Chain of Trust, und die ist bei selbstsignierten Sachen nicht oder nur unzureichend gegeben.

[BUG]

Zitat:

Zitat von H4ndy

Fuer "offizielle" Software kann man keine selbstsignierten Zertifikate nuzten, da das Root-Cert nicht in den Speichern der Anwender ist und somit trotzdem eine Warnung kommt.

Zitat:

Zitat von madas

Dieses in den Root-Cert Speicher geworfen und schon werden alle
Programme die Du mit deinem Code Signing Zertifikat (das mit dem CA erstellt wurde) signiert hast ohne Warnung ausgeführt.

Dass das funktioniert, hat er ja nicht bezweifelt. Man kauft ja Zertifikate, weil die Root-Zertifikate schon auf dem Rechner des Users liegen und vertrauenswürdig sind.

Zitat:

Zitat von madas

PS: Das Ganze geht auch für https Zertifikate.

Wer installiert sich denn Root-Certifikate aus dem Internet, weil eine Website das fordert.
Würden das alle machen, könnte man sich das Signieren auch direkt sparen.

Ist ja nicht so, das Zertifikate erfunden wurden, um Entwickler zu ärgern.

[Grolle]

Hallo,

unter http://www.startssl.com/ bekommt man ein class2 Zertifikat (code signing) für 49 USD für 2 Jahre. In den nächsten Tagen werde ich in meinem Blog ein Tutorial dazu verfassen (Thema ist gerade aktuell - Link folgt).

Viele Grüße ...

[rob74]

Zitat:

Zitat von kalwados (Beitrag 1020989)

Zitat:

Zitat von Ares

Das Stammzertifikat von Comodo ist ja nicht automatisch in Windows enthalten.

Ist es nicht? Bei Microsoft ist es aber gelistet:
http://download.microsoft.com/downlo...ber%202009.pdf

Ich werde nachher mal eine frische VM aufsetzen und prüfen, was bei meinen Anwendungen so angezeigt wird. Updates der Stammzertifikate werden von Microsoft per Windows-Update ausgeliefert. Man kann das auch manuell nachinstallieren:
http://support.microsoft.com/kb/931125

Hallo,

die Frage, welche CAs bei welchen Windows-Versionen default-mäßig "mit dabei" sind, interessiert mich auch brennend. Für die Code-Signierung besonders interessant wäre zu wissen, welche CAs bei Windows Vista "mit ausgeliefert" wurden. Leider liefert die verlinkte PDF-Datei keine Antwort auf diese Frage - da steht zwar, welche CAs schon vor dem Update vorhanden waren, aber nicht seit wann. Ich habe zwar nach älteren Versionen der PDF-Datei gegooglet, aber das älteste was ich gefunden habe war März 2009, alle anderen verlinken nur die Microsoft-Knowledge-Base-Seite, und wenn man den Links folgt landet man auf der aktuellen Version der Seite, nicht auf der "alten". Da hilft scheinbar wirklich nur ein frisches Vista installieren und damit testen...

Erschwerend kommt hinzu, dass die Root-Certificate-Updates zwar per Windows Update ausgeliefert werden, aber leider nur als optionale Updates. Frag' mal ein paar Benutzer, ob sie schon mal optionale Updates installiert haben, die meisten werden gar nicht wissen, wie sie das machen sollen...

Edit: laut http://www.entrust.net/knowledge-bas...te.cfm?tn=7740 lädt Windows Vista ein unbekanntes Root-Zertifikat automatisch nach, wenn es dem Windows-Update-Server bekannt ist, ohne dass der User was davon merkt. Außer natürlich er hat in dem Moment grad keine Internet-Verbindung, oder das Zertifikat-Update wurde vom Administrator deaktiviert, oder oder oder...

[Mschmidt]

Noch ein Tipp - wenn du deine Software bei Microsoft registrieren möchtest
um z.b. Punkte im Partnerprogramm zu erhalten (nur relevant für Unternehmen) oder ein Logo wie "Compatible with Windows 7" u.a.
musst du ein Verisign Zertifikat verwenden :-( Alle anderen werden komischweise nicht akzeptiert.

:-mschmidt

[mkinzler]

Und ein Zertifikat von VeriSign ist mit das teuerste

[Grolle]

Hallo,

wie oben versprochen ein kleines Tutorial zum Thema Code signing mit startssl.

Viele Grüße ...

[PhilmacFLy]

Gigne nicht theoretisch auch ein Zertifikat von Cacert.org? Weil die währen ja kostenlos, du brauchst nur einen Assurer mit genügen Punkten.

[generic]

Zitat:

Zitat von PhilmacFLy (Beitrag 1041551)

Gigne nicht theoretisch auch ein Zertifikat von Cacert.org? Weil die währen ja kostenlos, du brauchst nur einen Assurer mit genügen Punkten.

Ich bezweifele, dass die Root-Zertifikate in Windows sind.

[Assarbad]

Zitat:

Zitat von Mschmidt (Beitrag 1040596)

Noch ein Tipp - wenn du deine Software bei Microsoft registrieren möchtest um z.b. Punkte im Partnerprogramm zu erhalten (nur relevant für Unternehmen) oder ein Logo wie "Compatible with Windows 7" u.a. musst du ein Verisign Zertifikat verwenden :-( Alle anderen werden komischweise nicht akzeptiert.

Guckste bei "signtool.exe verify /kp ..." nach. Auch die Kernel Signing Policy (KP) erfordert VeriSign plus cross-signing mit dem MS-VeriSign-Root-Cert. VeriSign-Zertifikate gibt's derzeit für $99 (ein Jahr, nur erstes Jahr und dennoch nicht für KP geeignet) über WinQual, aber generell nur für Firmen.

Um die Regeln der KP kommt man bspw. nicht herum wenn die eigene Anwendung/DLL für AppInit funzen soll, mit dem WSC kommunizieren soll usw. ... Treiber ja ohnehin (sagt ja schon der Name ;)).

Zitat:

Zitat von Bernhard Geyer (Beitrag 1020763)

4: Bei Verisign ist es möglich das bei Anwendungsabstürzen der Callsstack+Umgebung an MS gesendet wird und du es dort abholen kannst um den Fehler nachzuvollziehen. Haben wir bisher nicht gemacht.

WinQual wird meines Wissens nach für derlei Dienste kostenpflichtig. Und bei Delpianwendungen ist madExcept (usw) ohnehin die bessere Lösung.

Übrigens ist das mit "nur signtool" sei wichtig vermutlich dann hinfällig wenn man am Logo-Programm teilnimmt. Denn für diverse Methoden des Signierens muß das Zertifikat im "Certificate Store" (in der Registry) liegen und darf eben nicht als .pfx auf der Platte sein. Frag mich nicht warum, aber es geht dann wirklich nicht mehr mit .pfx ... signtool weigert sich dann nur noch.

[divBy0]

Zitat:

Zitat von Grolle (Beitrag 1041511)

Hallo,

wie oben versprochen ein kleines Tutorial zum Thema Code signing mit startssl.

Viele Grüße ...

Das ist ja mal gut beschrieben, danke hierfür! :thumb: Dort werde ich mir mal ein Zertifikat für privat gönnen.

[generic]

Ach das passt gerade schön. Hatte gerade neue Preise rausgesucht.

Preis pro Jahr bei jeweils der längst möglichen Laufzeit.

49USD (34,4421 EUR) / einmalig?
https://www.startssl.com/
s.h. auch https://forum.startcom.org/viewtopic.php?f=15&t=1654

75USD (52,665 EUR) / Jahr
https://secure.ksoftware.net/code_signing.html

118€ / Jahr
http://www.trustcenter.de/products/t...thenticode.htm

135€/ Jahr
http://www.certum.eu/certum/cert,offer_code_signing.xml

159€ / Jahr
https://globalsign.wis.de/certs/info/object/

167€ / Jahr
http://www.instantssl.com/code-signing/

264€ / Jahr
http://www.thawte.com/code-signing/index.html

432€ / Jahr
http://www.verisign.de/code-signing/...ode/index.html
oder per Promotion Code 99 USD für nur 1 Jahr (und nicht länger)
https://securitycenter.verisign.com/...Code=THEDEAL99



Nur mit dem Verisign Zertifikaten ist die Nutzung der zusätzlichen Dienste von Microsoft möglich.
http://www.microsoft.com/whdc/winlog.../StartWER.mspx


Erfahrungen:
Bei KSoftware war mein Browser beim Kaufvorgang damals (vor ca. 5 Jahren) ausgestiegen und ich musste viele Emails schreiben, bis ich den bezahlten Kauf bekommen hatte.

Bei StartSSL funktioniert ganz gut. Gekauft habe ich dort allerdings nie etwas. Unbedingt das Clientzertifikat sichern, wenn ihr euch dort angemeldet habt. Ohne dem Zertifikat könnt ihr euch dort nicht mehr anmelden!

Comodo und Thawte laufen auch problemlos. Bei den beiden kaufe ich SSL Zertifikate über die deutsche Firma PSW Group (http://www.psw.net/).

Von Thawte ist mein aktuelles Code Signing Zertifikat. Lief bis jetzt ohne Probleme.

[Assarbad]

Zitat:

Zitat von generic (Beitrag 1059592)

Ach das passt gerade schön. Hatte gerade neue Preise rausgesucht.

Preis pro Jahr bei jeweils der längst möglichen Laufzeit.

49USD (34,4421 EUR) / einmalig?
https://www.startssl.com/
s.h. auch https://forum.startcom.org/viewtopic.php?f=15&t=1654

Der Preis (derzeit 59 USD) wird für die Validierung fällig und das geht alles recht flott. Danach kann man ein Zertifikat erstellen welches zwei Jahre lang gültig ist.

So, und da alle Tutorials immer von den PFX-Dateien ausgehen, welche man signtool.exe füttert, hier die kurze Anleitung wie das Signieren auch ohne die PFX-Datei geht. Ich beziehe mich hier auf das Tutorial von Stefan (Grolle) und andere Tutorials. Hier nochmal der Link: http://blog.stefangöppert.de/?page_id=275

Außerdem ist diese Methode mal sicherer (siehe Hinweis ganz unten) und erklärt vielleicht auch jenen die nicht StartSSL benutzen die Hintergründe und Zusammenhänge der verschiedenen Dateien und Formate.

Ich setze hier mal voraus, daß man zuvor die Validierung durchführen lassen hat.

1.) Privaten Schlüssel und CSR (certificate signing request) mit OpenSSL erstellen. Hat man einen privaten Schlüssel, kann man auch einen existierenden benutzen.

Code:

openssl req -new -newkey rsa:4096 -keyout key.pem -out csr.pem

Hinweis: die Details sind irrelevant. Nur der öffentliche Schlüssel der im CSR mitgeschickt wird, wird auch von StartSSL benutzt. Sprich, man kann die Vorgaben von OpenSSL übernehmen. Die Daten aus der Validierung werden stattdessen benutzt. Ja, das schließt die folgenden Felder ein: E (Email), CN (Common Name, also euer Name), L (Location, also Stadt), S (State, also Bundesland) und C (Country, also Staat). Soweit ich es sehen kann ist die Telefonnummer und die exakte Adresse nicht enthalten, die man aber während der Validierung angeben muß.

2.) Unter "Object Code Signing" im zweiten Tab im "Control Panel" bei StartSSL den Inhalt des CSR einfügen und abschicken (siehe Link oben).

3.) Am Ende dieses Schrittes bekommt man das von StartSSL signierte Zertifikat in einem Textfeld. Dieses Zertifikat speichert man nun in einer Datei, bspw.: cert.crt

Bei Verisign (jetzt Symantec) war dies beim letzten Mal ein Download. Wenn ich mich recht entsinne, brauchte ich auch die Zwischenformate irgendwie nicht. Ist aber schon zwei Jahre her. Ich kann evtl. im Herbst nochmal schreiben wie das heute dort läuft.

4.) Nun benutzt man das Tool cert2spc.exe aus dem Windows SDK um das Zertifikat in eine SPC-Datei zu konvertieren:

Code:

cert2spc.exe cert.crt cert.spc

5.) Nun benutzt man pvktool um den privaten Schlüssel in eine PVK-Datei zu konvertieren (neuere OpenSSL-Versionen sollen diese Funktionalität auch von Haus aus bieten, hab's aber nicht probiert). Um pvktool zu kompilieren mußte ich aber "-ldl" in der Make-Datei anfügen, damit die "Dynamic Loader" Bibliothek von Linux mit eingelinkt wird. Ansonsten gibt's Linkerfehler (zumindest zusammen mit dem aktuellsten OpenSSL 1.0.0d).

Code:

pvk -in key.pem -topvk -strong -out key.pvk

6.) Jetzt benutzt man das Tool pvk2pfx.exe aus dem Windows SDK um die SPC und PVK zu einer PFX zusammenzuführen.

Code:

pvk2pfx.exe -spc cert.spc -pvk key.pvk -pfx cert.pfx

Hinweis: cert.pfx enthält jetzt die "Credentials" (also den privaten Schlüssel) und das Zertifikat. Ab hier kann man es genauso benutzen wie es in den vielen Tutorials beschrieben wird. Oder man nimmt die letzte Hürde.

7.) Man kann nun die PFX in den "Certificate Store" des Computers oder des aktuellen Benutzers importieren.
Aktueller Benutzer:

Code:

certutil -user -importPFX cert.pfx

Computer:

Code:

certutil -importPFX cert.pfx

So und ab hier kann man jetzt ganz bequem das installierte Zertifikat benutzen.

Hat man es für den Computer installiert, benutzt man "/sm":

Code:

signtool.exe sign /v /a /sm /ph /d "..." /du "http://..." /tr http://www.startssl.com/timestamp my.exe

Hat man es für den aktuellen Benutzer installiert, läßt man es weg:

Code:

signtool.exe sign /v /a /ph /d "..." /du "http://..." /tr http://www.startssl.com/timestamp my.exe

• /v steht für verbose und wird nicht benötigt. Ist aber sinnvoll beim ersten Mal. So sieht man welches Zertifikat gewählt wurde (nächster Punkt).
• /a wählt automatisch das am längsten gültige Zertifikat aus, welches für "Code Signing" tauglich ist. Meist ist ohnehin nur ein Zertifikat auf dem Rechner installiert.
• /ph erstell Hashes über die einzelnen Sektionen der EXE (sicherer)
• /d fügt eine Beschreibung hinzu - wird meines Wissens nach nirgends später angezeigt.
• /du siehe /d, ist aber eine URL.
• /t oder /tr ist die URL eines Timestamp-Servers. Das ist SEHR SEHR WICHTIG. Wenn ihr das nicht benutzt, läuft sowohl das Zertifikat als auch die damit erstellte Signatur einer EXE ab. Wenn ihr es benutzt, läuft die Signatur nicht ab, da der Dienst garantiert, daß vor Ablauf signiert wurde ...
• /ac muß für Treiber benutzt werden um die Ausstellerzertifikate ebenso in die Binärdatei einzufügen.
• /i und /n und /r können benutzt werden um das korrekte Zertifikat auszuwählen, sollte mehr als eines installiert sein.

Den Timestamp-Service sollte man immer jeweils vom Aussteller her benutzen. Rein prinzipiell könnte es auch gemischt gehen.

Hinweis: man kann auch die Schritte bis zur Erstellung der PFX über StartSSL machen, dann muß man aber die Passphrase zu seinem privaten Schlüssel an die weitergeben. Benutzt man bspw. einen existierenden Schlüssel ist dies schlecht. Daher läßt man das lieber und benutzt den oben beschriebenen Weg, wenn man's sicher mag.

[mquadrat]

Unser Cert ist von Entrust, aber die sind eindeutig auf Großkunden spezialisiert. Da immer mindestens zwei verschiedene Personen bestätigen müssen (beide werden per Telefon gecheck), kann man da als Ein-Mann-Firma nicht mal eins kaufen :lol:

Comodo-Zertifikate kann man reduziert über Tucows kaufen, nachdem man sich dort als Autor registriert hat. Ich meine das wäre auch recht günstig.