Confluence Collaborative Editing does not work with SSL and Apache 2.4.9 or earlier
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.
Platform Notice: Server and Data Center Only - This article only applies to Atlassian products on the server and data center platforms.
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.
- 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
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:
LoadModule 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
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
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:
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.