Confluence Collaborative Editing does not work with SSL and Apache 2.4.9 or earlier
Platform Notice: Data Center Only - This article only applies to Atlassian products on the Data Center platform.
Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Summary
Atlassian applications allow the use of reverse-proxies, however Atlassian Support does not provide assistance for configuring them. Consequently, Atlassian can not guarantee providing any support for them.
If assistance with configuration is required, please raise a question on Atlassian Answers.
Problem
Confluence 6.x is configured with Apache 2.4 using SSL and Websockets as described in this guide: Securing your Atlassian applications with Apache using SSL
However, when trying to use collaborative editing, you get an error in the browser and the editor does not load.
Diagnosis
Environment
Confluence 6 or higher
Apache 2.4.9 or earlier (Not Apache 2.2, as it does not support Websockets at all)
If you are on Apache 2.2, please upgrade to the latest version of 2.4 and check if the issue persists
SSL configured in Apache and/or Tomcat level
The appropriate modules are loaded, specifically mod_proxy_wstunnel.so
Diagnostic Steps
Looking at the web requests on your browser's developer tools, we see the following:
Requests to Synchrony (e.g. https://servername.domain/synchrony/sockjs/v1/info?t=1485365) work and return a 200 OK status.
Requests to Websockets (e.g. wss://servername.domain/synchrony/sockjs/v1/808/k1g3xete/websocket) return a 404 not found error.
Confirm Apache is configured following our guides:
Check that the proxy parameters have been added to your confluence_install/conf/server.xml file: Cross Site Request Forgery (CSRF) protection changes in Atlassian REST
Confirm the following modules are all loading properly from Apache:
1 2 3 4LoadModule proxy_module /usr/lib/apache2/modules/mod_proxy.so LoadModule proxy_http_module /usr/lib/apache2/modules/mod_proxy_http.so LoadModule proxy_wstunnel_module /usr/lib/apache2/modules/mod_proxy_wstunnel.so LoadModule rewrite_module /usr/lib/apache2/modules/mod_rewrite.so
Cause
The following bug breaks the SSL handshake because it sends plain-text requests to the Websockets URL, as opposed to SSL requests: Plain-text request is sent to WSS URL (which should be over SSL) in mod_proxy_wstunnel
Solution
Workaround
Workarounds are ways to temporally circumvent a problem, although it still exists in the application.
A workaround is described in the following post from Stackoverflow: http://stackoverflow.com/a/22873747
Use a different proxy:
Resolution
Upgrade to Apache 2.4.10 or higher. For some operating systems there is a fix available that has been tested using Apache version 2.4.6-45.
Was this helpful?