Develop Reference

Cannot connect to Lotus Notes DIIOP on SSL port 63149

The company I work for creates software that crawls and indexes various sources for use in search, in this case we're completely stuck on attempting to connect to Lotus Notes over SSL. This is a classic case of "it worked in dev, but failed in prod".
The problem is further compounded by the fact that we're devs and techies, not Lotus Notes experts.
Basically we have a piece of Java software that connects to Lotus to grab the DIIOP IOR text file using this command:
String ior = NotesFactory.getIOR(host, userIOR, pwdIOR);
Now, this is a non-SSL connection and requires username and password to connect. This works perfectly every time.
Then we attempt to create a session using this:
session = NotesFactory.createSessionWithIOR(ior, args, this.user, this.pwd);
where:
args[0] = "-ORBEnableSSLSecurity";
When connecting we consistently receive this stack trace:
NotesException: Session closed due to communications failure
at lotus.domino.cso.ORBCallback.make_error(Unknown Source)
at lotus.priv.CORBA.iiop.Generic.make_error(Unknown Source)
at lotus.priv.CORBA.portable.ObjectImpl._invoke(Unknown Source)
at lotus.domino.corba._IObjectServerStub.createSession(Unknown Source)
at lotus.domino.cso.Session.initSession(Unknown Source)
at lotus.domino.cso.Session.<init>(Unknown Source)
at lotus.domino.cso.Session.createSession(Unknown Source)
at lotus.domino.NotesFactory.createSessionUP(Unknown Source)
at lotus.domino.NotesFactory.createSessionWithIOR(Unknown Source)
[ ... ]
Caused by: org.omg.CORBA.COMM_FAILURE: java.net.SocketException: Connection reset: Connection closed: Host: <redacted> Port: 63149 vmcid: 0x0 minor code: 1 completed: Maybe
at lotus.priv.CORBA.iiop.IIOPConnection.purge_calls(Unknown Source)
at lotus.priv.CORBA.iiop.ReaderThread.run(Unknown Source)
Caused by: java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:154)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at lotus.priv.CORBA.iiop.Message.readFully(Unknown Source)
at lotus.priv.CORBA.iiop.Message.createFromStream(Unknown Source)
at lotus.priv.CORBA.iiop.IIOPInputStream.prefill(Unknown Source)
at lotus.priv.CORBA.iiop.IIOPConnection.createInputStream(Unknown Source)
... 1 more
I understand the most common reason for this is because we're not correctly importing the TrustedCerts.class file, however after double and triple checking it's in the class path just fine (and the fact it works in dev environment) we're confident that it's being loaded in.
We know if we disable SSL (aka remove the aforementioned arg) our code will connect to the non-SSL DIIOP port 63148 and work just fine however it is a project requirement that all data must be passed through SSL.
Which finally brings me to my actual question: How do we get Lotus to report why this connection is failing?
I've tried upping the DIIOP log level to 4 which apparently should show all transmissions but the logs show nothing when I attempt to connect. Also it's worth noting the DIIOP service is definitely running and on the correct ports as well.
I've also checked that we're making it through the firewall to the remote box and TCPDUMP on our RedHat machine clearly shows that we establish a connection with the remote Lotus Notes host before it responds closing the connection.
[Pertinent Information]
Application: Java
Library: NCSO.jar
Lotus Version: Domino 8.5.3 FP6
Lotus Server: Windows Server 2008 Standard
Ports: 63148 (non-SSL), and 63149 (SSL)

Alright, the answer was clear as crystal but not something I was actively looking for.
The reason this doesn't work is that the third party certificate is not a SHA-1 certificate and Lotus Notes 8.5.x only supports SHA-1 (as per this documentation).
So basically that certificate of theirs can never be used for SSL authentication programatically or otherwise.

