what ports do jira application links need/use

[Bryan Karsh]

Hi,

I have 2 tomcat boxes, each hosting a jira instance, behind a firewall. A reverse proxy in our DMZ terminates SSL at proxy level. I can access each jira instance just fine. However, the application links aren't working -- the 2 tomcats don't see each other.

I've asked some other questions in this forum, but I am starting to suspect that my issue may be firewall related.

Can someone tell me:

1. which ports are needed for application links to talk with each other? Right now my 2 tomcat boxes can only see each other on port 8080. The proxy can only see them on port 8080 as well. Do I need to open up 8443, 8009, 443, etc., and if so, between which boxes? This wasn't an issue when I had a proxy behind the firewall, and when I was not using ssl...

2. If the issue is certificate-related, rather than fire-wall related, do I need to copy the proxy public cert to the keystore of each tomcat box? Or both tomcats to each other (currently they have no ssl), both, or...?

[Andy Brook [Plugin People] · Accepted solution]

1) I'm pretty sure that appllinks will not use any other port that the prescribed port included in the 'baseurl' of the application.

If both JIRA's are fronted by SSL terminating proxies, their external 'address' (their baseurl) in each, should point to that SSL host right, so no other ports other than the default 443 should be needed, meaning:

:443 from JIRA1 to SSL terminating proxy fronting JIRA2, from from JIRA2 to SSL terminating proxy fronting JIRA1.

2) Yep, if your issue link url is SSL based (should be), then JIRA1's local Tomcat JRE will need to have JIRA2's (SSL proxy?) CA chain, refe to https://confluence.atlassian.com/display/JIRA/Running+JIRA+over+SSL+or+HTTPS to get the required certs installed.

To prove you can connect, lookout for SSLPoke, a trivial java app to create a socket to a remote SSL server, if it works, then your JRE is setup correctly, its easy then to test bi-directional socket connectivity without any direct JIRA changes.

[Bryan Karsh]

I am adding an addendum answer as well. Part of my problem was that I was using an externally facing IP, a proxy in the DMZ, and internal tomcats.

To get my reverse proxy to finally work (after verifying all ports were up), was to update the /etc/hosts file on both tomcat machines, so that the external ip *name* resolved to the proxy's internal ip. Otherwise, the internal tomcats couldn't resolve the name of the external ip (which was appearing due to reverse proxy), and not implementing correctly in application links.