Signiertes Applet: Umgehen mit abgelaufenem Zertifikat

Java-Forum Allgemeine Themen
1

Hallo zusammen,

ich bin ein wenig am verzweifeln:

Wir entwickeln eine Applet-Basierte Anwendung für unsere Kunden. Die Sicherheitsbestimmungen zum Ausführen von Applets werden immer restriktiver. Und genau da ist gerade mein Problem:

Die Anwendung besteht aus rund einem dutzend JARs. Alle (auch Dritte) sind signiert (vollständig), alle (auch Dritte) haben mittlerweile folgende Manifest-Attribute vor dem signieren:

Permissions: all-permissions 
Codebase: *

Da wird eine Lösung für **viele **Kunden haben und nicht für jeden Kunden ein separates Projekt bauen (bei 600 Kundeninstallationen wäre das zu viel Aufwand für uns) und die Kundensysteme alle unterschiedlich sind, sitzt die Codebase auf “*”. Die Permissions brauchen wir “alle”. Deshalb “all-permissions”. Passt soweit und ist von den Kunden akzeptiert.

Die ganze signiererei wird von einem TSA mit einem gültigen Zeitstempel “abgesegnet”. Bis jetzt funktioniert das prima.

Nun ist es in ca. 5 Monaten mal wieder soweit dass unser gekauftes Zertifikat ausläuft, wir aber noch zwingend vor dem Zertifikatablauf ein Release rausbringen wollen bzw. müssen. Eigentlich dachte ich dass die Verwendung der passenden Manifest-Einträge sowie die signierung zusammen mit einem TSA ausreicht um auch nach dem ablauf des Zertifikats beim Kunden keine dicken Warnmeldungen zu bekommen (Das Zertifikat war ja immerhin während der signierung der Anwendung gültig und wurde auch nicht von der CA zurückgezogen). Zum simulieren des abgelaufenen Zertifikats hab ich gelesen, soll man die lokale PC Uhr vor stellen. Hab ich getan. Ca. 1 Monat nach Zertifikatablauf. Ergebnis ist das hier beim Start:

Selbst wenn ich unser Management davon überzeugen könnte dass “das halt so ist wie es ist” (was ich aber nicht glaube), dann kommt nach dem wegklicken der Meldung das hier:

??? Bahnhof Die Anwendung heisst nicht “jdom”. Aber eine der JARs die wir verwenden ist “jdom”.

Hat jemand einen Plan woran es noch liegen könnte? Ziel wäre es die Anwendung möglichst ohne Warndialog mit fettem rotem Warnhinweis auczh nach ablauf des Zertifikats laufen lassen zu können. Denn dafür soll doch die signierung mit TSA da sein…
Und hat jemand eine Idee wieso da JDOM auf einmal negativ auffällt?

Wenn die PC Uhr so eingestellt ist, dass das Zertifikat noch nicht abgelaufen ist, dann läuft alles ohne Fehlermeldung.

Gruß
Alex

P.S. In der Vergangenheit wurden die Systeme von uns nach-signiert. Aber das wir mit steigender Kunden und Installationszahl unpraktikabel. Deshalb der Ansatz mit dem Zeitstempel basierten signieren …

2

39 Views und keiner hat eine Idee :frowning:

3

Ich verstehe aber auch das Szenario nicht. Was spricht gegen ein neues Zertifikat? Zu teuer?

4

Moin,

ich kann auch nur raten, aber hast Du mal nachgesehen, ob die Zeitstempelinformationen tatsächlich in den JARs eingetragen wurden?

Imho kann das jarsigner immer noch nicht anzeigen. Eine kurze Websuche ergibt:

How to validate if a signed jar contains a timestamp?

(ggf. auf .rsa anpassen)

Viele Grüße
Fancy

5

Ich verstehe aber auch das Szenario nicht.

Das hab ich gemerkt…

Das Szenario ist: Das Zertifikat läuft in 5 Monaten ab, ein Release steht aber bereits in 4 Wochen ins Haus, und man will hier nicht „verfrüht“ Geld für ein neues Zertifikat ausgeben, und somit 4 Monate bereits bezahlte Zertifikatlaufzeit in den Wind schießen.