You mentioned DIIOP logging, but if the connection is failing in the SSL handshake, then the guts of the diiop task probably don't know what's wrong since that's occurring at a lower level in the stack. There are, however, additional debug variables that can be set on the server.
DEBUG_SSL_HANDSHAKE=1
DEBUG_SSL_CIPHERS=1
DEBUG_SSL_ALL=1
The last setting can be pushed up to 2 or 3 for more detailed information.
Restart of the server (or possibly of the server's diiop task) may be required to get the settings to take effect.

AWS DynamoDbMapper Error... Caused by: javax.net.ssl.SSLProtocolException:

I am trying to implement DynamoDBMapper from AWS but the application crashes when I try to connect to the AWS servers.
To start, I am running Android 4.4.2 on an Android Studio emulator and everything seems to be working fine. No problems there. Nonetheless, when I try to run on an actual device (running 4.4.2 on a Tablet... don't know the manufacturer), I get the following error:
Caused by: javax.net.ssl.SSLProtocolException: SSL handshake aborted: ssl=0x6bffcdf0:
Failure in SSL library, usually a protocol error error:140740B5:SSL
routines:SSL23_CLIENT_HELLO:no ciphers available (external/openssl/ssl/s23_clnt.c:486 0x68474ce0:0x00000000)
Here is the full stack trace:
Caused by: com.amazonaws.AmazonClientException: Unable to execute HTTP request: javax.net.ssl.SSLProtocolException: SSL handshake aborted: ssl=0x6bffcdf0: Failure in SSL library, usually a protocol error error:140740B5:SSL routines:SSL23_CLIENT_HELLO:no ciphers available (external/openssl/ssl/s23_clnt.c:486 0x68474ce0:0x00000000)
com.amazonaws.http.AmazonHttpClient.executeHelper AmazonHttpClient.java:421
com.amazonaws.http.AmazonHttpClient.execute AmazonHttpClient.java:196
com.amazonaws.services.dynamodbv2.AmazonDynamoDBClient.invoke AmazonDynamoDBClient.java:3257
com.amazonaws.services.dynamodbv2.AmazonDynamoDBClient.getItem AmazonDynamoDBClient.java:904
com.amazonaws.mobileconnectors.dynamodbv2.dynamodbmapper.DynamoDBMapper.load DynamoDBMapper.java:393
com.amazonaws.mobileconnectors.dynamodbv2.dynamodbmapper.DynamoDBMapper.load DynamoDBMapper.java:466
com.amazonaws.mobileconnectors.dynamodbv2.dynamodbmapper.DynamoDBMapper.load DynamoDBMapper.java:340
####.#####.####$####.doInBackground MainActivity.java:1259
####.#####.####$####.doInBackground MainActivity.java:1237
android.os.AsyncTask$2.call AsyncTask.java:288
java.util.concurrent.FutureTask.run FutureTask.java:237
... 4 more
Followed by:
Caused by: javax.net.ssl.SSLHandshakeException: javax.net.ssl.SSLProtocolException: SSL handshake aborted: ssl=0x6bffcdf0: Failure in SSL library, usually a protocol error error:140740B5:SSL routines:SSL23_CLIENT_HELLO:no ciphers available (external/openssl/ssl/s23_clnt.c:486 0x68474ce0:0x00000000)
com.android.org.conscrypt.NativeCrypto.SSL_do_handshake Native Method
com.android.org.conscrypt.OpenSSLSocketImpl.startHandshake OpenSSLSocketImpl.java:406
com.android.okhttp.Connection.upgradeToTls Connection.java:146
com.android.okhttp.Connection.connect Connection.java:107
com.android.okhttp.internal.http.HttpEngine.connect HttpEngine.java:294
com.android.okhttp.internal.http.HttpEngine.sendSocketRequest HttpEngine.java:255
com.android.okhttp.internal.http.HttpEngine.sendRequest HttpEngine.java:206
com.android.okhttp.internal.http.HttpURLConnectionImpl.execute HttpURLConnectionImpl.java:345
com.android.okhttp.internal.http.HttpURLConnectionImpl.connect HttpURLConnectionImpl.java:89
com.android.okhttp.internal.http.HttpURLConnectionImpl.getOutputStream HttpURLConnectionImpl.java:197
com.android.okhttp.internal.http.HttpsURLConnectionImpl.getOutputStream HttpsURLConnectionImpl.java:254
com.amazonaws.http.UrlHttpClient.writeContentToConnection UrlHttpClient.java:128
com.amazonaws.http.UrlHttpClient.execute UrlHttpClient.java:65
com.amazonaws.http.AmazonHttpClient.executeHelper AmazonHttpClient.java:353
... 14 more
And here is my sourcecode:
BasicAWSCredentials awsCredentials = new BasicAWSCredentials("abcdef12345","blahblahblah");
AmazonDynamoDBClient dynamoDBClient = new AmazonDynamoDBClient(awsCredentials);
DynamoDbMapper dbMapper = new DynamoDBMapper(dynamoDBClient);
//.... then eventually .....
AWSDriverNameTable awsDriverNameTable = dbMapper.load(AWSDriverNameTable.class, merchantID);
It is that last line of code where the error begins.
Now, I have looked around on SO and a few search engines and have learned that some Android devices fall back to SSL v3, while the server I am trying to connect to uses TLS v1.0 (went to www.ssllabs.com and found out that it does use TLS 1.0). Here is another SO question where someone seems to have solved an issue very similiar to this:
How to disable SSLv3 in android for HttpsUrlConnection?
Thus, if this is what is causing the issue (SSLv3 needing to be removed), how can I go about configuring the AmazonDynamoDbClient to use only TLS 1.0? I noticed you can create a ClientConfiguration and use:
clientConfiguration.getApacheHttpClientConfig().setSslSocketFactory(NoSSLv3SocketFactory);
and supply it with the awsCredentials in the AmazonDynamoDbClient constructor. But, it accepts:
org.apache.http.conn.ssl.SSLSocketFactory
not
javax.net.ssl.SSLSocketFactory
which is what is used in the answer from the link I provided (not to mention Android Studio is informing me that org.apache.http.conn.ssl.SSLSocketFactory is deprecated).
At any rate, any help with this matter would be much appreciated. Thanks!

You can use org.apache.http.conn.ssl.SSLConnectionSocketFactory instead of org.apache.http.conn.ssl.SSLSocketFactory.
From the JavaDoc of SSLSocketFactory (https://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/conn/ssl/SSLSocketFactory.html) -
Deprecated.
(4.3) use SSLConnectionSocketFactory

Some services like Cognito support TLSv1.0+, while some say DynamoDB supports only TLSv1.0 (not above). If your device supports TLSv1.0, it should work then. Since you said the code works on emulator but not on the tablet, it's hard to say where the problem is. I suggest you try these:
Visit https://dynamodb.us-west-2.amazonaws.com in your browser. If your device can handle TLSv1.0, you should see healthy: dynamodb.us-west-2.amazonaws.com.
Run the same code on a different device.
Some notes from comments:
SSLv3 has been deprecated on all AWS services.
Remove aws-java-sdk and use aws-android-sdk. The latter has lots of optimizations for Android.
aws-android-sdk uses HttpURLConnection as the default HTTP library.
To test what protocols a service supports, use this command:
openssl s_client -connect dynamodb.us-west-2.amazonaws.com:443

Trouble with securing a Tomcat/Axis2 web service via SSL

I have successfully built a working web service, client, and .jsp-driven UI. I did this with Eclipse, Axis2, Tomcat 7, and Java 7.
The basic flow is that the user visits the .jsp and submits a form with input data. The JSP forwards the "request" object to the Java client. The Java client consumes the web service and submits the user input. The service connects to a SQL Server database via JDBC to retrieve information, which is displayed back to the user.
This all works perfectly over HTTP, but now I want to secure the process, and this is where I'm running into problems. I'm able to create a cert and get Tomcat to use it. I can connect to the web UI via HTTPS and submit the form and get data back just fine. The problem is that this is only securing the front-end. The web service client code is still connecting to the service via HTTP in the background.
According to this page, all I really need to do to enable my service for connections via SSL is to update the axis2.xml file and include a new "transportReceiver" node for HTTPS. I did that and regenerated my client code to use the secure endpoint. It doesn't work.
I have configured Tomcat to listen on ports 8081 for http and 8443 for https. But after changing axis2.xml to match, and starting up Tomcat, I get the following:
[INFO] Listening on port 8443 [ERROR] Terminating connection
listener
org.apache.axis2.transport.http.server.DefaultConnectionListener#16d60567
after 10retries in 0 seconds. java.net.BindException: Address already
in use: JVM_Bind at java.net.DualStackPlainSocketImpl.bind0(Native
Method) at java.net.DualStackPlainSocketImpl.socketBind(Unknown
Source) at java.net.AbstractPlainSocketImpl.bind(Unknown Source) at
java.net.PlainSocketImpl.bind(Unknown Source) at
java.net.ServerSocket.bind(Unknown Source) at
java.net.ServerSocket.(Unknown Source) at
java.net.ServerSocket.(Unknown Source) at
org.apache.axis2.transport.http.server.DefaultConnectionListener.run(DefaultConnectionListener.java:80)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
I have tried changing the port number in axis2.xml (for example, to 8445), and that sort of works. The server is able to start cleanly, but eventually, the same errors start showing up. For example, when I retrieve the WSDL, I see the error via the console (though the WSDL does show up). Also, if I try to actually use the service when on port 8445, I get the following error:
org.apache.axis2.AxisFault: Connection has been shutdown:
javax.net.ssl.SSLException: Unrecognized SSL message, plaintext
connection?
I can only assume this is because Tomcat is configured to handle HTTPS on 8443, not 8445, but I honestly don't know.
If I leave the port as 8443 and ignore the errors at startup, I get the following message when I connect to the service:
org.apache.axis2.AxisFault: Connection has been shutdown:
javax.net.ssl.SSLHandshakeException:
sun.security.validator.ValidatorException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to
find valid certification path to requested target
I followed these steps to try to get it to recognize my certificate, but when importing it into my JRE7 keystore, I get the following:
keytool error: java.lang.Exception: Certificate reply and certificate
in keystore are identical
Basically, that cert is already there. Which makes sense, because it's the one that Tomcat is already using successfully.
So, I'm pretty clueless at this point. I'm really not sure what I'm supposed to be doing. Any general guidance, or a link to a step-by-step how-to would be really helpful.
But for a specific question... What, exactly, am I doing when I set the transportReceiver nodes in axis2.xml? Am I telling it what ports Tomcat is running on and that it should use, or does Axis2 have its own servers that will start on those ports? It seems to be the latter, but that doesn't make a whole lot of sense to me.

The correct way to configure the servlet transport is described in the Axis2 documentation. The symptoms you are describing suggest that you have a transportReceiver that refers to org.apache.axis2.transport.http.SimpleHTTPServer. Please also make sure that you use a recent version of Axis2 (1.5.6 or 1.6.1).

See Andreas's response for the port issue. As for the certificate issue, it was a misunderstanding on my part over the distinction between a keystore and truststore. The JVM defaults to using JAVA_HOME\lib\security\cacerts as its trust store, rather than the USER_HOME\.keystore file. Once I imported my certificate there, the errors went away.
I was also able to resolve the certificate problems by explicity setting the trust store to be the key store file, via code. I did this before importing the certificate into the cacerts store. It goes in the client code, right before invoking the service:
System.setProperty("javax.net.ssl.trustStore","C:\\path\\to\\.keystore");
System.setProperty("javax.net.ssl.trustStorePassword","password");

One of the way to connect to HTTPS is using jax-ws
E:\WSDL>wsimport -keep -p com.mypack.webservice https://domain:port/ws/MyService?wsdl
This will generate package structure under the wsdl folder. Use it.
Now all you have to do is put trust store in run.bat or use System class to set property.
It will work fine.

HANDSHAKE_FAILURE alert received

I am writing a Java client (on weblogic 10.3) to invoke a secure web service.
I have been provided with a client certificate which I have installed in cacerts, DemoIdentity.jks and DemoTrust,jks
In my weblogic I have set up keystore as DemoIdentity and DemoTrust.
In weblogic console I have set
"Two Way Client Cert Behavior:" as "Client Certs requested but not enforced".
and for "SSL Listen Port enabled:" I have checked the checkbox.
I get the below exception while trying to access the web service:
] FaultActor [null] Detail [<detail><bea_fault:stacktrace xmlns:bea_fault="http:
//www.bea.com/servers/wls70/webservice/fault/1.0.0">javax.net.ssl.SSLHandshakeEx
ception: [Security:090497]HANDSHAKE_FAILURE alert received from ************** Check both sides of the SSL configuration for mismatches in supported ciphers, supported protocol versions, trusted CAs, and hos
tname verification settings.
at com.certicom.tls.interfaceimpl.TLSConnectionImpl.fireException(Unknow
n Source)
at com.certicom.tls.interfaceimpl.TLSConnectionImpl.fireAlertReceived(Un
known Source)
at com.certicom.tls.record.alert.AlertHandler.handle(Unknown Source)
at com.certicom.tls.record.alert.AlertHandler.handleAlertMessages(Unknow
n Source)
at com.certicom.tls.record.MessageInterpreter.interpretContent(Unknown S
ource)
at com.certicom.tls.record.MessageInterpreter.decryptMessage(Unknown Sou
rce)
at com.certicom.tls.record.ReadHandler.processRecord(Unknown Source)
at com.certicom.tls.record.ReadHandler.readRecord(Unknown Source)
at com.certicom.tls.record.ReadHandler.readUntilHandshakeComplete(Unknow
n Source)
at com.certicom.tls.interfaceimpl.TLSConnectionImpl.completeHandshake(Un
known Source)
at com.certicom.tls.record.WriteHandler.write(Unknown Source)
at com.certicom.io.OutputSSLIOStreamWrapper.write(Unknown Source)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65
)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)
at java.io.FilterOutputStream.flush(FilterOutputStream.java:123)
at weblogic.net.http.HttpURLConnection.writeRequests(HttpURLConnection.j
ava:158)
at weblogic.net.http.HttpURLConnection.getInputStream(HttpURLConnection.
java:363)
at weblogic.net.http.SOAPHttpsURLConnection.getInputStream(SOAPHttpsURLC
onnection.java:37)
at weblogic.wsee.connection.transport.TransportUtil.getInputStream(Trans
portUtil.java:85)
at weblogic.wsee.connection.transport.http.HTTPClientTransport.receive(H
TTPClientTransport.java:271)
at weblogic.wsee.connection.soap.SoapConnection.receive(SoapConnection.j
ava:485)
at weblogic.wsee.ws.dispatch.client.ConnectionHandler.handleResponse(Con
nectionHandler.java:179)
at weblogic.wsee.handler.HandlerIterator.handleResponse(HandlerIterator.
java:287)
at weblogic.wsee.handler.HandlerIterator.handleResponse(HandlerIterator.
java:271)
at weblogic.wsee.ws.dispatch.client.ClientDispatcher.handleResponse(Clie
ntDispatcher.java:213)
at weblogic.wsee.ws.dispatch.client.ClientDispatcher.dispatch(ClientDisp
atcher.java:150)
at weblogic.wsee.ws.WsStub.invoke(WsStub.java:87)
at weblogic.wsee.jaxrpc.StubImpl._invoke(StubImpl.java:339)
at sips_cn_contract.PaymentService_Stub.processPaymentWebInit(Unknown So
urce)
at uk.gov.gateway.payments.SipsStartupController.handleRequest(SipsStart
upController.java:73)
at org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.ha
ndle(SimpleControllerHandlerAdapter.java:45)
at org.springframework.web.servlet.DispatcherServlet.doService(Dispatche
rServlet.java:485)
at org.springframework.web.servlet.FrameworkServlet.serviceWrapper(Frame
workServlet.java:342)
at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServl
et.java:318)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run
(StubSecurityHelper.java:227)
at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecuri
tyHelper.java:125)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.jav
a:300)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.jav
a:183)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationActio
n.doIt(WebAppServletContext.java:3686)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationActio
n.run(WebAppServletContext.java:3650)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(Authenticate
dSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:
121)
at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppS
ervletContext.java:2268)
at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletC
ontext.java:2174)
at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.j
ava:1446)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
</bea_fault:stacktrace></detail>]; nested exception is:
However in firefox, i have added the certificate, and when i view the wsdl of the web service.It prompts me with the certificate and after i click ok, it renders the wsdl file for secure web service.
Anybody has idea what should I do to make the client working using Java?

