Posted: October 15th, 2009 | Author: Graham | Filed under: random | Tags: citrix, java, jre, metaframe, security | 1 Comment »
I’m doing a bit of work for a client and they run this crazy Citrix Metaframe thing, which I’ve heard of but never used before. It’s like a remote access tool / website wrapped in java applets and special clients and all sorts of other whizbangerry.
But I had a problem connecting to it. It would load a java applet and then Java would die when initializing with the following error. I’m running the latest Sun Java 6 u16.
A local security certificate could not be loaded. (error code: 7)
at com.citrix.sdk.security.ssl.ConnectionModel.addCACertificate(ConnectionModel.java)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.citrix.client.io.net.ip.m.h(Unknown Source)
at com.citrix.client.io.net.ip.proxy.i.(Unknown Source)
at com.citrix.client.io.net.ip.g.a(Unknown Source)
at com.citrix.client.io.net.ip.o.a(Unknown Source)
at com.citrix.client.module.td.tcp.TCPTransportDriver.t(Unknown Source)
at com.citrix.client.module.td.TransportDriver.run(Unknown Source)
at java.lang.Thread.run(Thread.java:619)
Caused by: The SSL cryptography library failed. The security certificate "America Online Root Certification Authority 2" has a public key of length greater than 2048 bit.
at com.citrix.sdk.security.certificate.X509CertificateLoader.loadCertificates(X509CertificateLoader.java)
It’s about identical to this unsolved post at Ubuntu launchpad too. The certificates for a simple client JRE are stored in the cacerts file which lives in jre/lib/security/cacerts . It looks as if the root certificate for AOL is too long or recently updated or something and it’s not playing nicely with MetaFrame. So somehow we have to ditch that root cert. It would only really be a problem if we are unlucky enough to have our certificate signed by that root CA.
I assumed that MetaFrame worked on older jres and that the problem is that I am using a brand new one. So luckily Sun keep an archive of old JDKs and JREs here. So it is quite simple, download an install an old JRE (I got 5u1) and rip the cacerts file out of there and dump it into your new JRE’s directory and try it again. Worked like a charm for me. You probably don’t want to do this permanently (I guess they updated the cacerts file for a reason?) but if you really need to log into MetaFrame, it’ll do.
Posted: June 28th, 2009 | Author: Graham | Filed under: Uncategorized | Tags: db2, portal, security, websphere | No Comments »
I try to post really random solutions here, and this one’s a doozy ! I was updating a production machine from Portal 6.1.0 to 6.1.0.2. I always run the ConfigEngine tasks validate-standalone-ldap and validate-database-connection before I run any Portal update to make sure that the update won’t fail from something silly like a missing password. I’d highly recommend this practice on your Portal systems.
This time when running validate-database-connection, I ran into this error:
action-validate-database:
[echo] domain 'jcr'
[echo] DbtDbDriver 'com.ibm.db2.jcc.DB2Driver'
[echo] DbtDbLibrary '/home/db2inst1/sqllib/java/db2jcc.jar:/home/db2inst1/sqllib/java/db2jcc_license_cu.jar'
[echo] DbtDbUser 'db2inst1'
[echo] DbtDbUrl 'jdbc:db2://localhost:50000/WPS6TCP'
[echo] DbtDbName 'WPS6TCP'
[java] [06/28/09 13:47:09.620 EST] Attempting to make connection using: jdbc:db2://localhost:50000/WPS6TCP :: db2inst1 :: PASSWORD_REMOVED
[java] [06/28/09 13:47:09.875 EST] ERROR: Error obtaining connecting for jdbc:db2://localhost:50000/WPS6TCP
[java] com.ibm.db2.jcc.b.SqlException: [ibm][db2][jcc][t4][201][11237] Connection authorization failure occurred. Reason: Security mechanism not supported.
[java] at com.ibm.db2.jcc.a.b.m(b.java:1981)
[java] at com.ibm.db2.jcc.a.b.a(b.java:1565)
[java] at com.ibm.db2.jcc.a.bb.b(bb.java:3386)
[java] at com.ibm.db2.jcc.a.bb.a(bb.java:332)
[java] at com.ibm.db2.jcc.a.bb.a(bb.java:112)
[java] at com.ibm.db2.jcc.a.b.j(b.java:1259)
[java] at com.ibm.db2.jcc.a.b.b(b.java:1132)
[java] at com.ibm.db2.jcc.a.b.b(b.java:715)
[java] at com.ibm.db2.jcc.a.b.a(b.java:701)
[java] at com.ibm.db2.jcc.a.b.a(b.java:378)
[java] at com.ibm.db2.jcc.a.b.<init>(b.java:316)
[java] at com.ibm.db2.jcc.DB2Driver.connect(DB2Driver.java:166)
[java] at java.sql.DriverManager.getConnection(DriverManager.java:572)
[java] at java.sql.DriverManager.getConnection(DriverManager.java:165)
[java] at com.ibm.wps.config.db.Database.init(Database.java:139)
[java] at com.ibm.wps.config.db.validation.ValidationDriver.main(ValidationDriver.java:209)
It looked like the problem I’d seen on Ubuntu, where the database password was hashed with an unsupported scheme, but it couldn’t be, because this was on a plain old RHEL system. The difference was that I’d recently changed DB2’s database manager settings from AUTHENTICATION = SERVER to AUTHENTICATION = DATA_ENCRYPT . DATA_ENCRYPT is good because it will send your sql data and your authentication details encrypted across the wire.
Anyway, to make the validation work on a system where you have enabled the DATA_ENCRYPT parameter, just add securityMechanism=13; to the end of the database url. So mine becomes:
jcr.DbUrl=jdbc:db2://localhost:50000/WP6TCP:securityMechanism=13;
So how would the system work in any case, if the database url was wrong?!? The answer is clear after delving into the WebSphere admin console a little bit. I’d configured the custom properties of each Portal datasource post database transfer to work with DATA_ENCRYPT, but not the database urls in wkplc_comp.properties. Here’s where you would set it.
It is important to emphasize that the wkplc*.properties file in ConfigEngine are templates only, and don’t affect the running of the system, until you run a ConfigEngine task against them. Only then do their values get copied to the actual Portal server.
