On 2012-06-12 10:50, Alain Knaff wrote: ... and after the module is loaded the error message with BCEE now changes: Erreur LuxTrust: 131079 - LTEC:131079:CryptoTI module not initialized! (With the old driver, loading the module was not needed, as the banks supplied their own JNI to access the middleware directly, bypassing the browser itself) Alain

Dear all, I have forewarded the information right now to our IT waiting for a reply. thanks Paul -----Original Message----- From: Alain Knaff [mailto:alain@knaff.lu] Sent: Tuesday, June 12, 2012 8:08 PM To: lilux-help(a)prophecy.lu Cc: SCHUMACHER Pierre; Guy.Muller(a)luxtrust.lu; MULTILINE BPI; Maurice Hellers; Marco Trauffler; Lionel Elie Mamane Subject: Luxtrust now works in 64 bit with BGL, CCP and Raiffeisen! (Was: Re: [Lilux-help] LuxTrust using middleware Ubuntu 64-bit) ***** This message comes from the Internet Network ***** Hello all, After a bit of investigation, I've found that the only reason why BGL, CCP and Raiffeisen bank do not yet work in 64 bit is because the banks have not deployed LuxTrust's new version of their java JNI shim. (This shim allows java applets to call the PKCS11 middleware directly, bypassing java's normal security framework, and allowing to propose a menu if multiple card readers are present) So far this shim has existed only for 32 bits (which is expected, as the middleware itself only existed for 32 bit). Now, Luxtrust also have made a 64 bit version, but the banks (apparently) haven't deployed this yet. This is understandable, but why was there nobody at BGL who could point this out? (BGL was the only bank among the 3 listed above that I contacted, as it is the only one where I've got an account. I've also contacted BCEE, but the issue with their site is apparently unrelated) However, Luxtrust themselves have already installed this shim on their own site! To get it, go to test.luxtrust.lu (with javascript activated :-( ), and click yourself through the test. Just before the final screen, a file named LT_CTI_CC_GEM_9176010884699777019.tmp of size 130203 bytes will show up in /tmp (the exact digits in the name will change each time). This is the 64 bit version of the shim (if you performed the "test" with a 64 bit browser, else you will get a 32 bit version of 120041 bytes). Copy this to LT_CTI_CC_64.tmp both to /tmp and to your home directory. Now run the attached fix64.pl script. The script watches for new LT_CTI_CC_GEM_???????????????????.tmp files to appear in /tmp, and as soon as one appears, it is replaced immediately with a symlink to the LT_CTI_CC_64.tmp that you placed there in the previous step. Now, while the script is running, visit again one of the BGL, CCP or Raiffeisen sites: it should work now! Probably, in a couple of days (or weeks... :-( ), once all banks have deployed the new version of the Luxtrust shim, this "hack" should no longer be necessary. Many thanks to Mr Hellers for pointing me to the Luxtrust test site and to the BGL team for fixing a previous issue with a leftover Fortis class. Regards, Alain ============================================ Internet communications are not secure and therefore BGL BNP Paribas does not accept legal responsibility for the contents of this message. The information contained in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Nothing in the message is capable or intended to create any legally binding obligations on either party and it is not intended to provide legal advice. ============================================

Hi, For those of you who don't want to wait until BCEE deploys the correct LuxTrust jars, here is a workaround. 1. In /etc/hosts, add the following line: 127.0.0.1 bcee.snet.lu 2. If not yet there, install Apache. 3. Create a file with the following contents in /etc/apache2/sites-available/bcee : <VirtualHost *:443> ServerName bcee.snet.lu SSLEngine on SSLCertificateFile /etc/apache2/ssl/server.crt SSLCertificateKeyFile /etc/apache2/ssl/server.key ProxyPreserveHost on ProxyPass /ssogate/LuxTrust_Gemalto_CryptoTI_Adapter_LIN32_1.4.jar ! ProxyPass / https://195.46.224.5/ Redirect /ssogate/LuxTrust_Gemalto_CryptoTI_Adapter_LIN32_1.4.jar https://managing.luxtrust.lu/applets/public/LuxTrust_Gemalto_CryptoTI_Adapt… </VirtualHost> For 64 bit, the redirect line should be as follows instead: Redirect /ssogate/LuxTrust_Gemalto_CryptoTI_Adapter_LIN32_1.4.jar https://managing.luxtrust.lu/applets/public/LuxTrust_Gemalto_CryptoTI_Adapt… (note: we're still redirecting LIN32 due to BCEE's other error...) The SSL certifcates in /etc/apache2/ssl/server.crt and server.key should exist (but don't need to be correct, just add them as exception into firefox when prompted). 4. Activate the site: a2ensite bcee service apache2 reload 5. Now, connect to SNET as usual, add the certificate to Apache as an exception when prompted, and off you go! A note of CAUTION: Apache doesn't check whether the certificate for 195.46.224.5 is authentic, theoretically making your connection to BCEE vulnerable to snooping. So don't use this if you don't trust your ISP, or any other ISP between you and BCEE. It is possible to secure the connection from your Apache proxy to BCEE using SSLProxyVerify on, but this is too complex to fit into this short note. In case of interest, please drop me a mail Regards, Alain