Description
When creating AppLinks between FishEye/Crucible and another Atlassian application behind a reverse proxy set up with SNI, the AppLinks won't work properly.
Because the client does not support SNI, it won't be served the right SSL certificate and the connection will failed.
This issue is caused by the commons-httpclient version (3.1) used by FishEye/Crucible, which does not have support for TLS - SNI.
Environment
Java version 1.7 or newer (starting from the java version 1.7 TLS 1.1 and 1.2 are disabled by default).
Expected results
The AppLink can be successfully created.
Actual results
It is not possible to successfully create an AppLink and the following stack trace can be found in the atlassian-fisheye-YYYY-MM-DD.log
2015-09-01 17:02:29,222 ERROR [http-bio-8085-exec-11] [CreateApplicationLinkUIResource] ManifestNotFoundException thrown while retrieving manifest com.atlassian.applinks.spi.manifest.ManifestNotFoundException: javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate) at com.atlassian.applinks.core.manifest.AppLinksManifestDownloader.download1(AppLinksManifestDownloader.java:201) at com.atlassian.applinks.core.manifest.AppLinksManifestDownloader.access$000(AppLinksManifestDownloader.java:44) at com.atlassian.applinks.core.manifest.AppLinksManifestDownloader$1$1.<init>(AppLinksManifestDownloader.java:86) at com.atlassian.applinks.core.manifest.AppLinksManifestDownloader$1.apply(AppLinksManifestDownloader.java:79) at com.atlassian.applinks.core.manifest.AppLinksManifestDownloader$1.apply(AppLinksManifestDownloader.java:76) at com.google.common.collect.ComputingConcurrentHashMap$ComputingValueReference.compute(ComputingConcurrentHashMap.java:355) at com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.compute(ComputingConcurrentHashMap.java:184) ... ...
Notes
This ticket is about the link from FishEye/Crucible to another Atlassian application.
The improvement related to the connection from JIRA to FishEye/Crucible (or any other Atlassian applications) is described here JRA-24515.
The improvement related to the connection from Bamboo to any other Atlassian applications is described here BAM-16239.
Workarounds
As this issue is fixed, please consider upgrading before applying any of the following workarounds.
The following workaround options are alternatives, please choose the best one for your case.
Workaround - option #1
Use a newer commons-httpclient jar version (you need at least version 3.1-atlassian-2) by following these steps:
- Shutdown FishEye/Crucible
- Download this commons-httpclient-3.1-atlassian-2.jar into the machine hosting FishEye/Crucible
- Backup and delete <FISHEYE_DIR>/lib/commons-httpclient-3.1.jar
- Move the file commons-httpclient-3.1-atlassian-2.jar into the directory <FISHEYE_DIR>/lib
- Restart FishEye/Crucible
Workaround - option #2
Add the following Java properties to the FishEye/Crucible JVM properties:
-Dhttps.protocols=TLSv1.1,TLSv1.2
Workaround - option #3
Connect the Atlassian applications bypassing the proxy.
You can find the instructions describing the changes required to your environment, and how to recreate the AppLinks bypassing the proxy here:
How to create an unproxied Application Link
- is related to
-
JRACLOUD-24515 JIRA should support the use of TLS - SNI
- Closed
-
JRASERVER-24515 JIRA should support the use of TLS - SNI
- Closed
-
BAM-16239 Bamboo should support the use of TLS - SNI
- Closed
- mentioned in
-
Page Loading...