It's all about the answers!

Ask a question

Setting Public URI fails with "forbidden"

Joe Frank (2612) | asked Mar 31 '15, 8:45 a.m.
edited Apr 28 '15, 8:39 a.m. by Krzysztof Kaźmierczyk (7.4k35198)
 I'm setting up a Rational Team Concert server. It has ccm, qm and rm installed with Websphere, all on the same server. It uses IHS as the web frontend also on the same server. The only port allowed into the server from outside is 443. 
When I install jts and components and set the public URI as https://servername:9443/jts all the links to the projects are to port 9443, which the firewall won't allow through. 
When I install jts and components with the public URI at https://servername/jts it works OK until I configure IHS for SSLClientAuth required (smart card). It still seems to work, but running a diagnostic shows that "rm/rootservices", "qm/rootservices" etc, and "rm/scr" etc are all forbidden to log in. It looks like they go through IHS to access the services and because SSLClientAuth is set to required, they don't get through for lack of a certificate. Id I set the SSLClientAuth to optional it works fine. Unfortunately I am required to ask for the Smart Card cert. 

Is there a way to configure this to work?

Thanks in advance,

Joe Frank

Accepted answer

permanent link
Joe Frank (2612) | answered Apr 27 '15, 1:10 p.m.
 I found the answer to this problem, apparently there is a certificate that java uses when accessing Websphere in the \jazzTeamServer\server\jre\lib\security folder called cacerts. The server certificates had to be added to this so when the jazz application went to access the IHS server , they would have a valid certificate to present.

Thanks for all your help!

Ralph Schoon selected this answer as the correct answer

2 other answers

permanent link
Ralph Schoon (61.1k33643) | answered Mar 31 '15, 8:55 a.m.
9443 is the default port on WAS and tomcat, however this can be changed. See for how to do that.

Please keep in mind not to choose a machine dependent name for the server, use a fully qualified domain name that can later be moved to a different machine.

Joe Frank commented Mar 31 '15, 10:12 a.m. | edited Mar 31 '15, 10:31 a.m.

  Thanks for the quick response! Unfortunately, the link supplied didn't answer my question. I have the Public URI configured on port 443, as the article shows. I have the WAS server running on port 9443, also as the article shows. The translation happens properly, when I log in at https://servername/jts/admin I get through. The problem comes into play when I set the IHS server to require certificates. The internal connection to "Applications and Friends" is broken. I'm getting an error message:

"Application: the discovery resource at https://servername/qm/rootservices for "qm" cannot be accessed:
The return HTTP Status was 403
The response body was

You don't have permission to access /qm/rootservices on this server"

This occurs for all the applications rootservices and scr connections.

It doesn't happen if IHS is set to "SSLClientAuth optional"


Joe Frank

Ralph Schoon commented Mar 31 '15, 10:37 a.m.

You have to set up all the applications using the same public URI root (in your case with 443 as the port). If you have a topology that uses multiple application servers (potentially listning to other ports, you have to set up IHS as proxy server in front of them, covering the public URI root and forwarding to the other application servers. Usually you install IHS in front of the other WAS servers and set it up to use LTPA token so that the login on IHS works on the other application server. See this page:

I am not sure what your problem is, because I am not sure I know the symptoms. So that hint is pretty much what I can do. Hopefully someone else knows the symptoms and help better.

permanent link
Donald Nong (14.4k314) | answered Apr 01 '15, 1:45 a.m.
Check the last post in this link.

I believe you explained the problem in a too complicated way. Basically, when you enable

SSLClientAuth on IBM HTTP Server, your WebSphere server (acting as a client) cannot connect to the IHS due to the lack of a certificate.

If you need to find more references, search with keyword "IHS WebSphere SSLClientAuth", and don't include anything related to RTC or CLM, because it's basically an IHS and WAS configuration issue.

Joe Frank commented Apr 01 '15, 11:21 a.m. | edited Apr 02 '15, 5:21 a.m.

Thank you for restating the problem in a more suitable way. As explained in the link, the client I'm using has a certificate, It looks to me like the RTC server tries to access itself and goes through the IBM HTTP Server to do it. I have server certificates installed in both IHS and Websphere, where do I need to install a certificate to allow the server to access itself?

Donald Nong commented Apr 02 '15, 5:34 a.m.

You need to make it very clear, not using the term "RTC server", as no one knows whether you are talking about IHS, WAS or something else. Since the public URI uses the port 443, which is the IHS HTTPS port in this case, all CLM requests have to go through IHS, regardless the requests are initiated from a browser or WAS. Applications such as CCM running on WAS do not magically know to use port 9443 (WAS is not necessarily listening at 9443).
I don't really know how to import the certificate in this case since I have never work with "client certificate" before. In particular, you need to configure WAS so that it will send out a client certificate when connecting to IHS. Usually it's the other way round - IHS connects to WAS and WAS sends out a server certificate to IHS.
If you don't what to struggle with client certificates, you can check out the below document and configure IHS to not use client certificate on, and then map the host in the public URI to

Your answer

Register or to post your answer.