Hinzu kommt, dass mit dem anstehenden Release die Software „endlich“ mal ohne nachsignieren und damit ohne „Fehlermeldungen“ beim Start beim Kunden laufen kann wenn das Zertifikat seine Gültigkeit überschritten hat. Denn nicht jeder Kunde kann und will innerhalb der Zertifikatlaufzeit auf die nächste Version wechseln.

@timbeau

Danke, das werd’ ich mir gleich anschauen.

[update]
angeschaut und ausprobiert. Nachdem ich „.dsa“ in „.rsa“ im Samplecode geändert habe, zeigt mir das Tool Zeitstempel an. Sieht soweit korrekt aus :frowning:

6

Kurzes Feedback: Bin kein Stückchen weiter gekommen… :frowning:

Falls noch wer eine Idee haben sollte: Her damit :wink:

7

Viel werde ich auch nicht helfen können, nur vielleicht dass passende Websuchen schon Infos zu der JDOM-Sache bringen:

So ganz habe ich vielleicht auch das Problem noch nicht erfasst. Von diesen Zertifikats- und Signierungszeug hab’ ich bisher immer nur das nötigste gemacht (und schließlich hat sich in letzter Zeit da SO viel verändert, dass ich schon fast froh darüber sein kann, jetzt nicht auf einem Haufen veralteten Wissens zu sizten :smiley: :wink: ). Aber: EIN Warndialog wäre OK, aber zwei nicht? Oder sollte die Warnung nur „nicht so schlimm“ aussehen? Welche Möglichkeiten es da im Einzelfall gibt, und wie (wenig) akzeptabel die sind, ist schwer zu sagen (ich denke da an solche „worst-practice“-Sachen wie „jdom mit in die eigene JAR packen, damit alles gleich und auf einen Rutsch selbst signieren kann“ usw).

Nebenbei kommen halt auch weitere Infos, sowas wie https://blogs.oracle.com/java-platform-group/entry/new_security_requirements_for_rias stammt von vorgestern, ein Tag nachdem dieser Thread hier eröffnet wurde (noch nicht gelesen, könnte aber relevant sein), und … solche Fragen wie

  • Wie lange beschäftigst du dich schon damit?
  • Wie hoch ist dein Stundenlohn?
  • Wieviel kostet ein Zertifikat?
    blende ich jetzt mal aus :smiley:
8

[QUOTE=Marco13]Viel werde ich auch nicht helfen können, nur vielleicht dass passende Websuchen schon Infos zu der JDOM-Sache bringen:

[/quote]

Leider hilft das nicht. JDOM lässt sich in signierten Applets nutzen. Wenn man das Manifest auf den aktuellen Stand was Java Security anbelangt bringt. Das hab ich ja schon gemacht. Es funktioniert ja auch. Es geht nur dass die Anwendung ohne Warnmeldungen und für den Nicht-Compter-Affinen Anwender „kritisch“ aussehenden Sicherheitshinweise startet.

So ganz habe ich vielleicht auch das Problem noch nicht erfasst. Aber: EIN Warndialog wäre OK, aber zwei nicht? Oder sollte die Warnung nur „nicht so schlimm“ aussehen?

Die Anwendung läuft im medizinischen Umfeld. Die Anwender haben von in der Regel von PCs absolut null ahnung. Und wenn sich von heute auf morgen am „bekannten Verhalten“ irgendwas gravierend ändert (Sicherheitswarnmeldungen mit fetter roter Schrift z.B.), dann laufen bei uns in der Hotline die Telefone heiss. Das gilt es zu vermeiden.

Welche Möglichkeiten es da im Einzelfall gibt, und wie (wenig) akzeptabel die sind, ist schwer zu sagen (ich denke da an solche „worst-practice“-Sachen wie „jdom mit in die eigene JAR packen, damit alles gleich und auf einen Rutsch selbst signieren kann“ usw).

Wenn ich das JDOM Thema nicht gelöst bekomme, dann wäre das natürlich ein möglicher Workaround.

Nebenbei kommen halt auch weitere Infos, sowas wie https://blogs.oracle.com/java-platform-group/entry/new_security_requirements_for_rias stammt von vorgestern, ein Tag nachdem dieser Thread hier eröffnet wurde (noch nicht gelesen, könnte aber relevant sein), und

