![]() |
AW: Code Sign Zertifikat
Das Verschicken der Hardware hat bei mir 2 Tage gedauert.
Es kam per DHL Express |
AW: Code Sign Zertifikat
Zitat:
Nun habe ich ein anderes Problem: Das Signieren klappt nicht:
Code:
Ergibt die Meldung:
"E:\signtool.exe" sign /n "Firmenname" /t "http://time.certum.pl/" /fd sha256 /v "E:\test.exe" /debug
"E:\signtool.exe" verify "E:\test.exe"
Code:
E:\test.exe bekommt keine Signatur ohne weiter Meldungen. Stick ist aktiv, blinkt, proCertum CardManger läuft. Was mache ich falsch?
Index Algorithm Timestamp
======================================== SignTool Error: No signature found. Number of errors: 1 |
AW: Code Sign Zertifikat
Bei mir habe ich noch mit /v /f "e:\softtouch.cer" mit drin, klappt einwandfrei.
Hast Du denn das .cer file exportiert (Control Panel->Internet Options->Content->Certificates)? |
AW: Code Sign Zertifikat
Zitat:
|
AW: Code Sign Zertifikat
Zitat:
Kannst du SHA1 und SHA256 signieren? Die SHA1 Signatur klappt bei mir ohne Probleme. Bei SHA256 kommt immer ein SignTool Error. Egal ob als Dual Signature oder Standalone.
Code:
Ich hab es mit unterschiedlichen Aufrufparametern versucht.
Done Adding Additional Store
SignTool Error: An unexpected internal error has occurred. Error information: "Error: SignerSign() failed." (-1073741275/0xc0000225) Hier der Aufruf für Dual Signature (Sha1 schon gemacht)
Code:
und hier mal als Test auf einer nicht signierten Exe (also ohne Dual Signature)
"%signtoolbin%" sign /sha1 %cert_fprint% /tr http://time.certum.pl/ /td sha256 /fd sha256 /as /v %1
Code:
"%signtoolbin%" sign /sha1 %cert_fprint% /tr http://time.certum.pl/ /td sha256 /fd sha256 /v %1
signtoolbin ist der pfad zur signtool exe hier: C:\Program Files (x86)\Windows Kits\10\bin\10.0.22621.0\x64\signtool.exe cert_fprint ist der SHA1 fingerprint meines Zertifikats ich habe es anstelle des Fingerprints auch schon mit dem Namen des Zertifikatinhabers versucht. Klappt auch bei SHA1, klappt auch nicht bei SHA256... Die Parameter hab ich aus dem PDF von Certum übernommen: ![]() |
AW: Code Sign Zertifikat
Habe gerade auch eine Mail über das ablaufende (OV) Zertifikat von KSign erhalten.
Statt 200 Euro für 3 Jahre (in 2021) soll es nun 660 Euro kosten. Was für eine saftige und unverschämte Preiserhöhung, für die es keinen erkennbaren Grund gibt. Wenn ich keinen vernünftigen Ersatz finden sollte, dann überlege ich mit selbst signierten Zertifikaten zu arbeiten oder halt ganz ohne, da ich sowieso ganz überwiegend Update-Käufe von Bestandskunden habe (und die OV-Zertifikate eh auch schon mal zu Meldungen führten ("Dieses Programm wurde nicht oft heruntergeladen"). Kann man ja auch auf der Homepage entsprechend erläutern. Jedenfalls diese Preise zahle ich nicht. |
AW: Code Sign Zertifikat
Die Zertifikate erfüllen ihren Zweck: Hobby-Programmierer haben schon aufgegeben, Einzelentwickler werden bald aufgeben, zur Not werden die Preise halt weiter angehoben. Ihre Software wird nicht (mehr) signiert.
Bleiben die großen Softwarehäuser, die sich das leisten können und die jetzt einen weiteren Vorteil haben: Ihre Software wird von Windows als "besser" erkannt als die der "kleinen". Es wird nicht mehr lange dauern, bis Windows unsignierte Software gar nicht mehr ausführt. Nächster Schritt: Installation nur noch via Microsoft Store. (Ich wünschte, ich würde jetzt nur eine Verschwörungstheorie zum Besten geben, aber leider glaube ich wirklich, dass dies zumindest ein willkommener Nebeneffekt der Zertifikatsprüfungen in Windows ist.) |
AW: Code Sign Zertifikat
Früher sollte man eine Bank gründen, um reich zu werden - heute eine CA.
|
AW: Code Sign Zertifikat
Also ich habe von meiner Homepage mal ein ganz altes Setup-Programm aus 2009 runter geladen, wo die Signierungs-Zertifikate längst abgelaufen sind. Der Aufruf dieser Dateien wird von Windows nicht beanstandet, sondern ganz normal das blaue Fenster angezeigt und ich werde als verifizierter Herausgeber genannt.
Wenn also eine einmal signierte Setup-Datei "auf ewig" akzeptiert wird, dann könnte ich ja letztlich meine Setup-Variante ändern: Ich erstelle nicht jedesmal ein Setup-Paket (eine EXE-Datei), welche mein jeweiliges Programm enthält, sondern ich erstelle (mit meinem derzeit ja noch gültigen Signierungs-Zertifikat) eine für alle Setup-Projekte verwendbare Setup.exe Datei. Die enthält dann nicht mehr selbst alle Programmteile, sondern Sie entpackt eine mitgelieferte Ressourcen-Datei (oder zIP-Datei), welche anhand einer Setuplist einen eben variablen Inhalt haben kann. Alles das packe ich in einer ZIP-Datei, der User lädt die von meiner Homepage, entpackt das in einen Ordner und führt die Setup.exe Datei aus, welche das Programm wie bisher installiert (müsste da kaum was an dem Setup-Programm ändern, statt die Dateien aus der eigenen Resource zu laden, lädt das Programm die eben aus einer externen Datei). Dann würde ich kein neues Codesigning Zertifikat mehr benötigen (jedenfalls solange ich nichts an der Setup-Datei ändere). Oder begehe ich hier einen Denkfehler? |
AW: Code Sign Zertifikat
Jo, die Gültigkeit des Zertifikats, bezieht sich normal auf die Anwendung, also den Zeitpunkt der Signierung, nicht wann es geprüft/verifiziert wird.
Damit wäre aber auch nur dein Setup betroffen. Die ausgeführte Anwendung, welche dein Setup installiert, wäre somit nicht signiert und Windows könnte sich beim Start weigern. Es kommt aber auch immer darauf an, ob und wie eine Signatur geprüft wird. Wenn ich mich nicht täusche, dann prüft Delphi nur, ob eine Signatur in seinen DLLs/Packages enthalten sind/waren, aber nicht, ob dieses Zertifikat auch gültig ist und ob es von Emba selbst stammt ... bei sowas könnte ein "Angreifer" das also leicht aushebeln. * ist (irgendeine) Signatur vorhanden * lässt sie sich verifizieren * am besten noch gegen eine externe Stelle * ist sie auch vom "erlaubten" Besitzer/Ersteller * wie sieht es mit dem Ablaufdatum aus * wurde diese Signatur/RootZertifikat/Ausgabestelle gesperrt * ... Bei den gekauften Zertifikaten wird von Windows nicht deine Signaur selbst geprüft, da dich niemand kennt, aber bei den Vorvahren wird dann einfach geschaut, ob mindestens dem RootZertifikat (Ausgabestelle) vertraut wird und dann wird gehofft, dass Diese dir trauen. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 10:46 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz