ich signiere schon seit Jahren ein JAR mit jarsigner. Das Zertifikat stammt von GlobalSign, die haben sogar einen schönen Artikel dazu in ihrer Knowledgebase:
Jetzt habe ich ein neues Token bekommen, aber damit funktioniert das Verfahren nicht mehr. Das Problem ist, dass das Token auf ein Root- bzw. Zwischenzertifikate beruht, die standardmäßig nicht im Java-Keystore (cacerts) enthalten sind. Das meckert jarsigner dann an:
The signer’s certificate chain is invalid. Reason: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
Ok, die fehlenden Zertifikate kann ich zu cacerts hinzufügen. Dann klappt’s auch mit dem Signieren. Dann muss man das auf der Zielmaschine auch machen, sonst wird das JAR von (Open)WebStart als self-signed abgelehnt. Genau das möchte ich vermeiden, an die Zielmachine(n) komme ich nicht so ohne weiteres ran. Nein, es soll wie bisher mit eine Standard-JRE-Installation funktionieren, also z.B. Java 8 LTS oder OpenJDK mit OpenWebStart.
Meine Idee ist, dem JAR beim Signieren die fehlenden Zwischenzertifiktae mitzugeben. Das sollte doch mit jarsigner -certchain gehen, oder? Leider endeten alle meine Versuche beim anschließenden -verify mit einer Fehlermeldung:
Der GlobalSign-Support hat es auch nicht hinbekommen und steht nun nach einigem Hin und Her auf dem Standpunkt „Das Zertifikat wurde korrekt ausgestellt, alles weitere ist nicht unser Problem“. Na toll.
Ich bin auch mit meinem Latein am Ende Hat hier evtl. jemand eine Idee?
Hallo, das Thema hat mich heute auch fast in den Wahnsinn getrieben. Hier die Lösung:
1.) Mit „-certchain“ kann man zwar (nach etwas experimentieren) beim signieren die fehlenden Zwischenzertifikate mitgeben und es wird ohne Warnungen signiert, aber die Zertifikate werden nicht korrekt im .jar integriert und so kann der jarsigner das gerade eben produzierte .jar nicht ueberpruefen (!).
Fazit: nur weil der jarsigner keine Warnungen beim signieren ausgibt, heisst das nicht, dass eine vollständige und korrekte X509 Kette im .jar File integriert wurde (vollständig = Pfad bis zu einem dem JDK bekannten Root)
2.) Die Lösung ist simpel: einfach das „GlobalSign GCC R45 EV CodeSigning CA 2020“ sowie das „GlobalSign Code Signing Root R45 (R3 cross)“ Intermediate bzw. Cross Sign Zertifikat in das USB Token reinladen (mit dem SafeNet Client, Menupunkt „Import Certificate…“, es erscheint dann ein „CA Certificates“ Ordner zusätzlich zum existierenden „User Certificates“ Ordner).
3.) Das „-certchain“ Argument braucht es nicht beim signieren!
Achtung: Falls man nicht ein „EV“ Zertifikat hat, sondern ein „Standard“ Zertifikat, einfach das „GlobalSign GCC R45 CodeSigning CA 2020“ anstelle des „GlobalSign GCC R45 EV CodeSigning CA 2020“ verwenden (Warnung: konnte ich nicht testen).
Hier ist die Support Website von GlobalSign mit den Zertifikaten:
Somit ändert bei der Kommandozeile vom jarsigner nichts (das „alias“ Argument hast Du ja schon auf Dein neues GlobalSign Zertifikat angepasst), man muss lediglich die nötigen Intermediate/Cross Zertifikate auf dem Token haben.
das funktioniert prima, vielen Dank! Ich hatte mich zum Schluss dermaßen mit den vielen GlobalSign-Zertifikaten verheddert, da bin ich auf so eine einfache Lösung nicht mehr gekommen.
Noch ein paar Details fürs Archiv. Auf dem Token erscheinen die beiden Zertifikate so:
Das letzte Zertifikat heißt auf der GlobalSign-Seite „GlobalSign Code Signing Root R45 (R3 cross)“, der Anhang „(R3 cross)“ taucht im Token aber nicht auf.