Das ist schon bekannt. Wurde mit Update 45 bereits von Oracle kommuniziert. Deshalb ist bei uns auch alles

  • signiert
  • mit TSA Zeitstempel
  • mit allen erforderlichen Manifest-Attributen wie im Artikel beschrieben

… solche Fragen wie

  • Wie lange beschäftigst du dich schon damit?
  • Wie hoch ist dein Stundenlohn?
  • Wieviel kostet ein Zertifikat?
    blende ich jetzt mal aus :smiley:

Ja, solche Fragen muss ich auch schon ausblenden :wink: Aber um sie zu beantworten:

Wie lange beschäftigst du dich schon damit? → Zusammen mit anderem Kram in dem Umfeld: Locker schon 2 Wochen. Also viel zu lange.
Wie hoch ist dein Stundenlohn? → Wenn du mich fragst: Zu gering :wink:
Wieviel kostet ein Zertifikat? → ein paar hunderter glaub ich…

Ich weiß schon worauf du hinaus willst. Aber wie es so oft mit Chefs ist: Da gilt das „der ist doch eh den ganzen Tag im Büro, dann kann er sich damit auch beschäftigen“-Prinzip.

Aber selbst wenn wir jetzt schon verfrüht ein neues Zertifikat kaufen: Dann haben wir nur 4 Monate gewonnen… Die Anwendung läuft bei den Kunden unter Umständen ohne ein Update länger als das Zertifikat gültig ist. Und wenn das Zertifikat dann wieder mal ausläuft, dann kriegen die wieder, wie jetzt auch schon in meiner Simulation mit „vorgestelltem Datum“ jede Menge Meldungen und Warnhinweise um die Ohren geballert. Und dann glüht wieder die Telefonanlage.

Nochmal:

Ziel ist es mit der Zeitstempel-Signierung mittels eines TSA (siehe auch Trusted timestamping - Wikipedia) die Anwendung zu signieren, und auch nach der Gültigkeit des Zertifikats die Anwendung ohne Warnmeldungen zu benutzen. Genau dafür wurde das signieren mit einem TSA ja erfunden… Die Alternativen wäre ein Update bzw. ein nachsignieren der Anwendung mit einem neuen Zertifikat. Beides ist nur schwer möglich…

9

Interessant wäre vielleicht auch, von welcher Zertifizierungsstelle euer Code-Sign-Zertifikat ausgestellt wurde und welche TSA-URL verwendet wurde. Beziehungsweise, ob Du sicher weißt, dass die zur Signatur des Zeitstempels eingesetzte Zertifikatshierarchie von der JRE als gültig erkannt wird. Es gibt CAs die verwenden dazu eine andere Zertifikatshierarchie als zum normalen Zertifikatsbetrieb.

Vermutlich willst Du Deinen Arbeitgeber nicht preisgeben, sonnst hätte ich vorgeschlagen, dass Du ein “Hello World”-Applet baust, signierst und online stellst, dann könnte man sich das vielleicht ansehen. So ist es halt schwierig, denn eigentlich sollte es ja gehen.

Viele Grüße
Fancy

10

Evtl. habe ich eine Lösung.

Nachdem ich hier beide Antworten gelesen habe

Kann es sein dass deine TSA nicht im JRE unter den vertrauenswürdigen vorhanden ist und somit das Timestampen mit dieser sinnlos ist. Wie hier z.B. Thawte vor 6u10 und 5.0u18

Jetzt ist die Frage, welche TSA sind im JRE akzeptiert und welche hast du verwendet. Auf der Suche nach ersterem bin ich darauf gestossen. Letzteres geht hier ja schwer;)

https://blogs.oracle.com/java-platform-group/entry/code_signing_understanding_who_and

(Ganz unten - A Word on Timestamps)

Dort werden diese Dienste erwähnt.

http://timestamp.verisign.com
http://tsa.starfieldtech.com
https://timestamp.geotrust.com/tsa

Evtl. hast du also mit einem anderen TSA mehr Erfolg. AFAIU kann man auch mehrere TSA nutzen.

11

@Fancy

Zertifikat stammt von http://www.thawte.de/ und ist von Thawte für die Java-Code-SIgnierung vorgesehen.
TSA Url ist die von Thawte „empfohlene“: https://timestamp.geotrust.com/tsa

Getestet hab ich immer mit der aktuellen Java Version (erst Java 7 Update 45, jetzt Update 51).

