GNOME Bugzilla – Bug 632158
TLS Handshake Error: -59 (GnuTLS internal error.)
Last modified: 2018-06-29 22:45:49 UTC
Ich nutze die Version 2.3.15, SVN r19437. In 2.2.9 hat die HBCI Verbindung funktioniert. Nach dem Upgrade bekomme ich bereits beim Abrufen der Systemkennung folgende Fehlermeldungen: 00:19:27 Executing HBCI jobs 00:19:27 AqHBCI gestartet 00:19:27 Mit Bank verbinden... 00:19:27 Ermittle Adresse von "hbci.bw-bank.de" ... 00:19:27 Ermittelte IP Adresse ist 91.198.67.28 00:19:27 Aufträge werden kodiert 00:19:30 Aufträge werden gesendet 00:19:30 Mit Bank verbinden... 00:19:31 TLS Handshake Error: -59 (GnuTLS internal error.) 00:19:31 Retrying to connect (non-SSLv3) 00:19:31 TLS Handshake Error: -59 (GnuTLS internal error.) 00:19:31 Could not connect to the bank 00:19:31 Fehler beim Senden (Netzwerk-Fehler) 00:19:31 AqHBCI abgeschlossen. 00:19:31 Abgeschlossen. Sie können dieses Fenster nun schließen. Beim Anlegen eines neuen Users verschwindet beim Abrufen des SSL Zertifikats das Dialogfenster so schnell, dass die Nachrichten nicht lesbar sind, d.h. man kommt durch Neuanlage nicht weiter. Beim Saldenaufruf kommt aehnliche Fehlermeldung: Sending jobs to the bank(s) Locking users Locking user xxxxxxx Executing HBCI jobs AqHBCI gestartet Mit Bank verbinden... Ermittle Adresse von "hbci.bw-bank.de" ... Ermittelte IP Adresse ist 91.198.67.28 Öffne Dialog mit dem Server Aufträge werden kodiert Aufträge werden gesendet Mit Bank verbinden... A TLS handshake error occurred. If you are using AqBanking you should consider enabling the option "force SSLv3" in the user settings dialog. Retrying to connect (non-SSLv3) A TLS handshake error occurred. If you are using AqBanking you should consider enabling the option "force SSLv3" in the user settings dialog. Could not connect to the bank Fehler beim Senden (Netzwerk-Fehler) AqHBCI abgeschlossen. Postprocessing jobs Resetting provider queues Vielen Dank vorab fuer die Hilfe.
Wie's in der Fehlermeldung steht: Kannst du in den HBCI-Benutzer-Einstellungen die Option "SSLv3 benutzen" aktivieren?
Habe ich aktiviert, aber es macht keinen Unterschied. Im Dialog der Benutzereinstellungen habe ich alle Kombinationen von Aktivieren/Deaktivieren der verschiedenen Checkboxes ausprobiert, immer das gleiche Verhalten.
Created attachment 172444 [details] Output of command 'gnutls-cli-debug -p 443 -V hbci.bw-bank.de' For debugging GnuTLS related problems it is essential to know all kinds of details about the related server. I've just run the command gnutls-cli-debug to get this information -- just in case we might need it later.
Just for Info, the same issue is with ING-Diba ( https://fints.ing-diba.de:443/fints/ ), so I don't think it would be bank related. Let me know if you need further information. Thanks.
Oh, and which aqbanking/gwenhywfar version? Did you use gnucash's complete windows package of gnucash-2.3.15? In that case, you have gwenhywfar-3.11.3, aqbanking-4.1.6, gnutls-2.8.1 (the latter from http://josefsson.org/gnutls4win/gnutls-2.8.1.zip )
(In reply to comment #5) I am using the complete windows package of gnucash 2.3.15 SVN r19437 from 2010-08-16, but it came with aqbanking 4.2.3. not sure about gwenhywfar (in the lib directory it created a directory with number 47, if that helps), for gnutls 2.8.1 I just followed the link to above website and installed mentioned version. Unfortunately this didn't change anything.
I double checked the logfile: mode: pintan rdhtype: 1 hbciVersion: 220 tokenType: pintan crypt: no sender: user gwenhywfar: 3.11.3.0 aqhbci: 4.2.3.0stable appname: AQHBCI appversion: 4.2 hope this helps.
For information, this is my current workaround: 1) use fully installed 2.3.15 for 'normal' functionality and for csv import of data, which is a key function for my current migration from other tools into GnuCash. 2) use 2.2.9 in the portable version (see http://portableapps.com/apps/office/gnucash_portable ) including AqHBCI to do account updates via HBCI. In the beginning I was a bit scared using two different versions of GnuCash working on the same database, but so far no problem. Of course, I would be happy to get the AqHBCI running on 2.3.15 one day...
As the status is still 'NEEDINFO' I will provide more information, but I am not sure, whether this brings someone closer to a solution: 1) I completely removed the GnuCash 2.3.15 installation from my Desktop PC and re-installed. Then I wanted to manually set up the HBCI (PINTAN) connection again. When setting up a user, there is the step where aqhbci tries to get the SSL certificate. A window opens (as usual), but after maybe 4-5 lines of log entries, it disappears again. Tooooo fast to read whether there is an error message. Screenshot also impossible. I was doing this on Windows Vista Home Basic. 2) As I am always assuming that it might be the OS that is causing the trouble, I repeating all steps on my business laptop, which is running on XP. Unfortunately exactly same problem. 3) When I copy the HBCI definitions from my GnuCash 2.2.9 installation onto my PC, the errors as above appear again. Again: the workaround is to run 2.2.9 only for data import via HBCI, then I further process the data in 2.3.15 (most probably not the way it was intended by programmers...) Thanks a lot in advance, beside this issue GnuCash is great for me.
Just installed 2.3.16 and hoped for a change. Unfortunately same problem...
Just for completeness: In gnucash-2.3.16 there is aqbanking-4.2.4, gwenhywfar-3.11.3, gnutls-2.8.1
Can you please try to update gnucash's version of gnutls to the newest gnutls-2.8.x package, i.e. unpack http://josefsson.org/gnutls4win/gnutls-2.8.6.zip somewhere on your disk, then copy all *.dll files from its bin/ folder into gnucash's bin folder (i.e. where gnucash.exe exists) and try again. I will update the gnutls version in the gnucash package itself, too, but it would be helpful if you can already check newer gnutls versions yourself.
I did as suggested. Immediately after installing gnutls version 2.8.6 I tried to set up new user. Failed (again) in step 'Server Zertifikat abrufen'. Then I rebooted (quite desperate method, but one should never give up). Then I was able to pass the step 'Server Zertifikat abrufen' (jippie, I thought). Unfortunately in the next step I got errormessage as attached: TLS Handshake Error: -59 (GnuTLS internal error.) Just for info: after that I couldn't repeat the whole procedure again, it needed another reboot to pass ONCE the step 'Server Zertifikat abholen' Please let me know if you want me to produce debugging files or something.
Created attachment 174056 [details] Errormessage Screenshot
Martin Preuss (not the reporter) said: He's able to connect to the ing-diba server without the -59 error, both using gnucash-2.3.16 (including gnutls-2.8.1) and his alternative online banking software "aqfinance" (including gnutls-2.8.6). He couldn's run an actual online action because he doesn't have an account there, though. The next nightly gnucash windows build will be done with gnutls-2.8.6 so that maybe things work better there. Can you please try that once it is available (tomorrow after 10am German time).
I downloaded the version this morning (i.e. 2am German time), de-installed existing version, installed new version. Tested with my ING-Diba account to make sure it is not a bank issue (see comment #15). Same as before... :-( As the downloaded file was *exactly* same size as before (63686KB), I repeated after initial testing the steps from comment #12. However, same result, problem persists. Haven't done the rebooting though as in comment #13. Will do this later and will post a comment if it changes something.
Unfortunately the aqbanking developer cannot reproduce this error (comment #15) even though he tried as well on Windows with gnucash-2.3.16 (including gnutls-2.8.1) and also with gnutls-2.8.6. Unfortunately this means we have no idea where this error comes from and we can't do anything about it for now. Sorry.
OK, accepted for now, since I have a workaround and I don't update the accounts every day. Please keep in mind that I tried to install on three PC's, each time 2.2.9 worked perfectly and 2.3.16 did not work. I tried various ways on both MS XP and a MS Vista Home: - installation of 2.3.16 on a clean, i.e. 'virgin' system - installation of 2.2.9 on a clean system, then upgrade to 2.3.16 - installation of 2.2.9, complete de-installation (incl. cleaning registry), new installation of 2.3.16 - an unsupported way of installation of 2.3.16, then install 2.2.9 on top, then install again 2.3.16 (actually I wondered whether GnuCash would work after that at all...) I am running out of ideas. It appears to me that some components or settings must be missing on all of my PC's that are existant on developers PC, but somehow didn't find their way into the installation package and/or the installation guidelines. So let's wait and see.... One final question for my workaround: Currently I update the accounts with an 2.2.9 version and then copy the whole GnuCash data file into my 2.3.16 version for further actions (e.g. reporting). Would it be cleaner to update with 2.2.9, but then take the log file only into 2.3.16 and import from logfile? Thanks for the support.
Just to update, 2.3.17 didn't fix the issue for me.
*** Bug 635766 has been marked as a duplicate of this bug. ***
(In reply to comment #18) > One final question for my workaround: > Currently I update the accounts with an 2.2.9 version and then copy the whole > GnuCash data file into my 2.3.16 version for further actions (e.g. reporting). > Would it be cleaner to update with 2.2.9, but then take the log file only into > 2.3.16 and import from logfile? No, your current workaround to copy the whole data file is correct. The "log files" are almost useless. Just ignore them. The data file is completely compatible between 2.2.9 and 2.3.16 with one exception in the reccurrence interval of scheduled transactions: 2.3.16 has the possibility to choose the interval "each weekend" or "each weekday", and this particular setting will get lost in 2.2.9. But all normal scheduled transactions (e.g. "once per month") and all other data is completely compatible.
I had the same problem with 2.3.x and 2.4.0 in Windows Vista Business 32 bit and Windows 7 Enterprise 64 bit. It looks like gwenhyfar seems to be buggy under anything post 2.2.x... Is there any chance to use a more current SSL library that actually works?
Just for completeness: no change after upgrading to 2.4.0
(In reply to comment #21) > (In reply to comment #18) > > One final question for my workaround: > > Currently I update the accounts with an 2.2.9 version and then copy the whole > > GnuCash data file into my 2.3.16 version for further actions (e.g. reporting). > > Would it be cleaner to update with 2.2.9, but then take the log file only into > > 2.3.16 and import from logfile? > > No, your current workaround to copy the whole data file is correct. The "log > files" are almost useless. Just ignore them. > > The data file is completely compatible between 2.2.9 and 2.3.16 with one > exception in the reccurrence interval of scheduled transactions: 2.3.16 has the > possibility to choose the interval "each weekend" or "each weekday", and this > particular setting will get lost in 2.2.9. But all normal scheduled > transactions (e.g. "once per month") and all other data is completely > compatible. Information for others using this workaround: There is one tiny problem if you use currency trading accounts (i.e. you are working in a multiple currency setup): After updating accounts in 2.2.9 and copying the xml file back to 2.4.0, make sure you check the type of your currency trading accounts. In my case the type disappears and need to be re-assigned. No functional problem, if you miss to do this. However, in the balance sheet report the currency trading account will not be shown, if it has not been re-assigned (so the balance will be imbalanced). It is just another 10 seconds more effort in this workaround, so not to worry...
Hello, Not sure if it helps, but I am experiencing the same bug on Windows 7 and GnuCash 2.4. Already downloaded latest GnuTLS (2.10) but no change. I have observed a few things: 1. If you just try often enough (10-50 times) you will get through the first stage, but the request will abort 99% of the time. Mostly with error -59, but if repeated in quick succession you may also see -15 and -19. 2. When you restart GnuCash it would sometimes do it the first time, but afterwards fail again (As described by one poster). Unfortunately, that doesnt really help as you need to connect several times for each stage. All together the probability that you get all stages right are slim. 3. Checking the network traffic with WireShark it seems that the client sends a SYN, gets a SYN, ACK and responds with an ACK. Problem is that right after it sends an ACK, RST. I am not sure why this happens, dont even know if it is GC sending the RST. This might explain why the window to request the certificate just flashes for a split second on the screen. Using the command line tool will basically yield the same results. If you need more info or the network sniff please let me know. In case there is something to debug, please let me know what to do and I will try to get the info. Cheers, Danny
I would like to add myself to this list people with the error. I have, similar to above, found that downgrading to 2.2.9 solves the problem, whilst all newer versions (incl 2.4.2) error out - both at loading new users, and using old setups. Also running Windows 7, also tried to install GnuTLS with no success. Have the error with Comdirect, INGDiba, Sparkasse Koblenz and CortalConsors. Have tried all permutations of SSLv3 and security options, none work.
I might have another workaround or procedure to get HBCI queries to work with 2.4.4 I ran into similar problems as described above after upgrading from 2.2.9 to 2.4.3 and 2.4.4 - not being able to download the certificate and the message window immediately closing. I also at one point saw the -59 GnuTLS error. Having read the comment about the problem not being reproducible, I downloaded the latest version of AqFinance 0.9.91b. Using AqFinance, I could download the Bank server certificate without problems. Creating the banking user for DKB after some experimentation succeeded, using the following settings: Benutzerkennung (User ID): DKB Legitimations-ID Kundennummer (Customer ID): DKB Legitimations-ID HBCI version: 2.2 HTTP-Version: 1.1 SSLv3 erzwingen: selected Disable Base64 encoding: not selected Once the user was created in AqFinance, it also showed in Gnucash, I could map it to the needed account, and online queries to DKB started to work.
Unfortunately the workaround worked only until the next reboot. Now I consistently get the following error when trying to retrieve transactions: Sending jobs to the bank(s) Locking users Locking user xxxxxxxxxxxxxxxxxxx Executing HBCI jobs AqHBCI gestartet Mit Bank verbinden... Ermittle Adresse von "hbci-pintan-by.s-hbci.de" ... Ermittelte IP Adresse ist 195.140.107.125 Selecting iTAN mode "iTAN" Öffne Dialog mit dem Server Aufträge werden kodiert Aufträge werden gesendet Mit Bank verbinden... TLS Handshake Error: -59 (GnuTLS internal error.) Retrying to connect (non-SSLv3) TLS Handshake Error: -59 (GnuTLS internal error.) Could not connect to the bank Fehler beim Senden (Netzwerk-Fehler) AqHBCI abgeschlossen. Postprocessing jobs Resetting provider queues
I just want to mention that the problem persists in version 2.4.5 Hope that this can be fixed soon...
On my Windows XP system gnuCash 2.4.8 works with gnuTLS fine (no handshake error regardless the settings like ssl3 etc.) On my Windows 7 system I have to start gnuCash as admin, then it works fine (without any other special settings). Of course you can run also the aqhbci-tool4 in ADMIN mode, then everything works fine. My System: Windows 7 gnucash 2.4.8 aqhbci-tool4.exe
I tried Stefan's approach using admin mode (I also run on Windows 7), but no luck. I also tried playing around with XP compatibility mode, which also didn't help...
(In reply to comment #0) > Ich nutze die Version 2.3.15, SVN r19437. > In 2.2.9 hat die HBCI Verbindung funktioniert. > Nach dem Upgrade bekomme ich bereits beim Abrufen der Systemkennung folgende > Fehlermeldungen: > > 00:19:27 > Executing HBCI jobs > 00:19:27 > AqHBCI gestartet > 00:19:27 > Mit Bank verbinden... > 00:19:27 > Ermittle Adresse von "hbci.bw-bank.de" ... > 00:19:27 > Ermittelte IP Adresse ist 91.198.67.28 > 00:19:27 > Aufträge werden kodiert > 00:19:30 > Aufträge werden gesendet > 00:19:30 > Mit Bank verbinden... > 00:19:31 > TLS Handshake Error: -59 (GnuTLS internal error.) > 00:19:31 > Retrying to connect (non-SSLv3) > 00:19:31 > TLS Handshake Error: -59 (GnuTLS internal error.) > 00:19:31 > Could not connect to the bank > 00:19:31 > Fehler beim Senden (Netzwerk-Fehler) > 00:19:31 > AqHBCI abgeschlossen. > 00:19:31 > Abgeschlossen. Sie können dieses Fenster nun schließen. > > Beim Anlegen eines neuen Users verschwindet beim Abrufen des SSL Zertifikats > das Dialogfenster so schnell, dass die Nachrichten nicht lesbar sind, d.h. man > kommt durch Neuanlage nicht weiter. > > Beim Saldenaufruf kommt aehnliche Fehlermeldung: > > Sending jobs to the bank(s) > Locking users > Locking user xxxxxxx > Executing HBCI jobs > AqHBCI gestartet > Mit Bank verbinden... > Ermittle Adresse von "hbci.bw-bank.de" ... > Ermittelte IP Adresse ist 91.198.67.28 > Öffne Dialog mit dem Server > Aufträge werden kodiert > Aufträge werden gesendet > Mit Bank verbinden... > A TLS handshake error occurred. If you are using AqBanking you should consider > enabling the option "force SSLv3" in the user settings dialog. > Retrying to connect (non-SSLv3) > A TLS handshake error occurred. If you are using AqBanking you should consider > enabling the option "force SSLv3" in the user settings dialog. > Could not connect to the bank > Fehler beim Senden (Netzwerk-Fehler) > AqHBCI abgeschlossen. > Postprocessing jobs > Resetting provider queues > > > Vielen Dank vorab fuer die Hilfe. (In reply to comment #31) > I tried Stefan's approach using admin mode (I also run on Windows 7), but no > luck. I also tried playing around with XP compatibility mode, which also didn't > help... I cannot add much, but can confirm the described behaviour: I also use Windows 7 (Home Premium 64 Bit) and tried to create an HBCI user with GnuCash 2.4.8. When I come over the certificate download after clicking several times I also get this "TLS Handshake Error: -59 (GnuTLS internal error.)" error message. Running GnuCash as administrator does not help either. But in one of my trials I got the additional error message: Mit Bank verbinden... 13:19:38 TLS Handshake Error: -19 (An unexpected TLS handshake packet was received.) 13:19:38 Retrying to connect (non-SSLv3) Maybe this gives a hint. But I got this error -19 exactly one time. I even tried to install GnuCash 2.4.8 in virtual XP machine on my Windows 7 host. Here I did not even get over the certifact download. When using GnuCash 2.2.9 everything works fine. It would be great if someone found a solution because there obviously is something wrong with GnuCash versions higher than 2.2.9.
New approach that worked *once*: I removed the read-only setting from the gnucash folder and all sub-directories. SSL was forced, all other extra options were deactivated. Subsequently, I got systemID (successfully) and then re-ran the connection (for Comdirect). Whilst I still got a -59 error, it subsequently reconnected - and downloaded all transactions. Strange... it worked only once, though. The tick mark from force SSL was gone when I checked in the settings, reactivating it didn't make a difference. Still running Win 7, in admin mode, with GNUCash 2.4.7
I got it working after I had the same problems as you all (-59 error) :-) My System: Win7 Ultimate 64bit Gnucash 2.4.8 aqbanking 4.2.4 Run gnucash in compatibility mode (WinXP-SP3)!!! After recreation of the online users all connections could be established: - Sparkasse - IngDiba - DKB
(In reply to comment #34) > I got it working after I had the same problems as you all (-59 error) :-) > > My System: > Win7 Ultimate 64bit > Gnucash 2.4.8 > aqbanking 4.2.4 > > Run gnucash in compatibility mode (WinXP-SP3)!!! > After recreation of the online users all connections could be established: > - Sparkasse > - IngDiba > - DKB I experienced this issue (TLS Handshalte Error -59) before and can confirm the correct operation when running in Compatibilty Mode (XP SP3). Win7 Professional SP1 (64 Bit) GnuCash 2.4.8 Fiducia, Comdirect, Sparkasse Great job!
I didn't change the Compability Mode, but I upgraded to 2.4.10 instead. ALL issues on all my different PC's OS (XP, WIN7) SOLVED. Whatever/whoever fixed it: THANK YOU. Happy - happy - happy !!!
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=632158. Please update any external references or bookmarks.