It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Redirecting non-SSL port 8090 to SSL port 8443 Edited


We have recently upgraded our Confluence to run encrypted by means of a Let's Encrypt certificate, however there is a small issue that I would like to see resolved.

We have a few old links going to pages like, however the browser will then give me the following error: SSL_ERROR_RX_RECORD_TOO_LONG. The page can be manually accessed by changing 8090 to 8443, but I would like it to reroute to 8443 automatically.

According to step 5 of this guide, I need to add some constraints to my web.xml file, which I have done, but it does not seem to work.

According to other sources on the web, I should add SSLEnabled="true" to the 8090 port, however this is counter intuitive in my opinion because the guide states that it will route all non-SSL links to 8443. If I enable SSL for the 8090, it wouldn't route to 8443, right?

Any suggestions?

My server.xml file is as follows:

<Server port="8000" shutdown="SHUTDOWN" debug="0">
    <Service name="Tomcat-Standalone">
        <Connector port="8090" connectionTimeout="20000" redirectPort="8443"
                maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
                enableLookups="false" acceptCount="100" debug="0" URIEncoding="UTF-8"
                protocol="org.apache.coyote.http11.Http11NioProtocol" />

        <Engine name="Standalone" defaultHost="localhost" debug="0">

            <Host name="localhost" debug="0" appBase="webapps" unpackWARs="true" autoDeploy="false" startStopThreads="4">
                <Context path="" docBase="../confluence" debug="0" reloadable="false" useHttpOnly="true">
                    <!-- Logger is deprecated in Tomcat 5.5. Logging configuration for Confluence is specified in confluence/WEB-INF/classes/ -->
                    <Manager pathname="" />
                    <Valve className="org.apache.catalina.valves.StuckThreadDetectionValve" threshold="60" />

                <Context path="${confluence.context.path}/synchrony-proxy" docBase="../synchrony-proxy" debug="0" reloadable="false" useHttpOnly="true">
                    <Valve className="org.apache.catalina.valves.StuckThreadDetectionValve" threshold="60" />

<Connector port="8443" maxHttpHeaderSize="8192"
        maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
        enableLookups="false" disableUploadTimeout="true"
        acceptCount="100" scheme="https" secure="true"
        clientAuth="false" sslProtocol="TLS" SSLEnabled="true"
        URIEncoding="UTF-8" keystoreFile="..."



2 answers

You can handle all the old ports too.

In apache, you'd listen and set up virtualhosts and redirects for each of your old ports. Confluence would need to listen on an off port, let's say 8092 for Confluence and leave Synchrony on 8091.

apache httpd.conf

<VirtualHost *:80>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*){REQUEST_URI} [NE]

<VirtualHost *:8443>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*){REQUEST_URI} [NE]

<VirtualHost *:8090>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*){REQUEST_URI} [NE]


<VirtualHost *:443>

ProxyRequests Off

<Proxy *>
Require all granted

ProxyPass / http://localhost:8092/
ProxyPassReverse / http://localhost:8092/

SSLEngine On
SSLCertificateFile /path/to/your/cert.pem
SSLCertificateKeyFile /path/to/your/privkey.pem
SSLCertificateChainFile /path/to/your/chain.pem

<Location />
Require all granted

ProxyPass /synchrony http://localhost:8091/synchrony

<Location /synchrony>
Require all granted
RewriteEngine on
RewriteCond %{HTTP:UPGRADE} ^WebSocket$ [NC]
RewriteCond %{HTTP:CONNECTION} Upgrade$ [NC]
RewriteRule .* ws://localhost:8091%{REQUEST_URI} [P]



Server.xml (connector only):

<Connector port="8092" connectionTimeout="20000" redirectPort="8443"
maxThreads="48" minSpareThreads="10"
enableLookups="false" acceptCount="10" debug="0" URIEncoding="UTF-8"
proxyName="" proxyPort="443" scheme="https" />

Thank you for your detailed reply! We do not use Apache right now and it looks fairly complicated for what I want to solve right now. However, I did find UrlRewriteFilter for TomCat, Apache's mod_rewrite. Looks like it could work, what do you think?

You could rewrite and redirect using tomcat. Those changes would have to be re-applied every time you upgrade, so concider using nginx instead.

My recommendation is to use apache or nginx for the purpose, but why expose port numbers to your users at all?!

You should configure a simple URl like or



We redirect to right now with nginx and that works fine. However like I said, we have old links running directly to and I do not quite get how to redirect those to 8443. Are you suggesting nginx for this purpose as well?

Make nxinx listen on 8090 (and remove 8090 from tomcat), then redirect users to where you want them with nginx.

Why redirect users to a "clean" URL without port numbers are much better in my mind.


Thanks for your help Lars, however it's a little more complicated than I may have described. The problem is that there is more than one link with this problem, let's say 50. That's not possible with nginx as far as I know?

As for the link, I agree with you. Is there a guide that you can recommend? I don't want to use port 80 for this, but it's probably possible to hide the port number, right?

Look at Josh`s answer. :)

Suggest an answer

Log in or Sign up to answer
This widget could not be displayed.
This widget could not be displayed.
Community showcase
Published Thursday in Confluence

Confluence CVEs and common questions

Two vulnerabilities have been published for Confluence Server and Data Center recently: March 20, 2019 CVE-2019-3395 / CVE-2019-3396 April 17, 2019 CVE-2019-3398 The goal of this article is...

302 views 0 12
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you