Soweit ich das recherchiert habe, wird die Geotrust TSA von der JRE anerkannt.

Vermutlich willst Du Deinen Arbeitgeber nicht preisgeben, sonnst hätte ich vorgeschlagen, dass Du ein „Hello World“-Applet baust, signierst und online stellst, dann könnte man sich das vielleicht ansehen. So ist es halt schwierig, denn eigentlich sollte es ja gehen.

So ist es. Kann und darf den AG nicht nennen. Das mit dem HelloWorld ist so ne Sache. Das Ergebnis ließe sich in keinster Weise mit der betroffenen Anwendung vergleichen. Die Anwendung ist deutlich komplizierter und hat dutzende Abhängigkeiten zu fremden Bibliotheken (inkl. nativer Abhängigkeiten zu DLLs).

@Unregistered

The Stackoverflow-Artikel hatte ich auch schon gefunden. Leider ist das wohl nicht die Ursache.

Bin noch auf der Suche nach einem Log/Debug/Trace-Level das mir verrät warum die Anwendung mit einem abgelaufenen Zertifikat als nicht sicher eingestuft wird… Kann ja nicht sein dass da nirgendwo der Grund steht…

[update]

Manchmal hilft es ein wenig Abstand zur Anwendung zu bekommen. Mir kam gerade so eine Idee:

Der Screenshot in meinem obigen Post mit der roten Warnmeldung: Da geht’s in erster Linie nicht um das abgelaufene Zertifikat. Da geht’s in erster LInie mal um den uneingeschränkten Zugriff… Während das Zertifikat noch gültig ist kommt die Meldung nicht. Das heisst vllt. dass Java ein Problem damit hat wenn a) die Anwendung mit uneingeschränktem Zugriff laufen will und b) auch noch das Zertifikat abgelaufen ist…
Wenn das der Fall ist, dann werde ich wohl nicht drum rum kommen mal einen Bug/RFE/etc. bei Oracle aufzumachen um die Sache aufzuklären.

*** Edit ***

Nochmal ein wenig Rückmeldung:

Das Zertifikat läuft in Mai ab. Hab das Systemdatum auf Juni gesetzt und das Applet mal im IE mit zuvor geleertem Cache etc. ausgeführt. Bis zu dem Zeitpunkt wo der erste Dialog wie im ersten Screenshot gezeigt erscheint, wird folgendes in der Java-Console geloggt:

Java-Plug-in 10.51.2.13
JRE-Version verwenden 1.7.0_51-b13 Java HotSpot™ Client VM
Benutzer-Home-Verzeichnis = C:\Users\myuser

c: Konsolenfenster löschen
f: Objekte in Finalisierungs-Queue finalisieren
g: Garbage Collect
h: Diese Hilfemeldung anzeigen
l: Class Loader-Liste ausgeben
m: Speicherauslastung drucken
o: Logging auslösen
q: Konsole ausblenden
r: Policy-Konfiguration neu laden
s: System- und Deployment-Eigenschaften ausgeben
t: Threadliste ausgeben
v: Thread-Stack ausgeben
x: Class Loader-Cache leeren
0-5: Trace-Ebene auf setzen

