-
Bug
-
Resolution: Fixed
-
Medium
-
6.0, 6.0.1/OD-15, 6.0.2, 6.0.3, 6.0.4, 6.0.5, 6.0.6, 6.0.7, 6.1, 6.1.1
-
None
-
6
-
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.
Example scenarios
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? |
---|---|---|---|---|
8443 | 443 | |||
8443 | 8443 | |||
443 | 443 | |||
443 | 443 | |||
443 | 8443 | |||
8443 | 8443 | |||
443 | 8443 | |||
443 | 443 |
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:
- Stash:
STASH-3777 - Bamboo:
BAM-13987 - Confluence:
CONF-31627
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.
Workaround 1 - altering server.xml
Modify the remote application's server.xml to include the following arguments in the HTTPS Connector and restart the application:
proxyName="remote application server name" proxyPort="remote application SSL port (e.g. 8443)"
Workaround 2 - using a Reverse Proxy
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.
Workaround 3 - using Tomcat
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).
- relates to
-
CONFSERVER-31627 Confluence cannot connect to JIRA on non-standard HTTPS port
- Closed
-
BAM-13987 Bamboo cannot connect to other Atlassian applications on non-default HTTPS port
- Closed
-
BSERV-3777 Stash cannot connect to other Atlassian applications on non-standard HTTPS port
- Closed
-
FE-4960 Fisheye cannot connect to other Atlassian applications on non-default HTTPS port
- Closed
-
BDEV-3773 Loading...
- is caused by
-
SAL-233 Loading...
- mentioned in
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Wiki Page Loading...
-
Wiki Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Wiki Page Loading...