Reusing a Java REST client as an RTC service. Unable to login in RTC from an RTC service
Serghei Zagorinyak (48●2●9●13)
| asked Aug 08 '12, 10:31 a.m.
retagged Aug 09 '12, 10:50 a.m. by Vladimir Amelin (704●7●22●26) Hi! I'm trying to login to my local RTC server with help of some legacy code that is said to work fine, but I receive the javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure all the time. The trick is that I am trying to write a wrapper plugin for RTC web interface that would proxy calls from WebUI to a REST client implementation that was used to work with repository via REST from a remote client. So I wrote a MODELLED_REST service plugin and embedded the legacy code in it. It compiles and runs, but when the legacy method tries to login, it gets a handshake_failure error. Is what I am doing possible at all? I'll be grateful for any hints on this. Is there a smarter way to reuse the legacy code? This restClient has a lot of logic in it and I'd like to make as much use of it as possible. UPD: When I try to login from my service running on Jetty to a different instance of RTC running on Tomcat it works fine with Scheme set on port 443. The login URL I use there is https://127.0.0.1:9443/ccm/authenticated/identity. But Jetty doesn't have this kind of a link and uses https://127.0.0.1:7443/jazz/.. to address everything. So the URL for Jetty is https://127.0.0.1:7443/jazz/authenticated/identity Here is the code that is used to login (the bold line is the one where the Exception is thrown):
public boolean loginRTC() {
//this link in browser redirects me to the login page
and getHttpClient is as follows:
private HttpClient getHttpClient() throws RequestException {
|
2 answers
Could it be that your getHttpClient method is registering a Scheme for "https" on port 443, but you are sending a request to port 7443? Your HttpPost method uses the variable named "rtcUrl" for the request URI, and the code snippet does not show the value of that variable, but the earlier HttpGet request was constructed with the URL "https://127.0.0.1:7443/jazz/authenticated/identity".
Comments No, that doesn't seem to be the reason. When I try to login from my service running on Jetty to a different instance of RTC running on Tomcat it works fine with Scheme set on port 443. The login URL I use there is https://127.0.0.1:9443/ccm/authenticated/identity. But Jetty doesn't have this kind of a link and uses https://127.0.0.1:7443/jazz/.. to address everything. So the URL for Jetty is https://127.0.0.1:7443/jazz/authenticated/identity. I've tried to change the Scheme port to 7443 with Jetty, but still no good. P.S. The rtcUrl value is https://127.0.0.1:7443/jazz/ and the LOGIN_FORM_URL is authenticated/identity. The URL in the HttpGet request is a result of their concatenation. I just provided it in plain text for better understanding. The code I've seen that tries to do what you're doing (accept all certificate and trust all hosts) looks a little different; it uses TrustManager instead of TrustStrategy. For example, see http://javaskeleton.blogspot.com/2010/07/avoiding-peer-not-authenticated-with.html I'm afraid that's all the advice I have.
Serghei Zagorinyak
commented Aug 10 '12, 5:39 a.m.
Is it possible that the plugin tries to login to host but the host is not ready to accept the connections yet? As far as I get it, the initialization of the restClient is done during server startup. If so, how can I postpone it? I altered the code so that the first attempt to login is made when the first "set" request is recieved. I've also replaced the getHttpClient code with the one in your article. Still javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure Looks like this has something to do with Jetty. It works when deployed on Tomcat. Sorry, I'm out of ideas. |
SSLHandshakeException may occur because you don't have the Security Certificate of the particular server on the security store under your jdk's certificate store..
May be that one of the server's (to which you're able to talk to..) security certificate is already installed and the other one's not.. To overcome this, you must open the server on the browser, export the security certificate from there.. Import this certificate into the jdk's certificate store.. (import into all, if you have more than one certificate store, under jre, jdk folder... also if you have more than one jdk/jre folders, wherever you have the certificate store..) |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.