I think that the real problem is that Weblogic is not using standard Sun HTTPS implementation provided by JDK, but rather uses its own, as apparent on this line:
at weblogic.net.http.SOAPHttpsURLConnection.getInputStream(SOAPHttpsURLConnection.java:37)
The standard Sun implementation class is called javax.net.ssl.HttpsURLConnection.
As a result, the certificate policy is different inside Weblogic than in a standalone Java program. I just discovered this debugging a similar problem.
This page advises to use a Sun implementation instead of Weblogic:
http://webtech-kapil.blogspot.com/2010/06/javalangclasscastexception.html
They advice to start WL with the following flag:
-DUseSunHttpHandler=true
which will use standard Sun's implementation of SSL. However, I personally have not tried this yet.
Thanks,
Igor

You have likely not imported your certificate and key correctly. You can test your keystore by adding the following to a JUnit or something similar:
static {
System.setProperty("javax.net.ssl.keyStoreType", "pkcs12"); // or whatever
System.setProperty("javax.net.ssl.keyStore", "c:/folder/mycert.p12");
System.setProperty("javax.net.ssl.keyStorePassword", "mypassword");
System.setProperty("javax.net.debug", "ssl");
}
The javax.net.debug property set to ssl will print your certificate chain and all other SSL logging, which can be helpful. You'll want to add the certificate, etc. to your application container like you already have in production.
Try debugging with SSL and see what comes of that. More than likely you just need to configure weblogic correctly. Check to see if there are custom SSL endpoint configurations (i.e. when URI is /test/test use keyStore XYZ).

