info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Webstart Zertifikat Verifizierung
707 views
Skip to first unread message
Dirk Niemeier
Apr 24, 2014, 8:46:57 AM4/24/14
to
Hallo zusammen,
ich habe eine Web Start Anwendung mit einem CAcert Zertifikat unter Java 8. Es funktioniert mitlerweile auch alles ganz super, nach dem ich mit meinem selbst generierten Zertifikat seit Java 7.0.45 nicht mehr weiter kam. Javaws verifiziert die Anwendung und startet dann ganz normal. Nur manchmal, ich habe bisher nicht die Umstände ermitteln können, kommt die Meldung "Zertifikat konnte nicht validiert werden. Die Anwendung wird nicht ausgeführt"
Und diese Exception:
java.security.cert.CertificateException: java.security.cert.CertPathValidatorException: OCSP response error: MALFORMED_REQUEST
at com.sun.deploy.security.RevocationChecker.checkOCSP(Unknown Source)
at com.sun.deploy.security.RevocationChecker.check(Unknown Source)
at com.sun.deploy.security.TrustDecider.checkRevocationStatus(Unknown Source)
at com.sun.deploy.security.TrustDecider.getValidationState(Unknown Source)
at com.sun.deploy.security.TrustDecider.validateChain(Unknown Source)
at com.sun.deploy.security.TrustDecider.isAllPermissionGranted(Unknown Source)
at com.sun.javaws.security.AppPolicy.grantUnrestrictedAccess(Unknown Source)
at com.sun.javaws.security.JNLPSignedResourcesHelper.checkSignedResourcesHelper(Unknown Source)
at com.sun.javaws.security.JNLPSignedResourcesHelper.checkSignedResources(Unknown Source)
at com.sun.javaws.Launcher.prepareResources(Unknown Source)
....
Hat jemand eine Idee warum die Verifizierung gelegentlich fehlschlägt?
TIA
Dirk
ich habe eine Web Start Anwendung mit einem CAcert Zertifikat unter Java 8. Es funktioniert mitlerweile auch alles ganz super, nach dem ich mit meinem selbst generierten Zertifikat seit Java 7.0.45 nicht mehr weiter kam. Javaws verifiziert die Anwendung und startet dann ganz normal. Nur manchmal, ich habe bisher nicht die Umstände ermitteln können, kommt die Meldung "Zertifikat konnte nicht validiert werden. Die Anwendung wird nicht ausgeführt"
Und diese Exception:
java.security.cert.CertificateException: java.security.cert.CertPathValidatorException: OCSP response error: MALFORMED_REQUEST
at com.sun.deploy.security.RevocationChecker.checkOCSP(Unknown Source)
at com.sun.deploy.security.RevocationChecker.check(Unknown Source)
at com.sun.deploy.security.TrustDecider.checkRevocationStatus(Unknown Source)
at com.sun.deploy.security.TrustDecider.getValidationState(Unknown Source)
at com.sun.deploy.security.TrustDecider.validateChain(Unknown Source)
at com.sun.deploy.security.TrustDecider.isAllPermissionGranted(Unknown Source)
at com.sun.javaws.security.AppPolicy.grantUnrestrictedAccess(Unknown Source)
at com.sun.javaws.security.JNLPSignedResourcesHelper.checkSignedResourcesHelper(Unknown Source)
at com.sun.javaws.security.JNLPSignedResourcesHelper.checkSignedResources(Unknown Source)
at com.sun.javaws.Launcher.prepareResources(Unknown Source)
....
Hat jemand eine Idee warum die Verifizierung gelegentlich fehlschlägt?
TIA
Dirk
Manfred Schenk
Apr 28, 2014, 4:35:42 AM4/28/14
to
Dirk Niemeier <dirk.nie...@gmail.com> wrote:
> Hallo zusammen,
> ich habe eine Web Start Anwendung mit einem CAcert Zertifikat unter Java 8. Es funktioniert mitlerweile auch alles ganz super, nach dem ich mit meinem selbst generierten Zertifikat seit Java 7.0.45 nicht mehr weiter kam. Javaws verifiziert die Anwendung und startet dann ganz normal. Nur manchmal, ich habe bisher nicht die Umstände ermitteln können, kommt die Meldung "Zertifikat konnte nicht validiert werden. Die Anwendung wird nicht ausgeführt"
> Und diese Exception:
>
> java.security.cert.CertificateException: java.security.cert.CertPathValidatorException: OCSP response error: MALFORMED_REQUEST
Also die Fehlermeldung besagt dass der OCSP-Server bei der CA den von dir
> Hallo zusammen,
> ich habe eine Web Start Anwendung mit einem CAcert Zertifikat unter Java 8. Es funktioniert mitlerweile auch alles ganz super, nach dem ich mit meinem selbst generierten Zertifikat seit Java 7.0.45 nicht mehr weiter kam. Javaws verifiziert die Anwendung und startet dann ganz normal. Nur manchmal, ich habe bisher nicht die Umstände ermitteln können, kommt die Meldung "Zertifikat konnte nicht validiert werden. Die Anwendung wird nicht ausgeführt"
> Und diese Exception:
>
> java.security.cert.CertificateException: java.security.cert.CertPathValidatorException: OCSP response error: MALFORMED_REQUEST
geschickten Request abgelehnt hat mit MALFORMED_REQUEST.
Die eigentliche Frage ist also:
Wer von beiden hält sich nicht an den Standard, der OCSP-Server der CA oder
die Client-Implementierung im Java?
Oder gibt es evtl. Freiheiten bei der Implementierung der Spec. die in
ungünstigen Konstellationen zu dem von dir beobachteten Ergebnis führen
können?
cu,
Manfred
--
| Manfred Schenk | born between RFC638 and RFC640
| |
| | WWW: http://www.ZEROByte.de/
Matthias Hunstock
Apr 28, 2014, 10:17:48 AM4/28/14
to
Am 28.04.2014 10:35, schrieb Manfred Schenk:
> Oder gibt es evtl. Freiheiten bei der Implementierung der Spec. die in
> ungünstigen Konstellationen zu dem von dir beobachteten Ergebnis führen
> können?
Ursprünglich war nicht mal klar, ob man die Abfrage per GET oder POST
> Oder gibt es evtl. Freiheiten bei der Implementierung der Spec. die in
> ungünstigen Konstellationen zu dem von dir beobachteten Ergebnis führen
> können?
stellt. Da gab es sehr viele Inkompatibilitäten.
Hier gibts mehr Infos zu dem verwendeten OCSP Responder und eine
Befehlszeile zum Testen: http://wiki.cacert.org/OcspResponder
Dirk Niemeier
Apr 29, 2014, 6:18:14 AM4/29/14
to
Hallo,
es scheint mir ja so zu sein, dass Java WebStart immer den OCSP Server anfragt um die Gültigkeit der Zertifikate zu prüfen. Beim Firefox kann man noch entscheiden ob das Zertifikat trotzdem zugelassen wird bei einem OCSP verification problem. Kann man beim Webstart die Prüfung auch beeinflussen?
TIA
Dirk
es scheint mir ja so zu sein, dass Java WebStart immer den OCSP Server anfragt um die Gültigkeit der Zertifikate zu prüfen. Beim Firefox kann man noch entscheiden ob das Zertifikat trotzdem zugelassen wird bei einem OCSP verification problem. Kann man beim Webstart die Prüfung auch beeinflussen?
TIA
Dirk
Dirk Niemeier
Apr 29, 2014, 6:41:39 AM4/29/14
to
verification problem. Kann man beim Webstart die Prüfung auch beeinflussen?
eigentlich möchte ich gar keine externe Prüfung haben, da es sich um eine interne Anwendung handelt. Hier könnte ich auf jedem Client auch etwas konfgurieren.
Kann man da im Java Control Panel vielleicht etwas dazu einstellen? Mit der Liste der ausgenommenen Websites habe ich schon rum probiert, aber ohne Erfolg.
>
> TIA
>
> Dirk
Matthias Hunstock
Apr 29, 2014, 11:22:31 AM4/29/14
to
Am 29.04.2014 12:41, schrieb Dirk Niemeier:
> Kann man da im Java Control Panel vielleicht etwas dazu einstellen?
Ich meine unl�ngst auf Grund des gleichen Problems dort eine Einstellung
> Kann man da im Java Control Panel vielleicht etwas dazu einstellen?
gesehen zu haben, mit der man den Revocation Check deaktivieren konnte.
Im CP gibts bei mir unter Erweitert/Sicherheit/Allgemein einen Punkt
"Onlinezertifikatsvalidierung aktivieren", der deaktiviert ist. Direkt
dr�ber ist die entsprechende Option f�r die CRL-Pr�fung.
Ich bin mir aber nicht sicher, ob das auch f�r Webstart greift.
Matthias Hunstock
Apr 29, 2014, 11:24:27 AM4/29/14
to
Am 29.04.2014 12:41, schrieb Dirk Niemeier:
> Hier k�nnte ich auf jedem Client auch etwas konfgurieren.
Da tut vielleicht ein Zertifikat von einer selbst erstellten CA bessere
Dienste, zumal man das mit einer entsprechend langen Laufzeit erstellen
kann. Also nicht self-signed, sondern "zweistufig". Dann muss eben die
CA als vertrauensw�rdige CA importiert werden, und die entsprechende
Datei kann u.U. sogar leichter auf den Clients ausgerollt werden.
Bernd Waterkamp
Apr 29, 2014, 1:20:10 PM4/29/14
to
Dirk Niemeier schrieb:
> verification problem. Kann man beim Webstart die Pr�fung auch beeinflussen?
Wenn du es abschalten m�chtest und ich
http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/jcp/properties.html
richtig deute, sollte es reichen im jnlp-File oder auf dem Client
deployment.security.validation.ocsp und deployment.security.validation.crl
auf false zu setzen.
> verification problem. Kann man beim Webstart die Pr�fung auch beeinflussen?
Wenn du es abschalten m�chtest und ich
http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/jcp/properties.html
richtig deute, sollte es reichen im jnlp-File oder auf dem Client
deployment.security.validation.ocsp und deployment.security.validation.crl
auf false zu setzen.
Dirk Niemeier
Apr 30, 2014, 2:50:26 AM4/30/14
to
Hallo Bernd,
> Wenn du es abschalten m�chtest und ich
TIA
Dirk
> Wenn du es abschalten m�chtest und ich
>
> http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/jcp/properties.html
>
> richtig deute, sollte es reichen im jnlp-File oder auf dem Client
>
> deployment.security.validation.ocsp und deployment.security.validation.crl
>
> auf false zu setzen.
weisst du denn wie man das dem JNLP File mitgeben kann? In den JNLP Spezifikationen kann ich dazu nichts finden. Wäre meiner Meinung aber auch eine Sicherheitslücke wenn das gehen würde.
> http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/jcp/properties.html
>
> richtig deute, sollte es reichen im jnlp-File oder auf dem Client
>
> deployment.security.validation.ocsp und deployment.security.validation.crl
>
> auf false zu setzen.
TIA
Dirk
Dirk Niemeier
Apr 30, 2014, 2:55:05 AM4/30/14
to
Hallo Matthias,
TIA
Dirk
> Da tut vielleicht ein Zertifikat von einer selbst erstellten CA bessere
>
> Dienste, zumal man das mit einer entsprechend langen Laufzeit erstellen
>
> kann. Also nicht self-signed, sondern "zweistufig". Dann muss eben die
>
> CA als vertrauensw�rdige CA importiert werden, und die entsprechende
>
> Dienste, zumal man das mit einer entsprechend langen Laufzeit erstellen
>
> kann. Also nicht self-signed, sondern "zweistufig". Dann muss eben die
>
>
> Datei kann u.U. sogar leichter auf den Clients ausgerollt werden.
Ich habe ein Zertifikat von CAcert.org. Ich habe allerding das Zertifikat nur in den Keystore ..\cacerts importiert. Meinst du ich muß das auch im Java Control Panel als "CA für sichere Site" importieren? Bisher habe ich leider nirgends mal eine Erklärung/Beschreibung dazu gefunden.
> Datei kann u.U. sogar leichter auf den Clients ausgerollt werden.
TIA
Dirk
Matthias Hunstock
Apr 30, 2014, 6:38:28 AM4/30/14
to
Am 30.04.2014 08:55, schrieb Dirk Niemeier:
> Ich habe allerding das Zertifikat nur in den Keystore ..\cacerts
> importiert. Meinst du ich mu� das auch im Java Control Panel als
> Ich habe allerding das Zertifikat nur in den Keystore ..\cacerts
> "CA f�r sichere Site" importieren? Bisher habe ich leider nirgends
> mal eine Erkl�rung/Beschreibung dazu gefunden.
Keine Ahnung.. hast du den Import auch mit dieser -trustedroot Option
gemacht? Irgendwas musste da beachtet werden, sonst importiert er es
zwar in den Keystore, aber vertraut dem Zert trotzdem nicht.
Matthias Hunstock
Apr 30, 2014, 6:41:48 AM4/30/14
to
Am 30.04.2014 08:50, schrieb Dirk Niemeier:
> weisst du denn wie man das dem JNLP File mitgeben kann?
> In den JNLP Spezifikationen kann ich dazu nichts finden.
> W�re meiner Meinung aber auch eine Sicherheitsl�cke wenn
> weisst du denn wie man das dem JNLP File mitgeben kann?
> In den JNLP Spezifikationen kann ich dazu nichts finden.
> das gehen w�rde.
Da das JNLP-File nicht signiert ist, in der Tat.
Ich lese in der verlinkten Doku allerdings auch nur die M�glichkeit
heraus, das auf dem Client in der deployment.properties zu setzen.
Bernd Waterkamp
Apr 30, 2014, 12:40:48 PM4/30/14
to
Matthias Hunstock schrieb:
> Am 30.04.2014 08:50, schrieb Dirk Niemeier:
>> weisst du denn wie man das dem JNLP File mitgeben kann?
>> In den JNLP Spezifikationen kann ich dazu nichts finden.
>> W�re meiner Meinung aber auch eine Sicherheitsl�cke wenn
>> das gehen w�rde.
>
> Da das JNLP-File nicht signiert ist, in der Tat.
Sorry, das geht nicht und war nat�rlich Unsinn. Da hat mir mein Ged�chtnis
einen Streich gespielt.
> Ich lese in der verlinkten Doku allerdings auch nur die M�glichkeit
> heraus, das auf dem Client in der deployment.properties zu setzen.
Ja, da geh�rt das auch hin. Eine modifizierte deployment.properties mit der
entsprechenden Java-Version auszuliefern sollte ja insbesondere wenn ein
Software-Verteilungsverfahren f�r die Clients vorhanden ist keinen gro�en
Aufwand bedeuten.
Gr��e,
Bernd
> Am 30.04.2014 08:50, schrieb Dirk Niemeier:
>> weisst du denn wie man das dem JNLP File mitgeben kann?
>> In den JNLP Spezifikationen kann ich dazu nichts finden.
>> W�re meiner Meinung aber auch eine Sicherheitsl�cke wenn
>> das gehen w�rde.
>
> Da das JNLP-File nicht signiert ist, in der Tat.
einen Streich gespielt.
> Ich lese in der verlinkten Doku allerdings auch nur die M�glichkeit
> heraus, das auf dem Client in der deployment.properties zu setzen.
entsprechenden Java-Version auszuliefern sollte ja insbesondere wenn ein
Software-Verteilungsverfahren f�r die Clients vorhanden ist keinen gro�en
Aufwand bedeuten.
Gr��e,
Bernd
Bernd Waterkamp
Apr 30, 2014, 1:53:59 PM4/30/14
to
Matthias Hunstock schrieb:
Bin ich jetzt schon wieder auf dem Holzweg oder verwechselst du diesmal
was? :-) Es gibt bei keytool die Option trustcacerts. Die bewirkt, das man
beim Import nicht die ganze Trustchain mitliefern muss, wenn in der
cacerts-Datei bereits ein passendes CA-Zertifikate enthalten ist.
Das von Dirk beschriebe Problem liegt aber woanders: OCSP ist ein Protokoll
um durch R�ckfrage bei einer CA festzustellen, ob ein von denen aus-
gestelltes Zertifikat noch g�ltig ist oder zur�ckgerufen wurde. Auch CACert
betreibt einen solchen OCSP-Responder. http://wiki.cacert.org/OcspResponder
Der antwortet scheinbar manchmal mit malformed request. Das kommt wohl z.B.
dann vor, wenn der verwendete Hash-Algorithmus dort nicht unterst�tzt wird
oder dem CACert-Server sonstwas nicht passt. Vielleicht haben die
Loadbalancing auf mehrere Server und stellen gerade was um. Das Problem
k�nnte aber auch ganz woanders liegen und der Client sendet z.B. durch
einen Bug in Java8 mal richtige und mal "malformed requests". In jedem Fall
ist die Gegenstelle unzufrieden mit dem OCSP-Request, nicht die JVM.
Wenn man das Problem im Detail untersuchen m�chte, muss man wohl in den
Code der JRE schauen und die OCSP-Requests tracen, die zu CACert rausgehen.
Will man in erster Linie den Fehler vermeiden, sollte es ausreichen, das
OCSP-Checking in den deployment.properties abzuschalten. Das geht auch f�r
alle Benutzer eines Clients auf einen Rutsch, siehe "System Level" unter
http://docs.oracle.com/javase/8/docs/technotes/guides/jweb/jcp/properties.html
OCSP ist - und sp�testens hier ist es v�llig unabh�ngig von Java - schon
lange nicht unumstritten. Sp�testens seit Heartbleed kocht die Diskussion
wieder hoch, siehe z.B. die Beitr�ge von Adam Langley aus Googles Security-
Team. Chrome verwendet bewu�t kein OCSP mehr:
https://www.imperialviolet.org/2012/02/05/crlsets.html
https://www.imperialviolet.org/2014/04/19/revchecking.html
Gr��e,
Bernd
was? :-) Es gibt bei keytool die Option trustcacerts. Die bewirkt, das man
beim Import nicht die ganze Trustchain mitliefern muss, wenn in der
cacerts-Datei bereits ein passendes CA-Zertifikate enthalten ist.
Das von Dirk beschriebe Problem liegt aber woanders: OCSP ist ein Protokoll
um durch R�ckfrage bei einer CA festzustellen, ob ein von denen aus-
gestelltes Zertifikat noch g�ltig ist oder zur�ckgerufen wurde. Auch CACert
betreibt einen solchen OCSP-Responder. http://wiki.cacert.org/OcspResponder
Der antwortet scheinbar manchmal mit malformed request. Das kommt wohl z.B.
dann vor, wenn der verwendete Hash-Algorithmus dort nicht unterst�tzt wird
oder dem CACert-Server sonstwas nicht passt. Vielleicht haben die
Loadbalancing auf mehrere Server und stellen gerade was um. Das Problem
k�nnte aber auch ganz woanders liegen und der Client sendet z.B. durch
einen Bug in Java8 mal richtige und mal "malformed requests". In jedem Fall
ist die Gegenstelle unzufrieden mit dem OCSP-Request, nicht die JVM.
Wenn man das Problem im Detail untersuchen m�chte, muss man wohl in den
Code der JRE schauen und die OCSP-Requests tracen, die zu CACert rausgehen.
Will man in erster Linie den Fehler vermeiden, sollte es ausreichen, das
OCSP-Checking in den deployment.properties abzuschalten. Das geht auch f�r
alle Benutzer eines Clients auf einen Rutsch, siehe "System Level" unter
http://docs.oracle.com/javase/8/docs/technotes/guides/jweb/jcp/properties.html
OCSP ist - und sp�testens hier ist es v�llig unabh�ngig von Java - schon
lange nicht unumstritten. Sp�testens seit Heartbleed kocht die Diskussion
wieder hoch, siehe z.B. die Beitr�ge von Adam Langley aus Googles Security-
Team. Chrome verwendet bewu�t kein OCSP mehr:
https://www.imperialviolet.org/2012/02/05/crlsets.html
https://www.imperialviolet.org/2014/04/19/revchecking.html
Gr��e,
Bernd
Matthias Hunstock
May 8, 2014, 7:43:52 AM5/8/14
to
Am 30.04.2014 19:53, schrieb Bernd Waterkamp:
> Die bewirkt, das man
> beim Import nicht die ganze Trustchain mitliefern muss, wenn in der
> cacerts-Datei bereits ein passendes CA-Zertifikate enthalten ist.
Es ging darum, ein (Root-)CA-Zert zu importieren, welches noch gar nicht
> Die bewirkt, das man
> beim Import nicht die ganze Trustchain mitliefern muss, wenn in der
> cacerts-Datei bereits ein passendes CA-Zertifikate enthalten ist.
enthalten ist. Ich habe jetzt nicht nachgesehen, aber ich gehe nicht
davon aus, dass CAcert mit Java ausgeliefert wird.
> Das von Dirk beschriebe Problem liegt aber woanders: OCSP ist ein Protokoll
> um durch R�ckfrage bei einer CA festzustellen, ob ein von denen aus-
> gestelltes Zertifikat noch g�ltig
am 28.4.
Auf den gammligen OCSP-Responder von CAcert hat Dirk ja nunmal keinen
Einfluss, daher schlug ich vor, gleich ein eigenes Zert zu bauen und
dar�ber kamen wir auf die Truststore-Geschichte.
Bernd Waterkamp
May 8, 2014, 6:02:14 PM5/8/14
to
Matthias Hunstock schrieb:
> Am 30.04.2014 19:53, schrieb Bernd Waterkamp:
>> Die bewirkt, das man
>> beim Import nicht die ganze Trustchain mitliefern muss, wenn in der
>> cacerts-Datei bereits ein passendes CA-Zertifikate enthalten ist.
>
> Es ging darum, ein (Root-)CA-Zert zu importieren, welches noch gar nicht
> enthalten ist.
Das hatte ich schon verstanden. Die Erkl�rung zu OCSP habe ich
eingeschoben, weil ich das Posting von Manfred �bersehen habe. Und die zu
trustcacerts kam, weil ich zumindest in der Hilfe des JDK 7 keytools und im
CA-Cert-Wiki keine Option finden konnte, die trustedroot oder �hnlich
heisst und von einer Verwechselung ausgegangen bin. trustedcacerts schadet
in diesem Fall (CACert) beim Import nicht, bringt aber auch keinen Nutzen.
> Ich habe jetzt nicht nachgesehen, aber ich gehe nicht
> davon aus, dass CAcert mit Java ausgeliefert wird.
Da liegst du richtig.
> Ja, das hatten wir doch schon alles durch, siehe z.B. Post von Manfred
> am 28.4.
Siehe oben - den hab' ich �bersehen, sonst h�tten wir das abk�rzen k�nnen.
Ich halte es f�r die nahe liegende L�sung wenn Dirk ansonsten mit seiner
derzeitigen CACert-L�sung zufrieden ist, da sich �ber den Nutzwert von OCSP
eben streiten l�sst. Viel mehr Arbeit ist aber CA+Cert selber bauen und
Truststore verteilen in der Tat auch nicht.
Gr��e,
Bernd
> Am 30.04.2014 19:53, schrieb Bernd Waterkamp:
>> Die bewirkt, das man
>> beim Import nicht die ganze Trustchain mitliefern muss, wenn in der
>> cacerts-Datei bereits ein passendes CA-Zertifikate enthalten ist.
>
> Es ging darum, ein (Root-)CA-Zert zu importieren, welches noch gar nicht
> enthalten ist.
eingeschoben, weil ich das Posting von Manfred �bersehen habe. Und die zu
trustcacerts kam, weil ich zumindest in der Hilfe des JDK 7 keytools und im
CA-Cert-Wiki keine Option finden konnte, die trustedroot oder �hnlich
heisst und von einer Verwechselung ausgegangen bin. trustedcacerts schadet
in diesem Fall (CACert) beim Import nicht, bringt aber auch keinen Nutzen.
> Ich habe jetzt nicht nachgesehen, aber ich gehe nicht
> davon aus, dass CAcert mit Java ausgeliefert wird.
> Ja, das hatten wir doch schon alles durch, siehe z.B. Post von Manfred
> am 28.4.
Ich halte es f�r die nahe liegende L�sung wenn Dirk ansonsten mit seiner
derzeitigen CACert-L�sung zufrieden ist, da sich �ber den Nutzwert von OCSP
eben streiten l�sst. Viel mehr Arbeit ist aber CA+Cert selber bauen und
Truststore verteilen in der Tat auch nicht.
Gr��e,
Bernd
0 new messages