In 'FiComClient' class, 'signData' method, the DTBS object is created with "DTBS.MIME_SHA1" by default. However, a different value can't be provided, like for sha-256, as it is not configurable. Is there any reason for this behavior?
Then, in the same class and method, the "FiComMSS_Formats.PKCS7" is used by default and can't be configured, e.g., to use pkcs1. However, the FiCom guidelines states that for the signature profile 'D', the "PKCS1" format should be used. So, if I am not missing anything, ok, it does not need to be configurable, but it should be "FiComMSS_Formats.PKCS1" instead, right?
Good report, thanks.
FiComClient.signData is supposed to be as straightforward as possible, and that means using default values for most stuff. It might be that SHA-1 is not a good default, but that's what it is, now.
You can use FiComClient.call(.. DTBS..) instead of FiComClient.signData() to specify another hash algorithm. It's entirely ok to use call() directly.
As a rough draft,
new DTBS(digest256ToBeSigned, DTBS.ENCODING_BASE64, DTBS.MIME_SHA256), // note
FiComMSS_Formats.PKCS1, // note
We'll have to look into the PKCS1/7 thing later, gotta fly now.
To see all this stuff working, I have run some of the samples provided in the package, e.g. SignData. Thanks to the log output I can see that the call '_sigResp = etsiClient.send(sigReq);' in FiComClient.java never succeeds because of a "java.net.ConnectException: Operation timed out".
Is it so that the URLs in the sample.conf file are not accessible for non-laverca-developers?
Btw, while testing and investigating around this, I discovered that the call 'statReq = etsiClient.createStatusRequest(fSigResp, apTransId);' inside the loop in the Future declaration lacks a try-catch. Without it, exceptions raised in the 'createStatusRequest' method are not caught and not even propagated upwards; worst, the application seems to gets stuck and unresponsive if that condition happens.
Unfortunately we are unable to provide a test server. Some invalid server configurations seem to have slipped in the release package, sorry about that.
I added a catch for the IllegalArgumentExceptions createStatusRequest was throwing. It shouldn't get stuck in the loop anymore.
No problem regarding those slipped configurations in 1.1. The fact that they made its way into 1.1 forced me to initiate lots of testing but also source code reading, both Laverca's and Axis'. Having URLs with 'http' and port '443' was something I could not understand thinking of the defaults for Axis, JSEE and even Laverca. Summarizing:
1) Axis' default transport handler, HTTPSender, will not use a "secure" socket factory if the protocol part of a URL is "http".
2) I guessed that the client-config.wsdd with the "ComponentsHTTPSender" would solve it. However, client-config.wsdd is neither included in Laverca's jar files nor referenced in some other way at runtime.
3) So without tweaking Laverca's released build script, the samples will use Axis' HTTPSender (So with the slipped URLs, the traffic would remain "plain").
4) A quick review of ComponentsHTTPSender showed that no encrypted SSL traffic would happen with those URLs either (as 443 port is associated with "https"). IIRC, it is the same with Axis' CommonsHTTPSender.
5) So I started guessing that you guys may have another, non-slipped in release, "HTTP Sender", proxies or etc, in order to get the samples working with those URLs.
I have to review all this again and make sure that this is the case and that I have understood all this properly. But if I do, I must admit that I am a bit confused: is it the intended way to not use client-config.wsdd and thus use Axis' HTTPSender? Or do you recommend to use client-config.wsdd and thus, Apache's-HttpClient-based ComponentsHTTPSender?
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.