SOAP request in Java works locally but not on server

I have a webapp that sends a SOAP request to a 3rd party server. When the request is made on my local computer it works without a problem, but when I deploy my application to my server I get an error with the following causes:
com.sun.xml.messaging.saaj.SOAPExceptionImpl: java.security.PrivilegedActionException: com.sun.xml.messaging.saaj.SOAPExceptionImpl: Message send failed
Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: algorithm check failed: MD2withRSA is disabled
I've searched around but I can't find anything relevant to my situation. It's probably worth noting that the request I'm making is to an https url. My computer is running Windows XP and the server is running Slackware Linux. Any ideas what might be causing the server to reject the request?

Check your Java versions on your local machine, and your server.
From here, it seems the jvm 6u17 disabled MD2 as it is insecure, and whatever you connect to is using MD2

MD2withRSA is highly vulnerable and therefore deactivated in Sun... aeh Oracle's JVM. You should ask the owner of the remote service, whether his server supports more secure encryption methods (I think, older Apache HTTPd versions do offer MD2withRSA by default...). In order to resolve this problem without forcing the provider to change the method, you may use your own implementation of the X509TrustManager that accepts the old method.

A Google search on "MD2withRSA" showed this URL as the first hit, that seems to point to a change in a certain Java version. Probably the verasiuons on your local computer and the server do not match.

Newer Java 7 (version 1.7) allows re-enabling MD2 via $JAVA_HOME/jre/lib/security/java.security file. Download and install Java 7 and modify java.security file in text editor as follows
1) Remove MD2 from following property
jdk.certpath.disabledAlgorithms= # MD2
2) Ensure following property is commented out
# jdk.tls.disabledAlgorithms=MD5, SHA1, DSA, RSA keySize < 2048
3) Restart java application
Warning: MD2 is disabled by default in Jdk 7 because it is insecure. However, it can be enabled as described above to support older deployments.