Confluence incorrectly using HTTP protocol to reach synchrony-proxy during healthcheck when running over SSL

Problem summary

When Confluence's server.xml is configured to run over SSL, the healthcheck URL continues to use the HTTP protocol to reach synchrony-proxy, which causes a failure as the request should be over HTTPS.

Steps to reproduce

Install Confluence 6.0.2 to run over SSL (e.g. port 8443) at the Tomcat level (no external proxy involved). Self-signed cert is ok as long as it is imported into the Java trust store that Confluence is using.

After startup, observe the following repeated in logs:

2016-12-13 17:28:52,918 WARN [synchrony-interop-executor:thread-1] [plugins.synchrony.bootstrap.DefaultSynchronyProxyMonitor] pollHealthcheck Could not ping the synchrony-proxy [http://localhost:8443/synchrony-proxy/healthcheck]: 
org.apache.http.NoHttpResponseException: The target server failed to respond

Healthcheck URL should be https://localhost:8443/synchrony-proxy/healthcheck (HTTPS) rather than plain HTTP.

Workaround

1. Enable the standard HTTP connector port in the server.xml file, for example:

<Connector port="8090" connectionTimeout="20000" redirectPort="8443"
                maxThreads="48" minSpareThreads="10"
                enableLookups="false" acceptCount="10" debug="0" URIEncoding="UTF-8"
                protocol="org.apache.coyote.http11.Http11NioProtocol"/>

2. Disable the healthcheck request by setting a system property synchrony.proxy.healthcheck.disabled to true (in setenv.sh or setenv.bat) in Confluence 6.1.0 (when it's released). For example:

CATALINA_OPTS="-Dsynchrony.proxy.healthcheck.disabled=true ${CATALINA_OPTS}"

If you are running Confluence as a Windows Service, access the Java Options and add this line:

-Dsynchrony.proxy.healthcheck.disabled=true

The 1st workaround is already included in our documentation as below:

• Troubleshooting collaborative editing
• Running Confluence Over SSL or HTTPS

The 2nd workaround will be added in the same documentation when 6.1 is released. This ticket will now be resolved since the workarounds have been provided.