Code Sign Zertifikat

[Harry Stahl]

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?

[himitsu]

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.

[Harry Stahl]

Zitat von himitsu:

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.
.

Solange die installierte Anwendung keine Admin-Rechte braucht, glaube ich nicht, dass Windows gegen einen Start der Anwendung etwas einzuwenden hätte.

[Lemmy]

Zitat von Harry Stahl:

Solange die installierte Anwendung keine Admin-Rechte braucht, glaube ich nicht, dass Windows gegen einen Start der Anwendung etwas einzuwenden hätte.

aber evtl. ein Virenscanner. ist eine Exe signiert, gibt das ordentlich Pluspunkte.

[himitsu]

Zitat von Harry Stahl:

Solange die installierte Anwendung keine Admin-Rechte braucht, glaube ich nicht, dass Windows gegen einen Start der Anwendung etwas einzuwenden hätte.

Ich kann mehrfach bestätigen, dass dem nicht so ist und es dennoch was dagegen hat.

[Harry Stahl]

Zitat von himitsu:

Zitat von Harry Stahl:

Solange die installierte Anwendung keine Admin-Rechte braucht, glaube ich nicht, dass Windows gegen einen Start der Anwendung etwas einzuwenden hätte.

Ich kann mehrfach bestätigen, dass dem nicht so ist und es dennoch was dagegen hat.

Evtl. liegt das auch an einer speziellen Konstellation bei Dir? Jedenfalls habe ich schon oft zum Testen eine nicht signierte Datei auf einem anderen PC in das Programmverzeichnis kopiert und dort ausgeführt. Kein Problem. Auch in Problemfällen hatte ich unsignierte EXE-Dateien Usern zum Testen zur Verfügung gestellt, die Programme waren problemlos ausführbar.

Wenn ein Programm ordnungsgemäß im Programmverzeichnis installiert wurde, macht es auch keinen Sinn, wenn Windows hier was zeigen oder bemängeln würde, nur weil eine Datei nicht signiert wurde. Das macht es allenfalls bei Downloads, die gerade frisch herunter geladen und ausgeführt werden sollen.

[himitsu]

Noch Windows 10 oder schon 11?

Aber OK, in diesem Verzeichnis war es selten installiert.


Einfach EXE auf Desktop kopiert, oder in eigenen Verzeichnissen installiert (welche dann oft im Intranet freigegeben werden)

[Harry Stahl]

Zitat von himitsu:

Noch Windows 10 oder schon 11?

Aber OK, in diesem Verzeichnis war es selten installiert.


Einfach EXE auf Desktop kopiert, oder in eigenen Verzeichnissen installiert (welche dann oft im Intranet freigegeben werden)

Sowohl Windows 10 als auch Windows 11. Und natürlich in C:\Program files(x86) oder für 64 bit in "C:\Program Files".

Ich werde die Setup-Daten Daten nun einfach in eine DLL packen, aus der kann das Setup-Programm dann die Daten lesen und das Programm installieren...

[Kas Ob.]

Zitat von Harry Stahl:

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?

Most likely as himitsu pointed, will not work.

Also i want to correct or elaborate on the time of signing he mentioned, digital signature doesn't have timestamps by themselves nor have time at all, their structure and specification doesn't have that, but these signature can be timestamped with additional and specific timestamp signature, preferably form trusted TimeStamp Issuer, in other words you can have your digital signature with your CA trusted issued certificate and without the timestamp, no way to verify its singing time, has it signed after expiry date ?!!

The normal behavior is to not trust it, yet it might simply be marked as can't verify, while might show the publisher detail with this can't verify!

And this what i want to ask you to test, sign it with an old CA trusted issued certificate, but don't not timestamp it, please share your finding with us, specially if you have Windows 11.
ps: you can try with an old one where expired CA if you have one, but also you might have one where its CA is still valid, try both if you can, if you are up to testing something new and unorthodox, also for educational purposes