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 />
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
Tomcat
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.
-wc
William Crighton
Capital City Consultants
Hi, please help I also have the same issue, Jira redirects from HTTP to HTTPS but now the problem is that I also want to change the url eg: gugu.example.com to helpdesk.example.com.
how do I do that?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
With the date of the inquiry probably this has been answered. But just in case for others who might face the same inquiry, do a subject alternative name in the SSL. This can be set during the CSR creation to put -ext SAN=dns:gugu.example.com in this command:
keytool -certreq -keyalg RSA -alias tomcat -file myconfluence.csr -keystore C:\Users\Joan\.keystore -ext SAN=dns:helpdesk.example.com
Where in Alias - is any name that you can set and use for importing of the certificate
.CSR - filename that you can also set to easy reference the CSR file to the domain
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
hi daniel, How u generated your file.jks? Can you plese send me the screenshot on my email id "nikhilrote05@gmail.com".
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.