It's all about the answers!

Ask a question

Reusing a Java REST client as an RTC service. Unable to login in RTC from an RTC service

Serghei Zagorinyak (482913) | asked Aug 08 '12, 10:31 a.m.
retagged Aug 09 '12, 10:50 a.m. by Vladimir Amelin (70472226)

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 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 But Jetty doesn't have this kind of a link and uses to address everything. So the URL for Jetty is

Here is the code that is used to login (the bold line is the one where the Exception is thrown):

public boolean loginRTC() {
HttpResponse response;"trying to log in");
try {
httpClient = getHttpClient();"getting cookies");
cookieStore = new BasicCookieStore();
localContext = new BasicHttpContext();
localContext.setAttribute(ClientContext.COOKIE_STORE, cookieStore);

//this link in browser redirects me to the login page
HttpGet httpGetID = new HttpGet(""); 
response = httpClient.execute(httpGetID, localContext);;
List<Cookie> cookies1 = cookieStore.getCookies();
for (Cookie cookie : cookies1) {"\t" + cookie.getName() + " : " + cookie.getValue());
}"send username and password");
List<NameValuePair> authFormParams = new ArrayList<NameValuePair>();
  authFormParams.add(new BasicNameValuePair("j_username", "ADMIN"));
  authFormParams.add(new BasicNameValuePair("j_password", "ADMIN"));
UrlEncodedFormEntity entity;
entity = new UrlEncodedFormEntity(authFormParams, "UTF-8");
HttpPost httpPostAuth = new HttpPost(rtcUrl + LOGIN_CHECK_URL);
response = httpClient.execute(httpPostAuth, localContext);;

// retrieve new cookies
HttpGet httpGetCookie = new HttpGet(rtcUrl + LOGIN_FORM_URL);
response = httpClient.execute(httpGetCookie, localContext);;

if (checkAuthorized()) {"login SUCCESSFUL");
return true;
} catch (Exception e) {
logger.error(e.getMessage(), e);
}"login FAILED");
return false;

and getHttpClient is as follows:

private HttpClient getHttpClient() throws RequestException {
try {
SSLSocketFactory socketFactory = new SSLSocketFactory(
new TrustStrategy() {
public boolean isTrusted(X509Certificate[] chain, String authType)
throws CertificateException {
return true;
Scheme sch = new Scheme("https", 443, socketFactory);

ThreadSafeClientConnManager cm = new ThreadSafeClientConnManager();
HttpClient result = new DefaultHttpClient(cm);
return result;
} catch (Exception e) {
String msg = "Couldn't set SSL trust strategy: " + e.getMessage();
logger.error(msg, e);
throw new RequestException(msg);

String msg =

2 answers

permanent link
John Vasta (2.6k15) | answered Aug 08 '12, 10:48 a.m.
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 "".

Serghei Zagorinyak commented Aug 09 '12, 3:04 a.m. | edited Aug 09 '12, 3:43 a.m.

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 But Jetty doesn't have this kind of a link and uses to address everything. So the URL for Jetty is I've tried to change the Scheme port to 7443 with Jetty, but still no good.

P.S. The rtcUrl value is 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.

John Vasta commented Aug 09 '12, 4:03 p.m.

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 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?

Serghei Zagorinyak commented Aug 10 '12, 7:00 a.m. | edited Aug 10 '12, 7:24 a.m.

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 Received fatal alert: handshake_failure Looks like this has something to do with Jetty. It works when deployed on Tomcat.

John Vasta commented Aug 10 '12, 11:37 a.m.

Sorry, I'm out of ideas.

permanent link
Madhan Babu (368) | answered Jun 18 '13, 7:59 a.m.
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

Register or to post your answer.