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.
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?
<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 />
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:
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.
<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>
<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>
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
<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.
Capital City Consultants
I have multiple projects that use variations of the same base workflow. The variations depend on the requirements of the project or issue type. The variations mostly come in the form of new statuses ...
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!
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