cache: Initialize resource manager: com.sun.deploy.cache.ResourceProviderImpl@cf9bf0
basic: Fortschritts-Listener hinzugefügt: sun.plugin.util.ProgressMonitorAdapter@15ef3ab
basic: Plugin2ClassLoader.addURL parent called for http://company-9/company/company.jar
basic: Plugin2ClassLoader.addURL parent called for http://company-9/company/jdom.jar
basic: Plugin2ClassLoader.addURL parent called for http://company-9/company/jai_core.jar
basic: Plugin2ClassLoader.addURL parent called for http://company-9/company/jai_codec.jar
basic: Plugin2ClassLoader.addURL parent called for http://company-9/company/mlibwrapper_jai.jar
basic: Plugin2ClassLoader.addURL parent called for http://company-9/company/default.jar
basic: Plugin2ClassLoader.addURL parent called for http://company-9/company/lwf_jp2_jni.jar
basic: Plugin2ClassLoader.addURL parent called for http://company-9/company/icepdf-core.jar
basic: Plugin2ClassLoader.addURL parent called for http://company-9/company/icepdf-viewer.jar
basic: Plugin2ClassLoader.addURL parent called for http://company-9/company/font-engine.jar
basic: Plugin2ClassLoader.addURL parent called for http://company-9/company/plugin_upload.jar
basic: Plugin2ClassLoader.addURL parent called for http://company-9/company/network.jar
basic: Plugin2ClassLoader.addURL parent called for http://company-9/company/commons-codec.jar
basic: Plugin2ClassLoader.addURL parent called for http://company-9/company/commons-httpclient.jar
basic: Plugin2ClassLoader.addURL parent called for http://company-9/company/commons-logging.jar
basic: Plugin2ClassLoader.addURL parent called for http://company-9/company/patch_companyweb.jar
security: Blacklist-Entzugsprüfung ist aktiviert
security: blacklist: created: NEED_LOAD, lastModified: 1389866187087
security: blacklist: hasBeenModifiedSince 1389866229292 (we have 1389866187087)
security: Prüfung der Liste vertrauenswürdiger Librarys ist aktiviert
network: Cacheeintrag gefunden [URL: http://company-9/company/company.jar, Version: null] prevalidated=false/0
cache: Adding MemoryCache entry: http://company-9/company/company.jar
cache: Resource http://company-9/company/company.jar has expired.
network: Verbindung von http://company-9/company/company.jar mit Proxy=DIRECT wird hergestellt
network: Verbindung von http://company-9:80/ mit Proxy=DIRECT wird hergestellt
network: ResponseCode für http://company-9/company/company.jar: 304
network: Codierung für http://company-9/company/company.jar: null
network: Verbindung mit http://company-9/company/company.jar trennen
cache: Read manifest for http://company-9/company/company.jar: read=173 full=70429
cache: Loading full manifest for http://company-9/company/company.jarcache: Reading Signers from 4395 http://company-9/company/company.jar | C:\Users\myuser\AppData\LocalLow\Sun\Java\Deployment\cache\6.0\2\36fe3542-4a4a42d4.idx
cache: Done readSigners(http://company-9/company/company.jar)
security: Vertrauen für http://company-9/company/company.jar ist beendet: Thu Jan 01 01:00:00 CET 1970
security: Missing Application-Library-Allowable-Codebase manifest attribute for: http://company-9/company/company.jar
security: Zertifikate werden aus Deployment-Session-Zertifikatspeicher geladen
security: Zertifikate wurden aus Deployment-Session-Zertifikatspeicher geladen
security: Zertifikate werden aus Deployment-Session-Zertifikatspeicher geladen
security: Zertifikate wurden aus Deployment-Session-Zertifikatspeicher geladen
security: Zertifikate werden aus Deployment-Session-Zertifikatspeicher geladen
security: Zertifikate wurden aus Deployment-Session-Zertifikatspeicher geladen
security: Zertifikate werden aus Internet Explorer TrustedPublisher-Zertifikatspeicher geladen
security: Zertifikate wurden aus Internet Explorer TrustedPublisher-Zertifikatspeicher geladen
security: Zertifikate werden aus Internet Explorer DISALLOWED-Zertifikatspeicher geladen
security: Zertifikate wurden aus Internet Explorer DISALLOWED-Zertifikatspeicher geladen
security: Zertifikatkette mit CertPath-API validieren
security: Das Zertifikat ist abgelaufen. Zeitstempelinformationen müssen geprüft werden
security: Keine Zeitstempelinformationen verfügbar
security: Zertifikate werden aus Internet Explorer ROOT-Zertifikatspeicher geladen
security: Zertifikate wurden aus Internet Explorer ROOT-Zertifikatspeicher geladen
security: Loading blacklisted.certs file: C:\Users\myuser\AppData\LocalLow\Sun\Java\Deployment\security\blacklisted.certs
security: SHA-256Certificate finger print: B7122B3E5D5EBD477AD89B81B550906F2088D7EB24E562D79C07A8FB45E2E79F
security: Zertifikat wird in Internet Explorer DISALLOWED-Zertifikatspeicher gesucht
security: SHA-256Certificate finger print: AF840CA2B9DFB776BF81AA94C401BC440C52E5C590C43607A13D6680D83E3349
security: Zertifikat wird in Internet Explorer DISALLOWED-Zertifikatspeicher gesucht
security: SHA-256Certificate finger print: C99157DF28D28EBD87B8B041AACCF023CF1C9AD0D21FD7116149D7F96484FA51
security: Zertifikat wird in Internet Explorer DISALLOWED-Zertifikatspeicher gesucht
security: SHA-256Certificate finger print: AB7036365C7154AA29C2C29F5D4191163B162A2225011357D56D07FFA7BC1F72
security: Zertifikat wird in Internet Explorer DISALLOWED-Zertifikatspeicher gesucht
security: OCSP-Unterstützung ist aktiviert
security: CRL-Unterstützung ist aktiviert
security: Failing over to CRLs: Certificate does not specify OCSP responder
network: Cacheeintrag gefunden [URL: http://crl.thawte.com/ThawtePremiumServerCA.crl, Version: null] prevalidated=false/0
cache: Adding MemoryCache entry: http://crl.thawte.com/ThawtePremiumServerCA.crl
cache: Resource http://crl.thawte.com/ThawtePremiumServerCA.crl has expired.
network: Verbindung von http://crl.thawte.com/ThawtePremiumServerCA.crl mit Proxy=DIRECT wird hergestellt
network: Verbindung von http://crl.thawte.com:80/ mit Proxy=DIRECT wird hergestellt
network: ResponseCode für http://crl.thawte.com/ThawtePremiumServerCA.crl: 304
network: Codierung für http://crl.thawte.com/ThawtePremiumServerCA.crl: null
network: Verbindung mit http://crl.thawte.com/ThawtePremiumServerCA.crl trennen
network: Verbindung von http://ocsp.thawte.com/ mit Proxy=DIRECT wird hergestellt
network: Verbindung von http://ocsp.thawte.com:80/ mit Proxy=DIRECT wird hergestellt
security: Failing over to CRLs: java.io.IOException: Response is unreliable: its validity interval is out-of-date
network: Cacheeintrag gefunden [URL: http://crl.thawte.com/ThawtePCA.crl, Version: null] prevalidated=false/0
cache: Adding MemoryCache entry: http://crl.thawte.com/ThawtePCA.crl
cache: Resource http://crl.thawte.com/ThawtePCA.crl has expired.
network: Verbindung von http://crl.thawte.com/ThawtePCA.crl mit Proxy=DIRECT wird hergestellt
network: ResponseCode für http://crl.thawte.com/ThawtePCA.crl: 304
network: Codierung für http://crl.thawte.com/ThawtePCA.crl: null
network: Verbindung mit http://crl.thawte.com/ThawtePCA.crl trennen
network: Verbindung von http://ocsp.thawte.com/ mit Proxy=DIRECT wird hergestellt
network: Verbindung von http://ocsp.thawte.com:80/ mit Proxy=DIRECT wird hergestellt
security: Failing over to CRLs: java.io.IOException: Response is unreliable: its validity interval is out-of-date
network: Cacheeintrag gefunden [URL: http://cs-g2-crl.thawte.com/ThawteCSG2.crl, Version: null] prevalidated=false/0
cache: Adding MemoryCache entry: http://cs-g2-crl.thawte.com/ThawteCSG2.crl
cache: Resource http://cs-g2-crl.thawte.com/ThawteCSG2.crl has expired.
network: Verbindung von http://cs-g2-crl.thawte.com/ThawteCSG2.crl mit Proxy=DIRECT wird hergestellt
network: Verbindung von http://cs-g2-crl.thawte.com:80/ mit Proxy=DIRECT wird hergestellt
network: ResponseCode für http://cs-g2-crl.thawte.com/ThawteCSG2.crl: 304
network: Codierung für http://cs-g2-crl.thawte.com/ThawteCSG2.crl: null
network: Verbindung mit http://cs-g2-crl.thawte.com/ThawteCSG2.crl trennen
security: Zertifikatsvalidierung mit OCSP/CRL war erfolgreich
security: Zertifikat wird in Internet Explorer TrustedPublisher-Zertifikatspeicher gesucht
basic: Dialog type is not candidate for embedding

„Seltsame“ Stellen hab ich fett markiert. Hier mal die Stellen im einzelnen:

Vertrauen für http://company-9/company/company.jar ist beendet: Thu Jan 01 01:00:00 CET 1970

Seltsam. Wo kommt das 1970er Datum auf einmal her?!

Missing Application-Library-Allowable-Codebase manifest attribute for: http://company-9/company/company.jar

Werde das Attribut mal noch nachziehen. Die Meldung für dieses Attribut ist jetzt mit Jave7u51 neu.

security: Das Zertifikat ist abgelaufen. Zeitstempelinformationen müssen geprüft werden
security: Keine Zeitstempelinformationen verfügbar

Doof dass ich hier nicht weiß welches das sein soll?! Etwa das von „company.jar“? Der Check mir JarSigner bestätigt aber, dass es einen Zeitstempel gibt:

[entry was signed on 16.01.14 02:52]

Das spuckt der Jarsigner für jede File in der JAR aus … Wieso ist da also etwas nicht mit Zeitstempel signiert?!

security: Failing over to CRLs: java.io.IOException: Response is unreliable: its validity interval is out-of-date

Hmm, könnte evtl. von meiner vorgedrehten Systemzeit stammen?! Aber wie sonst soll ich prüfen wie die Anwendung mit abgelaufenen Zertifikat reagiert (bevor es tatsächlich abgelaufen und somit zu spät ist).

12

Zum letzten Punkt.

Du könntest dir ein Self-Signed-Zertifikat erstellen, daß in z.B. einer Stunde abläuft oder einem Tag. Bauen zeitstempeln und nach der Mittagspause/Morgen/Montag schauen was passiert.

13

(Leider) nur kurz dazu: Das ist Sekunde 0 der http://de.wikipedia.org/wiki/Unixzeit , bzw. die Zeit, bei der System.currentTimeMillis() genau 0 geliefert hat (+Zeitzone/Sommerzeit) - könnte also (wild geraten) schlicht ein „Bug in der Fehlermeldung“ sein…

14

[QUOTE=tuxedo]Zertifikat stammt von http://www.thawte.de/ und ist von Thawte für die Java-Code-SIgnierung vorgesehen.
TSA Url ist die von Thawte „empfohlene“: ]https://timestamp.geotrust.com/tsa[/Quote]

Die TSA-URL taucht auch in dem von Unregistered gepostetem Oracle Link auf, man sollte also eigentlich annehmen, dass die TSA als gültig erkannt wird.

Allerdings ließe sich eingrenzen ob das Problem im Signierungsprozess oder der eigentlichen Anwendung liegt. So früh, wie der Fehler geworfen wird, kann es aber eigentlich noch gar nicht an der Anwendung selbst liegen. Ein weiterer Punkt wäre, ob das Problem nur beim direkten Laden über die Applet-Tags auftritt oder auch bei dem eigentlich mittlerweile aktuellem Weg, bei dem das Applet über JNLP geladen wird. Im Log sieht es so aus, als ob Ihr kein JNLP verwendet?

Ich weiß allerdings auch nicht, inwieweit sich das TSA-Verhalten zwischen diesen beiden Varianten unterscheidet.

Ja, die Widerrufslisten sind immer zeitlich beschränkt. Oft haben diese nur eine Gültigkeit von einem Monat. Normalerweise sind die aber auch optional, es sollte also imho keine Rolle spielen das so keine Gültige gefunden wird. Spannend wäre das erst bei der Frage, was mit einem korrekt mit TSA signiertem Applet passiert bei dem das Zertifikat widerrufen wurde.

Imho werden selbst signierte Zertifikate von der aktuellen JRE inzwischen nicht mehr akzeptiert. Man müsste also vorher eine CA/PKI aufsetzen und das selbst signierte Wurzelzertifikat in den Zertifikatspeicher der JRE importieren. Geht, wenn man das zum ersten Mal macht, kann das aber etwas fummelig sein.

Das ist das spannende. Eine mögliche Ursache kann ich Dir allerdings leider nicht nennen.

Viele Grüße
Fancy

15

Hallo,

Man muß die Sicherheitseinstellung im JavaControlPanel auf „Mittel“ stellen (Schieberegler ganz nach unten) oder (im selben Reiter) einen Eintrag in der Siteliste machen. Dann funktioniert es wieder.

Details dazu erfährst du auch hier: Java Applets starten - ab Java 7 Update 51 – Byte-Welt Wiki

MfG
hansmueller