Due to a bug in the Shared Access Layer, one of the libraries JIRA uses, attempts to connect over non-standard ports (such as 8443) will not work properly. This can cause AppLinks to fail when attempting to connect to JIRA as the 'Host' HTTP header is always missing the port, regardless of the actual URL.
For affected versions in JIRA, refer to this issue. This table assumes the applications are listening on different IPs/ running on different servers so they can both listen on the same port numbers.
|JIRA affected?||Port||Target affected?||Port||Can establish Application Link?|
This is a bug kept in place to track the problem in JIRA - when SAL is upgraded this problem will be resolved. Other products are kept track in the following issues:
Any Atlassian application that has not had this bug fixed will require the workaround. For example, JIRA 6.1.3 is fixed however Confluence 5.3.1 is not so the applications would not be able to communicate with each other over HTTPS ports that are anything other than 443.
Modify the remote application's server.xml to include the following arguments in the HTTPS Connector and restart the application:
Host JIRA behind a reverse-proxy, such as Apache using Integrating JIRA with Apache using SSL.
This will serve HTTPS on port 443 on Apache, however JIRA will be serving HTTP behind that proxy, effectively working around the problem. It is the recommendation of Atlassian Support to use this configuration over setting up HTTPS on Tomcat as the configuration of it is considered to be easier to achieve.
Depending upon the application(s) that are affected, running them directly on port 443 can correct the problem as per our Application Stash seems to be offline in JIRA after creating an application link to Stash KB. This is only recommended for Windows installations as root access is required for Tomcat to listen on 443 - on Linux installs and this carries a significant security risk with it (if someone hacks Tomcat they have root access to the box).