Apache HTTPS代理重定向背后的Jira

Question

I have a jira server setup using tomcat and apache. When I type in the url jira.example.com it brings me to https://jira.example.com//secure/Dashboard.jspa and I get dashboard errors because of the url. If I type in jira.example.com:8080 it brings me to the correct url. http://jira.example.com:8080/secure/Dashboard.jspa Any ideas where the issue might be?

<IfModule mod_proxy.c>
ProxyRequests On

<VirtualHost *:80>
        ServerName jira.example.com
        ServerAlias jira jira.c11.example.com
        ProxyPreserveHost On
        ProxyRequests Off
        ProxyPass / http://localhost:8080/
        ProxyPassReverse / http://localhost:8080/
        ProxyTimeout 60
        RewriteEngine On
        RewriteCond %{SERVER_PORT} 80
        RewriteRule ^(.*)$ https://jira.example.com/$1 [R,L]
        ErrorLog /var/log/httpd/jira.example.com-error_log
        CustomLog /var/log/httpd/jira.example.com-access_log combined
</VirtualHost>

<VirtualHost *:443>
   ServerName jira.example.com
   ServerAlias jira jira.c11.example.com
     ServerSignature On
     SSLEngine on
     SSLCertificateFile    /etc/httpd/conf/ssl.crt/star.example.com.crt
     SSLCertificateKeyFile /etc/httpd/conf/ssl.key/star.example.com.key
     SSLCertificateChainFile /etc/httpd/conf/ssl.crt/thawte_chain_bundle.crt
     SetEnvIf User-Agent .*MSIE.* nokeepalive ssl-unclean-shutdown
    ErrorLog /var/log/httpd/ssl-jira.example.com-error_log
    CustomLog /var/log/httpd/ssl-jira.example.com-access_log combined
    SSLProxyEngine on
    <Proxy *>
            Order deny,allow
            Allow from all
            #Allow from .your_domain.com
    </Proxy>

    ProxyRequests       Off
    ProxyPreserveHost   On


ProxyPass              /       http://localhost:8080/
ProxyPassReverse       /       http://localhost:8080/

Answer 1

In your primary virtualhost you have a rewrite condition to redirect non ssl traffic to https:

RewriteCond %{SERVER_PORT} 80
        RewriteRule ^(.*)$ https://jira.example.com/$1 [R,L]

Removing this would remove the redirect.

Answer 2

I was facing this issue moments ago.

The base url was set properly in Jira but I still had the message about it being not the same than the one used to access the interface.

The problem was that I did not set a Tomcat connector with the proxy parameters. Adding the following connector solved my problem (with a jira restart of course)

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

   <!-- This is the important part -->
   proxyName="jira.mybuisness.com" proxyPort="443" scheme="https"/>

This is the very only modification made to Jira's installation, all the other config related to the https proxy is handled by apache.

---

Here is the relevant apache config with mod_ssl mod_proxy mod_proxy_http and mod_proxy_connect enabled.

<VirtualHost 192.168.5.143:443>
    ServerName          https://jira.mybuisness.com

    # SSLEngine is not specified in jira's documentation but was necessary for me
    SSLEngine               On
    SSLProxyEngine          On
    SSLCertificateFile      /path/to/my/certificate/cacert_https.pem
    SSLCertificateKeyFile   /path/to/private/privkey_https.pem

    ProxyRequests           Off
    ProxyPreserveHost       On
    ProxyPass               /       http://myjiraserver:8081/
    ProxyPassReverse        /       http://myjiraserver:8081/

    <Proxy *>
        Order deny,allow
        Allow from all
    </Proxy>

    ErrorLog "logs/jira-error.log"
    CustomLog "logs/jira-access.log" common
</VirtualHost>

<VirtualHost 192.168.5.143:80>  
    ErrorLog "logs/jira-error.log"
    CustomLog "logs/jira-access.log" common

    ServerName          superjiratest.mybuisness.com
    Redirect permanent  /   https://jira.mybuisness.com/
</VirtualHost>

I was using self-signed keys as this was a test setup but it's pretty much the same with validated paid keys.

I hope this will help someone, I lost quite a lot of time on that. I guess that OP already found a solution after almost a year.