hbci4java-help Mailing List for HBCI4Java (Page 4)
Brought to you by:
kleiner77
Menu
▾
▴
hbci4java-help — all questions concerning hbci4java
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(21) |
Jun
|
Jul
(9) |
Aug
(2) |
Sep
(16) |
Oct
(9) |
Nov
(10) |
Dec
(31) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(16) |
Feb
(43) |
Mar
(11) |
Apr
(4) |
May
(2) |
Jun
(7) |
Jul
|
Aug
(5) |
Sep
(2) |
Oct
(20) |
Nov
(32) |
Dec
(10) |
| 2005 |
Jan
(15) |
Feb
(15) |
Mar
(20) |
Apr
(19) |
May
(1) |
Jun
(5) |
Jul
(1) |
Aug
(9) |
Sep
(6) |
Oct
(5) |
Nov
(2) |
Dec
(1) |
| 2006 |
Jan
(34) |
Feb
|
Mar
(9) |
Apr
|
May
(12) |
Jun
(27) |
Jul
(2) |
Aug
(1) |
Sep
(11) |
Oct
(11) |
Nov
(7) |
Dec
(1) |
| 2007 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
(23) |
| 2008 |
Jan
(1) |
Feb
(1) |
Mar
(3) |
Apr
(32) |
May
(29) |
Jun
(22) |
Jul
(3) |
Aug
(5) |
Sep
(25) |
Oct
(30) |
Nov
(25) |
Dec
(1) |
| 2009 |
Jan
(23) |
Feb
(20) |
Mar
(20) |
Apr
(72) |
May
(9) |
Jun
(3) |
Jul
(18) |
Aug
|
Sep
(6) |
Oct
(7) |
Nov
(10) |
Dec
|
| 2010 |
Jan
(19) |
Feb
|
Mar
(3) |
Apr
|
May
(1) |
Jun
(11) |
Jul
(3) |
Aug
(19) |
Sep
(7) |
Oct
|
Nov
|
Dec
(2) |
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(14) |
Jun
(1) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
(3) |
| 2012 |
Jan
(2) |
Feb
(1) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(3) |
Aug
|
Sep
|
Oct
(1) |
Nov
(4) |
Dec
|
|
From: Vinh <arb...@go...> - 2010-03-15 07:02:45
|
Hi, ich habe gestern mich an der HBCIBatch Demo versucht. Die Passport Datei für PIN/TAN habe ich erstellt sowie die properties files angepasst. Leider bekomme ich es immer noch nicht hin, mich mit der comdirect zu verbinden um meinen Kontostand abzufragen. Beim verbinden erhalte ich eine "java.lang.IllegalArgumentException: URI can't be null". <ERR> [2010.03.15 00:33:08.893] [main/main] manager.HBCIUtils: org.kapott.hbci.exceptions.HBCI_Exception: error while sending message to HBCI server at org.kapott.hbci.comm.CommPinTan.ping(CommPinTan.java:136) at org.kapott.hbci.comm.Comm.pingpong(Comm.java:66) at org.kapott.hbci.manager.HBCIKernelImpl.rawDoIt(HBCIKernelImpl.java:358) at org.kapott.hbci.manager.HBCIKernelImpl.rawDoIt(HBCIKernelImpl.java:184) at org.kapott.hbci.manager.HBCIInstitute.fetchBPD(HBCIInstitute.java:227) at org.kapott.hbci.manager.HBCIInstitute.register(HBCIInstitute.java:371) at org.kapott.hbci.manager.HBCIHandler.registerInstitute(HBCIHandler.java:196) at org.kapott.hbci.manager.HBCIHandler.<init>(HBCIHandler.java:131) at org.kapott.hbci.tools.HBCIBatch.main(HBCIBatch.java:255) Caused by: java.lang.IllegalArgumentException: URI can't be null. at sun.net.spi.DefaultProxySelector.select(DefaultProxySelector.java:111) at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:786) at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:158) at sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:133) at org.kapott.hbci.comm.CommPinTan.ping(CommPinTan.java:126) ... 8 more Hat jemand ein Tipp an was das liegen könnte? Grüße Vinh |
|
From: HBCI4Java (S. Palme) <hbc...@ka...> - 2010-03-11 12:52:39
|
Hallo Martin, vielen Dank für die Dateien. Ich erlaube mir mal, die Mail an die Mailing-Liste zu CCen, denn das Problem betrifft mehrere Personen... Wie schon vermutet - mit den StarMoney-6-Dateien treten keine Probleme auf. Das StarMoney-7-File konnte ich zunächst ebenfalls nicht öffnen - das entspricht genau dem Bug, der mir schon des öfteren berichtet wurde. Dank Deiner Dateien habe ich den Fehler jedoch gefunden: StarMoney-7 treibt Unfug ;-) Zum einen wird das RDH-2-Dateiformat verwendet, um darin RDH-10- Schlüssel abzuspeichern (was technisch zwar möglich, aber nicht im Sinne des Erfinders ist) - damit kam HBCI4Java auch noch zurecht. Des weiteren wird ein Feld, welches sowohl in der Spezifikation für RDH-2- als auch für RDH-10-Dateien als "reserved for future use" deklariert und mit einem festen Wert versehen ist, für eigene Zwecke missbraucht. Damit kam die HBCI4Java-Implementierung dieses Datei- formates nicht klar. Das Problem ist nun im SVN gefixt (ChangeSet r237 und r240). Da mir leider nicht ganz klar ist, was genau StarMoney mit diesem Wert eigentlich treibt, ist die in HBCI4Java implementierte Heuristik möglicherweise nicht richtig - also bitte mal testen... Gruß -stefan- On Thu, 2010-03-11 at 09:06 +0100, Martin Schniewind wrote: > Hallo Stefan, > > Alles klar. Dateien anbei. > > Liebe Grüße > > Martin > > HBCI4Java (Stefan Palme) schrieb am 11.03.2010 08:58: > > Ja, zwei Testdateien (StarMoney-6, StarMoney-7) wären sehr hilfreich... |
|
From: Rolf V. <ro...@we...> - 2010-01-15 08:03:57
|
> Hi,
>
> wofuer eigentlich dieses zwanghaft englische Geschreibe?
> Niemand ausserhalb von Deutschland verwendet HBCI.
Naja, eigentlich sollte HBCI ja mal ein internationaler Standard werden. Hat aber nicht so ganz hingehauen ...
> > Strange, I canŽt find any blame at all.
> > A simple "no" to my question if you knew
> > a way or code to do this was all that was required.
> > So IŽll just look for myself next time I have some
> > spare cycles to use on this program.
> Schreib einen eigenen TrustManager.
>
> SSLContext ctx = SSLContext.getInstance(...);
> KeyManagerFactory km = KeyManagerFactory.getInstance(...);
> km.init(keystore,"...".toCharArray());
>
> TrustManager tm = new MyTrustManager();
> ctx.init(km.getKeyManagers(),new TrustManager[]{tm},null);
> > >> You are proposing to sit here for weeks to find all hbci-servers
> > >> of all banks on this planet and then to constantly monitor them.
Naja, wie Olaf schon schrieb, der Planet ist hier gar nicht relevant, die HBCI-Server stehen alle in Deutschland, und es sind gar nicht so arg viele, mich würde es wundern, wenn es mehr als 30 - 40 öffentlich zugängliche wären.
Außerdem ist das Zertifikat des Servers selbst nicht relevant, bloß wenn sich an der Kette, an der das Zertifiakt hängt, was verändert hätte, könnte es notwendig sein, irgendwas zu machen. Aber diese Zertifikate gehören ja alle den Trust Centern und sind oftmals sehr lange gültig (mehrere Jahre bis mehrere Jahrzehnte (!)). Sprich: Wenn erstmal alles läuft, ist vermutlich für einige Jahre Ruhe.
> > > I do not. But you seem to think I have to time to do this, just to
> > > make *you* happy. You are wrong.
> >
> > Why? Did I propose you to do this job or just show
> > how rediculus a solution your proposal was?
"Rediculus" ist es nicht, wenn man's richtig macht. Die Browser machen es ja auch so: Die enthalten die Stammzertifikate und andere Zertifikate der Trust Center, und gegen diese eingebauten Zertifikate werden dann die Zertifikate der besuchten Seiten geprüft. Wenn dabei eine gültige Kette zu einem gültigen Trust Anchor zustande kommt, akzeptiert der Browser das Zertifikat des Webservers ohne Rückfrage beim User. Das ist schon sehr lange so, und scheint wohl auch gut zu funktionieren.
> Nochmal. Ich kann deinen Postings nicht entnehmen, wer deine
> User sind. Woher soll dann jemand wissen, ob die mehr als
> ein Konto haben koennen?
Aus der allerersten Mail ging fast garnichts hervor. Wer Fragen stellt, sollte die notwendigen Infos kurz erwähnen, damit ihm geholfen werden kann.
> > > But this is not a *HBCI4Java related* problem, so I can only give
> > > you the advice to learn how to deal with SSL certificates in Java,
> > > and do not blame others for the fact that you don't know.
> >
> > Did I say it is?
> Warum hast du die Frage dann in der HBCI4Java-Mailingliste
> gestellt und nicht z.Bsp. in de.comp.lang.java?
Man muss erst mal wissen, dass HBCI mit PIN/TAN auf HTTPS aufsetzt, und Java die Prüfung der Zertifikate übernimmt. Das ist evtl. nicht jedem klar.
> Gruss
> Olaf
Rolf
|
|
From: Rolf V. <ro...@we...> - 2010-01-15 01:18:59
|
> Hi, > > On Mon, 2010-01-11 at 17:43 +0100, Marcus Wolschon wrote: > > I was using 1.6.0.07 . > > The certificate is the one Comdirect uses. I have no > > idea how to obtain that as I have no client nor code that > > can open an SSL-dialog for FinTS/HBCI and save the certificate > > to a PEM or DER -file. > > Try to open the HBCI-PIN/TAN URL in the browser. This will give > you an error (because you did not send a valid HBCI message), but > nevertheless you can examine the certificate details, and especially > examine the certificate CHAIN. > > For each certificate in the chain, check if it is contained in the > Java-cacert-file. If not, go to the website of the corresponding CA > - there you can download the certificates... There's an easier way in case anyone wants to know: The key is a great Firefox plugin that can be used to inspect the certificates that are used, as well as dump them to the hard disk. The Java keytool application is then able to import the files written by the plugin. Name: Cert Viewer Plus URL: https://addons.mozilla.org/en-US/firefox/addon/1964 Current Version: 1.5 Normally, the certificate of the bankserver itself is not needed, but everything above it. In this specific case: PIN/TAN-URL: https://hbci.comdirect.de/pintan/HbciPinTanHttpGate Certificate chain according to Firefox: 1.: "Builtin Object Token: Equifax Secure CA" (since 22.08.1998 18:41:51) 2.: "TC TrustCenter SSL CA I" (since 15.08.2008 18:45:15) 3.: "hbci.comdirect.de" (since 30.09.2009 12:45:25) I think that it is sufficient to add certificates #1 and #2 to the keystore if they are not yet present, it should not be necessary to add #3. > > b) that is not "inside the program" but would > > require an advanced user that can be trusted to > > perform such operations on the command-line > > without help. > > ... > > How do you combine "not an option" and "the only way"? > > Both are mutually exclusive answers. > > I thought about the following solution: YOU (as the developer of your > special application) fetch the missing certificate(s) and create > a cacert-style file from them using Java's keytool. > > This cacert-style file you could include in your application. > You could set the certfile-kernel-parameter by default to point > to the file provided by you. > > So no user of your application must do anything complicated. Yes, but I would suggest to start with the file that is shipping with the latest Java SDK (which will contain most of the entries that are needed in practice). It is easy to to the following: -> Take this file (The filename should be similar to "C:\Program Files\Java\jdk1.6.0_12\jre\lib\security\cacerts"). Copy it into the directory hierarchy of your project. -> Dump the two certificates to the local hard disk with the mentioned plugin. -> Add the two certificates to the cacerts file of your project. -> Ship this "pimped" cacerts file along with your application, and configure the app to use your file automatically, ignoring the Java included file (that would normally be used). -> Should work, even on Linux or MacOSX boxes, since the format of the cacerts file should be the same on every platform. > Regarding "not an option" and "the only way": I've meant, in general > it is of course not a real solution to include all bank-certificates > in your own application (you have written: "I donŽt think itŽs an option > to ship and update the certificates of every bank the user could > configure with the software." - this is exactly what I mean). > > But the only way IN THIS SPECIAL CASE (i.e. where ONE bank has a new > certificate whose root certificate is not yet in the cacert-file of an > older Java version) is to provide a cacert-style file for yourself. > > > 1.6.0.07 I know their HTTP-certificare is a EV.cert from VeriSign > > but I have no idea about their FinTS -certificate > > This is probably the same certificate, because in most cases the > SSL decryption layer is far before the decision which backend- > application has to handle the incoming request. No, I think this is incorrect. In most cases, the PIN/TAN-URL contains a different hostname than the one that is used for the browser-based online-banking. In most cases, there are three different hosts (subdomains) for a single bank: 1.: One host (for example www.somebank.de) for the normal page with some content management system (or whatever) on it. 2.: One host (for example hbci.somebank.de) for the PIN/TAN-based HBCI banking. 3.: One host (for example banking.somebank.de) for the browser-based online banking. Hosts #2 and #3 only communicate via HTTPS (PIN/TAN-based HBCI is layered on top of HTTPS), and #1 is typically not security critical (so simple HTTP is sufficient). Host #3 (browser-based banking) typically supports extended validation (green bar), which is FAR more expensive than a normal certificate, but completely useless for HBCI, since the certificate is never shown to the user, so he won't know the difference. So host #2 (HBCI) typically supports only classic validation (blue bar). In this case: 1.: http://www.comdirect.de/ (no validation / clear bar) 2.: https://hbci.comdirect.de/pintan/HbciPinTanHttpGate (blue bar) 3.: https://kunde.comdirect.de/lp/wt/login (green bar) If your software only needs host #2, the certificate chain for this host is the only thing that is ever relevant to you. > As already said above: try to open the HBCI-PIN/TAN-URL in your > browser and examine the SSL certificate... > > Regards > -stefan- |
|
From: Rolf V. <ro...@we...> - 2010-01-15 01:07:00
|
*** In case you get this mail duplicated: According to my mail provider, it was sent to the list but never got back, so I'm trying to resend it one more time. *** > Hi, > > On Mon, 2010-01-11 at 17:43 +0100, Marcus Wolschon wrote: > > I was using 1.6.0.07 . > > The certificate is the one Comdirect uses. I have no > > idea how to obtain that as I have no client nor code that > > can open an SSL-dialog for FinTS/HBCI and save the certificate > > to a PEM or DER -file. > > Try to open the HBCI-PIN/TAN URL in the browser. This will give > you an error (because you did not send a valid HBCI message), but > nevertheless you can examine the certificate details, and especially > examine the certificate CHAIN. > > For each certificate in the chain, check if it is contained in the > Java-cacert-file. If not, go to the website of the corresponding CA > - there you can download the certificates... There's an easier way in case anyone wants to know: The key is a great Firefox plugin that can be used to inspect the certificates that are used, as well as dump them to the hard disk. The Java keytool application is then able to import the files written by the plugin. Name: Cert Viewer Plus URL: https://addons.mozilla.org/en-US/firefox/addon/1964 Current Version: 1.5 Normally, the certificate of the bankserver itself is not needed, but everything above it. In this specific case: PIN/TAN-URL: https://hbci.comdirect.de/pintan/HbciPinTanHttpGate Certificate chain according to Firefox: 1.: "Builtin Object Token: Equifax Secure CA" (since 22.08.1998 18:41:51) 2.: "TC TrustCenter SSL CA I" (since 15.08.2008 18:45:15) 3.: "hbci.comdirect.de" (since 30.09.2009 12:45:25) I think that it is sufficient to add certificates #1 and #2 to the keystore if they are not yet present, it should not be necessary to add #3. > > b) that is not "inside the program" but would > > require an advanced user that can be trusted to > > perform such operations on the command-line > > without help. > > ... > > How do you combine "not an option" and "the only way"? > > Both are mutually exclusive answers. > > I thought about the following solution: YOU (as the developer of your > special application) fetch the missing certificate(s) and create > a cacert-style file from them using Java's keytool. > > This cacert-style file you could include in your application. > You could set the certfile-kernel-parameter by default to point > to the file provided by you. > > So no user of your application must do anything complicated. Yes, but I would suggest to start with the file that is shipping with the latest Java SDK (which will contain most of the entries that are needed in practice). It is easy to to the following: -> Take this file (The filename should be similar to "C:\Program Files\Java\jdk1.6.0_12\jre\lib\security\cacerts"). Copy it into the directory hierarchy of your project. -> Dump the two certificates to the local hard disk with the mentioned plugin. -> Add the two certificates to the cacerts file of your project. -> Ship this "pimped" cacerts file along with your application, and configure the app to use your file automatically, ignoring the Java included file (that would normally be used). -> Should work, even on Linux or MacOSX boxes, since the format of the cacerts file should be the same on every platform. > > 1.6.0.07 I know their HTTP-certificare is a EV.cert from VeriSign > > but I have no idea about their FinTS -certificate > > This is probably the same certificate, because in most cases the > SSL decryption layer is far before the decision which backend- > application has to handle the incoming request. No, I think this is incorrect. In most cases, the PIN/TAN-URL contains a different hostname than the one that is used for the browser-based online-banking. In most cases, there are three different hosts (subdomains) for a single bank: 1.: One host (for example www.somebank.de) for the normal page with some content management system (or whatever) on it. 2.: One host (for example hbci.somebank.de) for the PIN/TAN-based HBCI banking. 3.: One host (for example banking.somebank.de) for the browser-based online banking. Hosts #2 and #3 only communicate via HTTPS (PIN/TAN-based HBCI is layered on top of HTTPS), and #1 is typically not security critical (so simple HTTP is sufficient). Host #3 (browser-based banking) typically supports extended validation (green bar), which is FAR more expensive than a normal certificate, but completely useless for HBCI, since the certificate is never shown to the user, so he won't know the difference. So host #2 (HBCI) typically supports only classic validation (blue bar). In this case: 1.: http://www.comdirect.de/ (no validation / clear bar) 2.: https://hbci.comdirect.de/pintan/HbciPinTanHttpGate (blue bar) 3.: https://kunde.comdirect.de/lp/wt/login (green bar) If your software only needs host #2, the certificate chain for this host is the only thing that is ever relevant to you. > As already said above: try to open the HBCI-PIN/TAN-URL in your > browser and examine the SSL certificate... > > Regards > -stefan- Rolf |
|
From: Rolf V. <ro...@we...> - 2010-01-15 00:54:26
|
> > I'm not sure how long the option client.passport.PinTan.checkcert has > > been available and documented, it could very well have been that this > > option didn't exist in an older version of the library > > Just FYI: This was one of the very first options that have been > implemented, because the test server which I have used in the "old days" > did not have an "official" SSL certificate, so I had to disable > certification checking to be able to work in HBCI-PIN/TAN at all :-) Ah, I see :) > With HBCI4Java's kernel parameter client.passport.PinTan.certfile > you can specify the name of such a file, which will then be used > by Java's SSL engine in addition the the standard cacert file. Oops, I didn't know that the provided keystore is used as an addition to the regular one, I thought it would be used as a replacement. SORRY about that. But still, what I have written in my previous mail should work nicely, and should be safe and understandable. Also, if you use the Java keystore of a recent JDK version, you don't have to add much, and if you ship the result along with the app, it should work even if the user has installed a very much older Java version. So the results should be identical on his/her and your computer. Which is what you want :) > > I donŽt think itŽs an option to ship and update the certificates of > > every bank the user could configure with the software. > > Of course, you are right. But if you work with an "older" Java version, > which does not yet include the (maybe very new) root certificate in > question, this may be the only way. > > The alternative would be to tell your users that they need a relatively > new Java version (which includes the root cert in question). > > By the way, this is the reason for my first question in this mail: if > you already use a very new Java version, and this certificate is not > included, this may cause bigger problems - not only for HBCI4Java, but > all Java applications working with certificates... I think that possibly the intermediate certificate in the chain is the culprit: Certificate chain according to Firefox: 1.: "Builtin Object Token: Equifax Secure CA" (since 22.08.1998 18:41:51) 2.: "TC TrustCenter SSL CA I" (since 15.08.2008 18:45:15) 3.: "hbci.comdirect.de" (since 30.09.2009 12:45:25) Java 1.6.0.07 seems to be older than 15.08.2008 (for example, I found a message in a board, dated "Jul 13, 2008 5:21 AM" where someone wants to download this exact Java version). So certificate #2 can't possibly be included. > Regards > -stefan- Rolf |
|
From: Rolf V. <ro...@we...> - 2010-01-15 00:36:47
|
> > If I understand it correctly, you could use the parameter > > client.passport.PinTan.certfile to specify a file that you ship > > along with your code that will be used by HBCI4Java. This file > > could contain any (root or immediate) certificate that will be > > needed to communicate with the host. > Do you know any way of doing this at configuration-time inside the > program? > Preferably one that works with any version of the hbci-protocol. (I > donŽt know > much about how hbci and FinTS work on the network-layer.) Well, it should look similar to: - HBCI - HTTPS - SSL layer (that's the one we are configuring here) - HTTPS - HTTP layer - TCP - IP - ... something irrelevant to this discussion ... You could try the client.passport.PinTan.certfile option that seems to be specifed in the hbci.properties file. A sample could be found here: http://hbci4java.kapott.org/svn/hbci4java/trunk/src/hbci.properties.template Just search for "client.passport.PinTan" ... > I donŽt think itŽs an option to ship and update the certificates of > every bank > the user could configure with the software. This is not needed, only the certificates above the bank certificate should ever be needed (se my other mail for details). Java contains most certificates needed for everyday usage. > > Also, the password for the default Java keystore seems to be > > documented, it's either "changeit" or "changeme" (the latter only > > on MacOSX). > Yes, cou can find out about it but not easy enough to let an untrained > everyday-user do it. I think, if you use a standard Java JDK keystore and "pimp" it as described in my other mail, but without changing the password, the user does not have to enter anything at all. > > You could also check out the great open source (GNU GPL v2) > > software Portecle (http://portecle.sourceforge.net/) that can be > > used to inspect and modify Java keystores. > Never seen that one yet. Thanks for mentioning it. > > Marcus |
|
From: Olaf W. <hbc...@wi...> - 2010-01-11 22:32:07
|
Hi,
wofuer eigentlich dieses zwanghaft englische Geschreibe?
Niemand ausserhalb von Deutschland verwendet HBCI.
> Strange, I can´t find any blame at all.
> A simple "no" to my question if you knew
> a way or code to do this was all that was required.
> So I´ll just look for myself next time I have some
> spare cycles to use on this program.
Schreib einen eigenen TrustManager.
SSLContext ctx = SSLContext.getInstance(...);
KeyManagerFactory km = KeyManagerFactory.getInstance(...);
km.init(keystore,"...".toCharArray());
TrustManager tm = new MyTrustManager();
ctx.init(km.getKeyManagers(),new TrustManager[]{tm},null);
> >> You are proposing to sit here for weeks to find all hbci-servers
> >> of all banks on this planet and then to constantly monitor them.
> >
> > I do not. But you seem to think I have to time to do this, just to
> > make *you* happy. You are wrong.
>
> Why? Did I propose you to do this job or just show
> how rediculus a solution your proposal was?
Aus deinem Posting war ueberhaupt ersichtlich, was genau deine Software
macht, wer sie wie nutzt, wer wo was konfiguriert oder administriert.
Woher soll Stefan dann die fuer dein Szenario passende Loesung wissen?
> I don´t think any user has more then a dozen or so bank-accounts
> at any one time. I´ll sign it up to be added in the next version.
> It certainly beats keytool.
Nochmal. Ich kann deinen Postings nicht entnehmen, wer deine
User sind. Woher soll dann jemand wissen, ob die mehr als
ein Konto haben koennen?
> > But this is not a *HBCI4Java related* problem, so I can only give
> > you the advice to learn how to deal with SSL certificates in Java,
> > and do not blame others for the fact that you don't know.
>
> Did I say it is?
Warum hast du die Frage dann in der HBCI4Java-Mailingliste
gestellt und nicht z.Bsp. in de.comp.lang.java?
Gruss
Olaf
|
|
From: Marcus W. <Ma...@Wo...> - 2010-01-11 18:36:38
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 HBCI4Java (Stefan Palme) schrieb: > But why do you blame ME for not being able to do this? To quote > you: > >> Do you realize that I have a) no Idea what banks my users want to >> use Strange, I can´t find any blame at all. A simple "no" to my question if you knew a way or code to do this was all that was required. So I´ll just look for myself next time I have some spare cycles to use on this program. >> You are proposing to sit here for weeks to find all hbci-servers >> of all banks on this planet and then to constantly monitor them. > > I do not. But you seem to think I have to time to do this, just to > make *you* happy. You are wrong. Why? Did I propose you to do this job or just show how rediculus a solution your proposal was? > So why not ask out there, how other authors solve this problem? Because I first asked you before I ask and search around elsewhere. > >> Wouldn´t it be far easier to just connect to the server at the >> time the user configures my program, fetch the certificate and >> let the user decide if he wants to trust it? THAT is what I asked >> if you knew how to do that or knew (Java-)code that did that so I >> could integrate this feature. At runtime my program runs without >> user-interaction so I have to ask at configure-time. > > This may be a solution, if your programm will be run only against a > handful of banks, and your users must reconfigure / recompile your > application when the certificate changes. But yes, why not, this > may be a solution for your problem. I don´t think any user has more then a dozen or so bank-accounts at any one time. I´ll sign it up to be added in the next version. It certainly beats keytool. > But this is not a *HBCI4Java related* problem, so I can only give > you the advice to learn how to deal with SSL certificates in Java, > and do not blame others for the fact that you don't know. Did I say it is? Marcus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktLb5gACgkQf1hPnk3Z0cT+DQCg2EMxYBMpvwrA+Mbz9PoB0N5a iEgAnRKeuIC4LY46ADCxhBRQer0klrXG =YChD -----END PGP SIGNATURE----- |
|
From: HBCI4Java (S. Palme) <hbc...@ka...> - 2010-01-11 18:01:13
|
Marcus, you obviously did not get the relevant point. I'm working on HBCI4Java since about the year 2000 or 2001, and until now it NEVER HAPPENED that a bank's SSL server switched to a new certificate which could not be validated by Java's builtin root certificates (at least not when using reasonable up-to-date Java versions). So your case is a special and for sure a temporary one! Automatic SSL certificate validation is a *Java* feature, and I am not the author of Java, but of HBCI4Java, which just USES Java's SSL capabilities. If you are not happy with Java's standard behaviour (i.e. providing a cacert file with the most common root certificates and so being able to automatically verify a lot of certificates), you have to find another way on your own. Of course you CAN completely ignore the provided cacert file and use a self-written certificate-store, which can be updated either at runtime or at compile time or whenever you want. But why do you blame ME for not being able to do this? To quote you: > Do you realize that I have > a) no Idea what banks my users want to use Same applies to me - I have no idea what kind of "certificate validation" users of HBCI4Java want. I just provide the default behaviour included in the JRE. See Javas documentation for more info about how to modify it. > b) no way of knowing when they change certificates Again: why do you blame ME? Do you think *I* know when they change their certificates and have the time to provide always up-to-date keystores with all the required root certificates? > c) a job and a number of other, more imporant software-projects > to care about? Again: why do you blame ME? I'm not responsible for your spare time and what you do with it - and I will not solve your general Java problems. Sorry for the fact that I have released a version of a software project, which is not perfect and does not fulfill everyone's requirements. The next time I will take more care to solve ALL worlds problems in my software projects, including: 1) calculation of PI up to the 1.000st digit, 2) making more peace on earth, and, last but not least, 3) user-managed certificate-stores > You are proposing to sit here for weeks to find all hbci-servers > of all banks on this planet and then to constantly monitor them. I do not. But you seem to think I have to time to do this, just to make *you* happy. You are wrong. > If not, I would risk that my software just does not work > for any random bank with the user blaming me, not his bank > or his own abilities. The same applies to ALL Java software, which uses SSL certificates (in most cases: HTTPS-connections) and which does not include a user- managed certificate store, but relies on the builtin cacert file. So why not ask out there, how other authors solve this problem? > Wouldn´t it be far easier to just connect to the server > at the time the user configures my program, fetch the > certificate and let the user decide if he wants to trust it? > THAT is what I asked if you knew how to do that or knew > (Java-)code that did that so I could integrate this feature. > At runtime my program runs without user-interaction > so I have to ask at configure-time. This may be a solution, if your programm will be run only against a handful of banks, and your users must reconfigure / recompile your application when the certificate changes. But yes, why not, this may be a solution for your problem. But this is not a *HBCI4Java related* problem, so I can only give you the advice to learn how to deal with SSL certificates in Java, and do not blame others for the fact that you don't know. -stefan- > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > HBCI4Java (Stefan Palme) schrieb: > > I thought about the following solution: YOU (as the developer of > > your special application) fetch the missing certificate(s) and > > create a cacert-style file from them using Java's keytool. > > Do you realize that I have > a) no Idea what banks my users want to use > b) no way of knowing when they change certificates > c) a job and a number of other, more imporant software-projects > to care about? > > You are proposing to sit here for weeks to find all hbci-servers > of all banks on this planet and then to constantly monitor them. > > If not, I would risk that my software just does not work > for any random bank with the user blaming me, not his bank > or his own abilities. > > So no user of your application must do anything complicated. > Wouldn´t it be far easier to just connect to the server > at the time the user configures my program, fetch the > certificate and let the user decide if he wants to trust it? > THAT is what I asked if you knew how to do that or knew > (Java-)code that did that so I could integrate this feature. > > At runtime my program runs without user-interaction > so I have to ask at configure-time. > > > Marcus > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAktLXrYACgkQf1hPnk3Z0cTDfwCglxOUlk16oF1veub4+FMm5+tn > WDoAoNP+wyQrJj3P79PCNCd7n2yssBYL > =I1bq > -----END PGP SIGNATURE----- > |
|
From: Marcus W. <Ma...@Wo...> - 2010-01-11 17:24:20
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
HBCI4Java (Stefan Palme) schrieb:
> I thought about the following solution: YOU (as the developer of
> your special application) fetch the missing certificate(s) and
> create a cacert-style file from them using Java's keytool.
Do you realize that I have
a) no Idea what banks my users want to use
b) no way of knowing when they change certificates
c) a job and a number of other, more imporant software-projects
to care about?
You are proposing to sit here for weeks to find all hbci-servers
of all banks on this planet and then to constantly monitor them.
If not, I would risk that my software just does not work
for any random bank with the user blaming me, not his bank
or his own abilities.
> So no user of your application must do anything complicated.
Wouldn´t it be far easier to just connect to the server
at the time the user configures my program, fetch the
certificate and let the user decide if he wants to trust it?
THAT is what I asked if you knew how to do that or knew
(Java-)code that did that so I could integrate this feature.
At runtime my program runs without user-interaction
so I have to ask at configure-time.
Marcus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAktLXrYACgkQf1hPnk3Z0cTDfwCglxOUlk16oF1veub4+FMm5+tn
WDoAoNP+wyQrJj3P79PCNCd7n2yssBYL
=I1bq
-----END PGP SIGNATURE-----
|
|
From: HBCI4Java (S. Palme) <hbc...@ka...> - 2010-01-11 17:13:35
|
Hi, On Mon, 2010-01-11 at 17:43 +0100, Marcus Wolschon wrote: > I was using 1.6.0.07 . > The certificate is the one Comdirect uses. I have no > idea how to obtain that as I have no client nor code that > can open an SSL-dialog for FinTS/HBCI and save the certificate > to a PEM or DER -file. Try to open the HBCI-PIN/TAN URL in the browser. This will give you an error (because you did not send a valid HBCI message), but nevertheless you can examine the certificate details, and especially examine the certificate CHAIN. For each certificate in the chain, check if it is contained in the Java-cacert-file. If not, go to the website of the corresponding CA - there you can download the certificates... > I know that it is possible to add a certificate with keytool but > a) that does not cover the important part of > optaining the certificate in the first place See above. > b) that is not "inside the program" but would > require an advanced user that can be trusted to > perform such operations on the command-line > without help. > ... > How do you combine "not an option" and "the only way"? > Both are mutually exclusive answers. I thought about the following solution: YOU (as the developer of your special application) fetch the missing certificate(s) and create a cacert-style file from them using Java's keytool. This cacert-style file you could include in your application. You could set the certfile-kernel-parameter by default to point to the file provided by you. So no user of your application must do anything complicated. Regarding "not an option" and "the only way": I've meant, in general it is of course not a real solution to include all bank-certificates in your own application (you have written: "I don´t think it´s an option to ship and update the certificates of every bank the user could configure with the software." - this is exactly what I mean). But the only way IN THIS SPECIAL CASE (i.e. where ONE bank has a new certificate whose root certificate is not yet in the cacert-file of an older Java version) is to provide a cacert-style file for yourself. > 1.6.0.07 I know their HTTP-certificare is a EV.cert from VeriSign > but I have no idea about their FinTS -certificate This is probably the same certificate, because in most cases the SSL decryption layer is far before the decision which backend- application has to handle the incoming request. As already said above: try to open the HBCI-PIN/TAN-URL in your browser and examine the SSL certificate... Regards -stefan- |
|
From: Marcus W. <Ma...@Wo...> - 2010-01-11 16:43:59
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 HBCI4Java (Stefan Palme) schrieb: > Hi > > Although you have solved the issue already, here some comments from me: > > On Sun, 2010-01-10 at 20:50 +0100, Marcus Wolschon wrote: >> The bank switched CAs and the CA they chose this time is not in >> the default Java-Truststore sun provides. > > Can you tell me, which java version you are using and which CA > certificate is missing in the standard cacert truststore? This > may be an important information for other users, too. I was using 1.6.0.07 . The certificate is the one Comdirect uses. I have no idea how to obtain that as I have no client nor code that can open an SSL-dialog for FinTS/HBCI and save the certificate to a PEM or DER -file. > On Mon, 2010-01-11 at 06:11 +0100, Marcus Wolschon wrote: >>> If I understand it correctly, you could use the parameter >>> client.passport.PinTan.certfile to specify a file that you ship >>> along with your code that will be used by HBCI4Java. This file >>> could contain any (root or immediate) certificate that will be >>> needed to communicate with the host. >> Do you know any way of doing this at configuration-time inside the >> program? Preferably one that works with any version of the hbci-protocol. >> (I don´t know much about how hbci and FinTS work on the network-layer.) > > This stuff is totally independent of HBCI4Java - it's a feature of > the Java runtime environment itself (see the Java docs). You can > import SSL certificates into an own truststore file (one similar to > the provided cacert file) using "keytool". I know that it is possible to add a certificate with keytool but a) that does not cover the important part of optaining the certificate in the first place b) that is not "inside the program" but would require an advanced user that can be trusted to perform such operations on the command-line without help. > > With HBCI4Java's kernel parameter client.passport.PinTan.certfile > you can specify the name of such a file, which will then be used > by Java's SSL engine in addition the the standard cacert file. I know that. >> I don´t think it´s an option to ship and update the certificates of >> every bank the user could configure with the software. > > Of course, you are right. But if you work with an "older" Java version, > which does not yet include the (maybe very new) root certificate in > question, this may be the only way. How do you combine "not an option" and "the only way"? Both are mutually exclusive answers. > > By the way, this is the reason for my first question in this mail: if > you already use a very new Java version, and this certificate is not > included, this may cause bigger problems - not only for HBCI4Java, but > all Java applications working with certificates... 1.6.0.07 I know their HTTP-certificare is a EV.cert from VeriSign but I have no idea about their FinTS -certificate > > Regards > -stefan- > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktLVTIACgkQf1hPnk3Z0cQOYQCfWvQH+n4BSEAD61DyXZij0Cz4 TqkAnjI5SZvPuVx5P9/aXUuzZGs9vlED =4u5z -----END PGP SIGNATURE----- |
|
From: HBCI4Java (S. Palme) <hbc...@ka...> - 2010-01-11 16:21:12
|
Hi Although you have solved the issue already, here some comments from me: On Sun, 2010-01-10 at 20:50 +0100, Marcus Wolschon wrote: > The bank switched CAs and the CA they chose this time is not in > the default Java-Truststore sun provides. Can you tell me, which java version you are using and which CA certificate is missing in the standard cacert truststore? This may be an important information for other users, too. On Mon, 2010-01-11 at 02:04 +0100, Rolf Viehmann wrote: > http://hbci4java.kapott.org/javadoc/org/kapott/hbci/manager/HBCIUtils.html > > is already provided and documented for exactly that purpose? > > I'm not sure how long the option client.passport.PinTan.checkcert has > been available and documented, it could very well have been that this > option didn't exist in an older version of the library Just FYI: This was one of the very first options that have been implemented, because the test server which I have used in the "old days" did not have an "official" SSL certificate, so I had to disable certification checking to be able to work in HBCI-PIN/TAN at all :-) On Mon, 2010-01-11 at 06:11 +0100, Marcus Wolschon wrote: > > If I understand it correctly, you could use the parameter > > client.passport.PinTan.certfile to specify a file that you ship > > along with your code that will be used by HBCI4Java. This file > > could contain any (root or immediate) certificate that will be > > needed to communicate with the host. > > Do you know any way of doing this at configuration-time inside the > program? Preferably one that works with any version of the hbci-protocol. > (I don´t know much about how hbci and FinTS work on the network-layer.) This stuff is totally independent of HBCI4Java - it's a feature of the Java runtime environment itself (see the Java docs). You can import SSL certificates into an own truststore file (one similar to the provided cacert file) using "keytool". With HBCI4Java's kernel parameter client.passport.PinTan.certfile you can specify the name of such a file, which will then be used by Java's SSL engine in addition the the standard cacert file. > I don´t think it´s an option to ship and update the certificates of > every bank the user could configure with the software. Of course, you are right. But if you work with an "older" Java version, which does not yet include the (maybe very new) root certificate in question, this may be the only way. The alternative would be to tell your users that they need a relatively new Java version (which includes the root cert in question). By the way, this is the reason for my first question in this mail: if you already use a very new Java version, and this certificate is not included, this may cause bigger problems - not only for HBCI4Java, but all Java applications working with certificates... Regards -stefan- -- --------------------------------------------------------------------- Stefan Palme Email: pa...@ka... WWW: http://hbci4java.kapott.org GnuPG-Fingerprint: 1BA7 D217 36A1 534C A5AD F18A E2D1 488A E904 F9EC --------------------------------------------------------------------- |
|
From: Marcus W. <Ma...@Wo...> - 2010-01-11 05:11:44
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rolf Viehmann schrieb: > >> ThatŽs exactly what I wanted to avoid for my users are it is a >> PITA to add a trust-ancor to the default Java keystore. (First >> issue: itŽs password protected and they donŽt document the >> password.) > > > If I understand it correctly, you could use the parameter > client.passport.PinTan.certfile to specify a file that you ship > along with your code that will be used by HBCI4Java. This file > could contain any (root or immediate) certificate that will be > needed to communicate with the host. Do you know any way of doing this at configuration-time inside the program? Preferably one that works with any version of the hbci-protocol. (I don´t know much about how hbci and FinTS work on the network-layer.) I don´t think it´s an option to ship and update the certificates of every bank the user could configure with the software. > > Also, the password for the default Java keystore seems to be > documented, it's either "changeit" or "changeme" (the latter only > on MacOSX). Yes, cou can find out about it but not easy enough to let an untrained everyday-user do it. > > You could also check out the great open source (GNU GPL v2) > software Portecle (http://portecle.sourceforge.net/) that can be > used to inspect and modify Java keystores. Never seen that one yet. Thanks for mentioning it. Marcus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktKsv0ACgkQf1hPnk3Z0cT5UgCfVwkg5uiv1a37qp/t3/bJgTnq SXwAnjifUta8N7WD2o5PBq4d0lakxVYi =KtRW -----END PGP SIGNATURE----- |
|
From: Rolf V. <ro...@we...> - 2010-01-11 01:11:07
|
> Ok, > Issue solved. > > I had the validateCert=0 setting in there but it was not in effect. > The bank switched CAs and the CA they chose this time is not in > the default Java-Truststore sun provides. > I changes the settings so validateCert is not actually in effect > and it works. Well, that's great to hear, but still, it would be more safe and clean if you would provide the users with a keystore that contains all the necessary certificates, so if any user is tricked into connecting to a forged host (DNS poisoning or something similar), the application will cancel the connection. Simply accepting all possible hosts is not very safe and should only be a last resort IMHO. You could start with the default Java keystore of the most recent Java SDK, and add everything that is needed for a connection to this bank, then ship the resulting keystore along with your code. If the code automatically uses your keystore, the user shouldn't have to do anything special. So it won't be a problem for the users, but more safe for them. > Marcus |
|
From: Rolf V. <ro...@we...> - 2010-01-11 01:04:23
|
> >> Any idea what could have happened? IŽm sure the old certificate > >> wasnŽt in the list of trust-ancors too and that it was > >> implemented to simply accept all certificates. The code of the > >> application has not changed in half a year. > > If your application hasn't changed, maybe the server was upgraded > > or something alike. Maybe it got an "Extended Validation" > > certificate instead of a plain one. > Of cause they did get a new certificate. Why else would it fail. They could have changed any of the settings that their webserver provides to them, or switched the software that is used on the webserver etc. Or they could have changed any other part of their infrastructure (Web Application Firewall or something similar). > Extended validation has nothing to do with it. In fact, it is useless > for HBCI as the certificate is never presented to the user at all. Yes, it is useless, but still, they could have a policy in-house that prescribes that any new or renewed certificate should be an extended validation one. Keep in mind that you didn't provide us (this list) with any information about the hostname, location or owner of the server, so it's not possible to rule this things out. > > It seems as if the application is doing a real check whether the > > server's certificate is valid. So you could provide this list with > > the following information: > > > > -> How you tried to implement the "simply accept all certificates" > > part of the application. Maybe this class (classes) is not really > > loaded and used, or it contains some sort of mistake. > This is the mailing-list of HBCI4Java. > Why would I use my own imlementation when > "|client.passport.PinTan.checkcert" > > http://hbci4java.kapott.org/javadoc/org/kapott/hbci/manager/HBCIUtils.html > is already provided and documented for exactly that purpose? I'm not sure how long the option client.passport.PinTan.checkcert has been available and documented, it could very well have been that this option didn't exist in an older version of the library, so software that uses HBCI4Java could easily contain own code that does essentially the same thing. So whenever asking questions, you could mention how you did something (feature of the library, own code, etc.), because if you don't, nobody can know how you built it. > I reviews my code and found a possibility that the abovementioned > setting was not in effect at that time. > IŽll try again soon. > > -> Which host you tried to connect to. If the host has an official > > certificate (that would be accepted by all major browsers), it > > should not normally be necessary to accept all certificates. > I very much doubt that my bank uses anything BUT an official > certificate from one of the > major commercial CAs. > > In this case, you probably only want to add the root certificate of > > the certificate authority, > ThatŽs exactly what I wanted to avoid for my users are it is a PITA to > add a trust-ancor > to the default Java keystore. (First issue: itŽs password protected > and they donŽt document > the password.) If I understand it correctly, you could use the parameter client.passport.PinTan.certfile to specify a file that you ship along with your code that will be used by HBCI4Java. This file could contain any (root or immediate) certificate that will be needed to communicate with the host. Also, the password for the default Java keystore seems to be documented, it's either "changeit" or "changeme" (the latter only on MacOSX). You could also check out the great open source (GNU GPL v2) software Portecle (http://portecle.sourceforge.net/) that can be used to inspect and modify Java keystores. > > as well as the immediate certificates that are used in the chain. > You do know that the server has to send the itermediate certificates along > and usually does so? Yes, that's what it should do, and it's the only thing that makes sense. But as far as I know, there are a few SSL hosts that don't send the correct chain, which can cause mayor headaches. I'm not sure whether there are any hosts for HBCI that have this problem, but I'm quite sure there are some HTTPS hosts that have this misconfiguration. > > Accepting all certificates (including invalid ones) should only be > > the last thing you do if everything else fails or if the server is > > completely under your control and you don't want to spend any money > > on a real certificate (for example, a dev server on a local > > network). > We are talking about a very large international bank here. > Why do you think I would have any control over the server? Well, you didn't tell us anything about the server involved, so I simply didn't know. Sorry. |
|
From: Marcus W. <Ma...@Wo...> - 2010-01-10 19:50:26
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ok, Issue solved. I had the validateCert=0 setting in there but it was not in effect. The bank switched CAs and the CA they chose this time is not in the default Java-Truststore sun provides. I changes the settings so validateCert is not actually in effect and it works. Marcus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktKL3IACgkQf1hPnk3Z0cT9ZgCgkCYbh9cKd9Qf1cz2Rk09I3/d ROkAnAhkfOONuqpu9pinn/Ejn7JWa+L3 =Does -----END PGP SIGNATURE----- |
|
From: Marcus W. <Ma...@Wo...> - 2010-01-10 19:38:48
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rolf Viehmann schrieb: >> Any idea what could have happened? IŽm sure the old certificate >> wasnŽt in the list of trust-ancors too and that it was >> implemented to simply accept all certificates. The code of the >> application has not changed in half a year. > > If your application hasn't changed, maybe the server was upgraded > or something alike. Maybe it got an "Extended Validation" > certificate instead of a plain one. Of cause they did get a new certificate. Why else would it fail. Extended validation has nothing to do with it. In fact, it is useless for HBCI as the certificate is never presented to the user at all. > > It seems as if the application is doing a real check whether the > server's certificate is valid. So you could provide this list with > the following information: > > -> How you tried to implement the "simply accept all certificates" > part of the application. Maybe this class (classes) is not really > loaded and used, or it contains some sort of mistake. This is the mailing-list of HBCI4Java. Why would I use my own imlementation when "|client.passport.PinTan.checkcert" http://hbci4java.kapott.org/javadoc/org/kapott/hbci/manager/HBCIUtils.html is already provided and documented for exactly that purpose? I reviews my code and found a possibility that the abovementioned setting was not in effect at that time. I´ll try again soon. | > > -> Which host you tried to connect to. If the host has an official > certificate (that would be accepted by all major browsers), it > should not normally be necessary to accept all certificates. I very much doubt that my bank uses anything BUT an official certificate from one of the major commercial CAs. > In this case, you probably only want to add the root certificate of > the certificate authority, That´s exactly what I wanted to avoid for my users are it is a PITA to add a trust-ancor to the default Java keystore. (First issue: it´s password protected and they don´t document the password.) > as well as the immediate certificates that are used in the chain. You do know that the server has to send the itermediate certificates along and usually does so? > Accepting all certificates (including invalid ones) should only be > the last thing you do if everything else fails or if the server is > completely under your control and you don't want to spend any money > on a real certificate (for example, a dev server on a local > network). We are talking about a very large international bank here. Why do you think I would have any control over the server? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktKLKYACgkQf1hPnk3Z0cSCNwCglvgOFmEYEM4AFQc4hWrpHag9 98MAnAhu2ybuVeC888K8AVjcLYMyI6PO =przn -----END PGP SIGNATURE----- |
|
From: Rolf V. <ro...@we...> - 2010-01-10 19:23:30
|
> Any idea what could have happened? > IŽm sure the old certificate wasnŽt in the list of trust-ancors too > and that it was implemented to simply accept all certificates. > The code of the application has not changed in half a year. If your application hasn't changed, maybe the server was upgraded or something alike. Maybe it got an "Extended Validation" certificate instead of a plain one. It seems as if the application is doing a real check whether the server's certificate is valid. So you could provide this list with the following information: -> How you tried to implement the "simply accept all certificates" part of the application. Maybe this class (classes) is not really loaded and used, or it contains some sort of mistake. -> Which host you tried to connect to. If the host has an official certificate (that would be accepted by all major browsers), it should not normally be necessary to accept all certificates. In this case, you probably only want to add the root certificate of the certificate authority, as well as the immediate certificates that are used in the chain. Accepting all certificates (including invalid ones) should only be the last thing you do if everything else fails or if the server is completely under your control and you don't want to spend any money on a real certificate (for example, a dev server on a local network). > Marcus > > > > 02343 [AWT-EventQueue-0] WARN > biz.wolschon.finance.jgnucash.HBCIImporter.PropertiesHBCICallback - > the job with the code HKSYN seems not to be allowed with PIN/TAN > 202594 [AWT-EventQueue-0] INFO > biz.wolschon.finance.jgnucash.HBCIImporter.PropertiesHBCICallback - > status: statusTag=23 o[]=null > 202980 [AWT-EventQueue-0] WARN > biz.wolschon.finance.jgnucash.HBCIImporter.PropertiesHBCICallback - > could not insert the following user-defined data into message: > Crypted.CryptHead.SecProfile.method=PIN > 203012 [AWT-EventQueue-0] WARN > biz.wolschon.finance.jgnucash.HBCIImporter.PropertiesHBCICallback - > could not insert the following user-defined data into message: > Crypted.CryptHead.SecProfile.version=1 > 203170 [AWT-EventQueue-0] INFO > biz.wolschon.finance.jgnucash.HBCIImporter.PropertiesHBCICallback - > callback: reason=24 msg="Bitte stellen Sie jetzt die Verbindung zum > Internet her" datatype=0 retData="" > 203171 [AWT-EventQueue-0] INFO > biz.wolschon.finance.jgnucash.HBCIImporter.PropertiesHBCICallback - > status: statusTag=24 o[]=null > 203363 [AWT-EventQueue-0] ERROR > biz.wolschon.finance.jgnucash.HBCIImporter.PropertiesHBCICallback - > org.kapott.hbci.exceptions.HBCI_Exception: Fehler beim Senden der > HBCI-Nachricht zum Server > at org.kapott.hbci.comm.CommPinTan.ping(CommPinTan.java:124) > at org.kapott.hbci.comm.Comm.pingpong(Comm.java:66) > at > org.kapott.hbci.manager.HBCIKernelImpl.rawDoIt(HBCIKernelImpl.java:358) > at > org.kapott.hbci.manager.HBCIKernelImpl.rawDoIt(HBCIKernelImpl.java:184) > at org.kapott.hbci.manager.HBCIUser.fetchSysId(HBCIUser.java:441) > at > org.kapott.hbci.manager.HBCIUser.updateUserData(HBCIUser.java:646) > at org.kapott.hbci.manager.HBCIUser.register(HBCIUser.java:667) > at > org.kapott.hbci.manager.HBCIHandler.registerUser(HBCIHandler.java:207) > at > org.kapott.hbci.manager.HBCIHandler.<init>(HBCIHandler.java:132) > at > biz.wolschon.finance.jgnucash.HBCIImporter.HBCIImporter.synchronizeAllTransactions(HBCIImporter.java:170) > at > biz.wolschon.finance.jgnucash.HBCIImporter.HBCIImporter.runImport(HBCIImporter.java:326) > at > biz.wolschon.finance.jgnucash.actions.ImportPluginMenuAction.actionPerformed(ImportPluginMenuAction.java:103) > at > javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1995) > at > javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2318) > at > javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:387) > at > javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:242) > at javax.swing.AbstractButton.doClick(AbstractButton.java:357) > at > javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:1220) > at > javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:1261) > at > java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:272) > at java.awt.Component.processMouseEvent(Component.java:6041) > at javax.swing.JComponent.processMouseEvent(JComponent.java:3265) > at java.awt.Component.processEvent(Component.java:5806) > at java.awt.Container.processEvent(Container.java:2058) > at java.awt.Component.dispatchEventImpl(Component.java:4413) > at java.awt.Container.dispatchEventImpl(Container.java:2116) > at java.awt.Component.dispatchEvent(Component.java:4243) > at > java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4322) > at > java.awt.LightweightDispatcher.processMouseEvent(Container.java:3986) > at > java.awt.LightweightDispatcher.dispatchEvent(Container.java:3916) > at java.awt.Container.dispatchEventImpl(Container.java:2102) > at java.awt.Window.dispatchEventImpl(Window.java:2440) > at java.awt.Component.dispatchEvent(Component.java:4243) > at java.awt.EventQueue.dispatchEvent(EventQueue.java:599) > at > java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:273) > at > java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183) > at > java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:173) > at > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168) > at > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:160) > at java.awt.EventDispatchThread.run(EventDispatchThread.java:121) > Caused by: javax.net.ssl.SSLHandshakeException: > sun.security.validator.ValidatorException: PKIX path validation > failed: java.security.cert.CertPathValidatorException: Path does not > chain with any of the trust anchors > at > com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:174) > at > com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1591) > at > com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:187) > at > com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:181) > at > com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:975) > at > com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:123) > at > com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:516) > at > com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:454) > at > com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:884) > at > com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1096) > at > com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1123) > at > com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1107) > at > sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:405) > at > sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:166) > at > sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:133) > at org.kapott.hbci.comm.CommPinTan.ping(CommPinTan.java:121) > ... 39 more > Caused by: sun.security.validator.ValidatorException: PKIX path > validation failed: java.security.cert.CertPathValidatorException: Path > does not chain with any of the trust anchors > at > sun.security.validator.PKIXValidator.doValidate(PKIXValidator.java:251) > at > sun.security.validator.PKIXValidator.doValidate(PKIXValidator.java:234) > at > sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:148) > at sun.security.validator.Validator.validate(Validator.java:218) > at > com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:126) > at > com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:209) > at > com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:249) > at > com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:954) > ... 50 more > Caused by: java.security.cert.CertPathValidatorException: Path does > not chain with any of the trust anchors > at > sun.security.provider.certpath.PKIXCertPathValidator.engineValidate(PKIXCertPathValidator.java:195) > at > java.security.cert.CertPathValidator.validate(CertPathValidator.java:250) > at > sun.security.validator.PKIXValidator.doValidate(PKIXValidator.java:246) > ... 57 more > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAktJ4n4ACgkQf1hPnk3Z0cRQjACfb+ybJ4FTziatPh7yS5ClXOqU > 81EAnjEF6UJxCn/ObA+HNdt92Rczyaph > =CHYg > -----END PGP SIGNATURE----- |
|
From: Marcus W. <Ma...@Wo...> - 2010-01-10 15:02:52
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Any idea what could have happened?
I´m sure the old certificate wasn´t in the list of trust-ancors too
and that it was implemented to simply accept all certificates.
The code of the application has not changed in half a year.
Marcus
02343 [AWT-EventQueue-0] WARN
biz.wolschon.finance.jgnucash.HBCIImporter.PropertiesHBCICallback -
the job with the code HKSYN seems not to be allowed with PIN/TAN
202594 [AWT-EventQueue-0] INFO
biz.wolschon.finance.jgnucash.HBCIImporter.PropertiesHBCICallback -
status: statusTag=23 o[]=null
202980 [AWT-EventQueue-0] WARN
biz.wolschon.finance.jgnucash.HBCIImporter.PropertiesHBCICallback -
could not insert the following user-defined data into message:
Crypted.CryptHead.SecProfile.method=PIN
203012 [AWT-EventQueue-0] WARN
biz.wolschon.finance.jgnucash.HBCIImporter.PropertiesHBCICallback -
could not insert the following user-defined data into message:
Crypted.CryptHead.SecProfile.version=1
203170 [AWT-EventQueue-0] INFO
biz.wolschon.finance.jgnucash.HBCIImporter.PropertiesHBCICallback -
callback: reason=24 msg="Bitte stellen Sie jetzt die Verbindung zum
Internet her" datatype=0 retData=""
203171 [AWT-EventQueue-0] INFO
biz.wolschon.finance.jgnucash.HBCIImporter.PropertiesHBCICallback -
status: statusTag=24 o[]=null
203363 [AWT-EventQueue-0] ERROR
biz.wolschon.finance.jgnucash.HBCIImporter.PropertiesHBCICallback -
org.kapott.hbci.exceptions.HBCI_Exception: Fehler beim Senden der
HBCI-Nachricht zum Server
at org.kapott.hbci.comm.CommPinTan.ping(CommPinTan.java:124)
at org.kapott.hbci.comm.Comm.pingpong(Comm.java:66)
at
org.kapott.hbci.manager.HBCIKernelImpl.rawDoIt(HBCIKernelImpl.java:358)
at
org.kapott.hbci.manager.HBCIKernelImpl.rawDoIt(HBCIKernelImpl.java:184)
at org.kapott.hbci.manager.HBCIUser.fetchSysId(HBCIUser.java:441)
at
org.kapott.hbci.manager.HBCIUser.updateUserData(HBCIUser.java:646)
at org.kapott.hbci.manager.HBCIUser.register(HBCIUser.java:667)
at
org.kapott.hbci.manager.HBCIHandler.registerUser(HBCIHandler.java:207)
at
org.kapott.hbci.manager.HBCIHandler.<init>(HBCIHandler.java:132)
at
biz.wolschon.finance.jgnucash.HBCIImporter.HBCIImporter.synchronizeAllTransactions(HBCIImporter.java:170)
at
biz.wolschon.finance.jgnucash.HBCIImporter.HBCIImporter.runImport(HBCIImporter.java:326)
at
biz.wolschon.finance.jgnucash.actions.ImportPluginMenuAction.actionPerformed(ImportPluginMenuAction.java:103)
at
javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1995)
at
javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2318)
at
javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:387)
at
javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:242)
at javax.swing.AbstractButton.doClick(AbstractButton.java:357)
at
javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:1220)
at
javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:1261)
at
java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:272)
at java.awt.Component.processMouseEvent(Component.java:6041)
at javax.swing.JComponent.processMouseEvent(JComponent.java:3265)
at java.awt.Component.processEvent(Component.java:5806)
at java.awt.Container.processEvent(Container.java:2058)
at java.awt.Component.dispatchEventImpl(Component.java:4413)
at java.awt.Container.dispatchEventImpl(Container.java:2116)
at java.awt.Component.dispatchEvent(Component.java:4243)
at
java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4322)
at
java.awt.LightweightDispatcher.processMouseEvent(Container.java:3986)
at
java.awt.LightweightDispatcher.dispatchEvent(Container.java:3916)
at java.awt.Container.dispatchEventImpl(Container.java:2102)
at java.awt.Window.dispatchEventImpl(Window.java:2440)
at java.awt.Component.dispatchEvent(Component.java:4243)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:599)
at
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:273)
at
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183)
at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:173)
at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168)
at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:160)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:121)
Caused by: javax.net.ssl.SSLHandshakeException:
sun.security.validator.ValidatorException: PKIX path validation
failed: java.security.cert.CertPathValidatorException: Path does not
chain with any of the trust anchors
at
com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:174)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1591)
at
com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:187)
at
com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:181)
at
com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:975)
at
com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:123)
at
com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:516)
at
com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:454)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:884)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1096)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1123)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1107)
at
sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:405)
at
sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:166)
at
sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:133)
at org.kapott.hbci.comm.CommPinTan.ping(CommPinTan.java:121)
... 39 more
Caused by: sun.security.validator.ValidatorException: PKIX path
validation failed: java.security.cert.CertPathValidatorException: Path
does not chain with any of the trust anchors
at
sun.security.validator.PKIXValidator.doValidate(PKIXValidator.java:251)
at
sun.security.validator.PKIXValidator.doValidate(PKIXValidator.java:234)
at
sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:148)
at sun.security.validator.Validator.validate(Validator.java:218)
at
com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:126)
at
com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:209)
at
com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:249)
at
com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:954)
... 50 more
Caused by: java.security.cert.CertPathValidatorException: Path does
not chain with any of the trust anchors
at
sun.security.provider.certpath.PKIXCertPathValidator.engineValidate(PKIXCertPathValidator.java:195)
at
java.security.cert.CertPathValidator.validate(CertPathValidator.java:250)
at
sun.security.validator.PKIXValidator.doValidate(PKIXValidator.java:246)
... 57 more
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAktJ4n4ACgkQf1hPnk3Z0cRQjACfb+ybJ4FTziatPh7yS5ClXOqU
81EAnjEF6UJxCn/ObA+HNdt92Rczyaph
=CHYg
-----END PGP SIGNATURE-----
|
|
From: HBCI4Java (S. Palme) <hbc...@ka...> - 2009-11-26 10:44:51
|
Hallo, bin gerade dabei, meine Wohnung umzuziehen. Komme vermutlich erst ab der nächsten Woche wieder dazu, mich intensiver um HBCI4Java zu kümmern... Viele Grüße -stefan- On Tue, 2009-11-24 at 11:28 +0100, no...@gm... wrote: > Hallo, > > gibts bereits Neuerungen? > Die letzten Testfiles sind vom 17.11.09. > Will nicht schieben, sondern nur vorsichtig Nachfragen. > > > Gruß, > Harry > > |
|
From: <no...@gm...> - 2009-11-24 10:28:45
|
Hallo, gibts bereits Neuerungen? Die letzten Testfiles sind vom 17.11.09. Will nicht schieben, sondern nur vorsichtig Nachfragen. Gruß, Harry -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 |
|
From: HBCI4Java (S. Palme) <hbc...@ka...> - 2009-11-13 22:48:17
|
On Fri, 2009-11-13 at 21:31 +0100, HBCI4Java (Stefan Palme) wrote: > Eine erste Version der Test-Programme für RSA-Chipkarten liegt auf > http://hbci4java.kapott.org zum Download bereit. Derzeit sind nur > Shell-Scripte für Linux enthalten - Windows-Nutzer müssen entweder > selbst Hand anlegen oder warten, bis ich auch entsprechende Batch- > Files für Windows geschrieben habe. Habe inzwischen auch Batch-Dateien für Windows beigefügt und dazu passend die README-Datei angepasst (Snapshot 20091113-02). Grüße -stefan- -- http://hbci4java.kapott.org |
|
From: HBCI4Java (S. Palme) <hbc...@ka...> - 2009-11-13 20:31:25
|
Eine erste Version der Test-Programme für RSA-Chipkarten liegt auf http://hbci4java.kapott.org zum Download bereit. Derzeit sind nur Shell-Scripte für Linux enthalten - Windows-Nutzer müssen entweder selbst Hand anlegen oder warten, bis ich auch entsprechende Batch- Files für Windows geschrieben habe. Eine kleine Anleitung steht im README, bei Fragen oder Problemen stehe ich natürlich zur Verfügung (am besten hier über die Liste, damit alle was davon haben :-) ) Grüße -stefan- On Fri, 2009-11-13 at 15:29 +0100, HBCI4Java (Stefan Palme) wrote: > Hallo, > > ich arbeite gerade noch am letzten Feinschliff für das Test-Programm, > vor allem die Windows-Version ist für mich nur sehr aufwändig zu > testen :-( > > Werde aber noch heute abend entsprechende Downloads bereitstellen. > > On Fri, 2009-11-13 at 11:30 +0100, Martin Hoefling wrote: > > Dito - Ich habe hhier eine Deutsch Bank WebSign RSA Karte mit der ich > > auch gerne testen kann. > > Ich fürchte, die WebSign-Karte der Deutschen Bank fällt in die Kategorie > "proprietär" und wird darum wohl nach wie vor nicht zu mit HBCI4Java zu > verwenden sein. Grund sind - wie schon öfters erwähnt - die mir nicht > zugänglichen Spezifikationen für diese Karte. > > Einen Versuch ist es natürlich allemal wert... > > Viele Grüße > -stefan- > > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Hbci4java-help mailing list > Hbc...@li... > https://lists.sourceforge.net/lists/listinfo/hbci4java-help -- http://hbci4java.kapott.org |
23 messages has been excluded from this view by a project administrator.
