Jira dosen't redirect properly to HTTPS

Daniel Nielsen2

JIRA does not redirect to HTTPS properly. Whilst it works, if you use the default port and HTTP, it does not work if you initilize it on the correct port but with HTTP instead of HTTPS.

So http://localhost:8100 redirects to https://localhost:8443, but http://localhost:8443 does not redirect to https://localhost:8443

Instead, it downloads a file with the content: "1503 0300 0202 0a".

 

Any way I can make it redirect properly from HTTP to HTTPS, if access on the same port?

 

server.xml

<Connector port="8100"
                   maxThreads="150"
                   minSpareThreads="25"
                   connectionTimeout="20000"
                   enableLookups="false"
                   maxHttpHeaderSize="8192"
                   protocol="HTTP/1.1"
                   useBodyEncodingForURI="true"
                   redirectPort="8443"
                   acceptCount="100"
                   disableUploadTimeout="true"/>


 
 
<Connector port="8443" protocol="org.apache.coyote.http11.Http11Protocol"
              maxHttpHeaderSize="8192" SSLEnabled="true"
              maxThreads="150" minSpareThreads="25"
              enableLookups="false" disableUploadTimeout="true"
              acceptCount="100" scheme="https" secure="true"
              clientAuth="false" sslProtocol="TLS" useBodyEncodingForURI="true"
              keyAlias="jira" keystoreFile="file.jks" keystorePass="password" keystoreType="JKS />

 

 

 

William Crighton _CCC_

 

JIRA has no built in functionality for redirecting HTTP (typically on port 80) traffic to HTTPS (typically on port 443).

When we setup JIRA for a client on Linux we always 'front' JIRA with Apache letting Apache handle the SSL encrypt/decrypt and provide URL's that don't contain port numbers.

This does result in a system where the traffic is not encrypted all the way to the JIRA application - the traffic from Apache to Tomcat/Catalina is not typically encrypted - if both apps are running on the same system general consensus has it that any 'intruders' would already have control of the systems anyway so it wouldn't make much difference for the final segment to be encrypted.

By fronting with Apache you don't have to screw around (much) with Tomcat and SSL certificates, which is a PITA. And if you use mod_jk to handle the communication between Apache and Tomcat then you'll get a sweet performance boost and binary instead of plain text traffic between Apache and Tomcat.

The configuration points that you'll need to be spending most your time with are the following:

Apache

• virtual host definition
• SSL definition/implementation
• mod_jk config and the Tomcat Handoff

Tomcat

• connector descriptor that accepts binary traffic from Apache and delivers it to the JIRA Application in server.xml

 

What you had provided in your question had you loading up Tomcat with a public/private keypair created as part of a  JAVA keystore file. I really hate dealing with these because it's harder to renew your certificates and prevents you from re-using certificates (such as wildcard certs) across multiple applications.

One thing to be aware of if you don't know this already - on Linux only the root user can bind an application to a port under 1024. Which for Tomcat, not having a 'wrapper' like Apache which starts up as root to do the port bind and then su's to a restricted user to manage the process, this means that it'll need to be listening out in the ports above 1024.

The apache config will look like the following, and the Tomcat side is shown below that.

Apache Config

• HTTP Virtual Host
  

<VirtualHost IPADDR:80>
...virtual host stuff...
   # – redirect everything that comes in on 80 to the encrypted HTTPS port
   RedirectPermanent / "https://jira.<domain.com>/"
....virtual host logging stuff...

</VirtualHost>

• HTTPS Virtual Host
  

<VirtualHost IPADDR:443>
...virtual host stuff...
    SSLEngine on
    SSLProxyEngine on
    ProxyPreserveHost on
    ProxyPass / ajp://<ip address of jira host>:<port tomcat connector listens on>/
    ProxyPassReverse / ajp://<ip address of jira host>:<port tomcat connector listens on>/
    # -- we like to have our SSL cert config information kept in files separate from the vhost descriptor
    Include "/etc/apache2/ssl.certs/domain-ssl-intel.conf"
....virtual host logging stuff...
</VirtualHost>

•  SSL Cert Config Information

SSLProxyCheckPeerCN off
SSLCertificateFile /etc/apache2/ssl.certs/<domain>/ssl.crt/<cert signed public key file>.crt
SSLCertificateKeyFile /etc/apache2/ssl.certs/<domain>/ssl.key/<cert key file>.key
SSLCertificateChainFile /etc/apache2/ssl.certs/<domain>/ssl.crt/<cert-chain-file>.crt
SSLProtocol +SSLv3 +TLSv1 +TLSv1.1 +TLSv1.2

 

Tomcat Config

• This is typically done by modifying your server.xml file in the tomcat install directory conf

<Connector 
            port="<port entered into apache vhost config>" 
            redirectPort="8443" 
            enableLookups="false" 
            protocol="AJP/1.3" 
            URIEncoding="UTF-8"

            maxThreads="100"
            minSpareThreads="10"
            connectionTimeout="60000"

            pollTime="4000"    
            pollerSize="8192"

            disableUploadTimeout="true"
            acceptCount="100" 
            secure="true"
            useBodyEncodingForURI="true"
            
            proxyName="<jira DNS name associated with apache SSL cert file>"
            scheme="https"
            proxyPort="<https port being used by apache that's sending all traffic to this connector>"
        />

 

---

well, that's a lot of answer for you. It's not 100% complete with me having left out huge chunks of knowledge relating to virtual hosts, among other things. However you could use the information to resolve your issue.

Atlassian maintains several pages describing how to do this with all the detail you can want. I'll get this answer posted then find the page and add it as a comment.

-wc

William Crighton

Capital City Consultants