Jenkins does not redirect to HTTPS

Question

The problem

I am using Jenkins over HTTPS/SSL (the details of setup below). I can navigate to https://jenkins.mydomain.com:8088 without any problems. All links are correct with https:// in front of them. I can properly navigate through almost all Jenkins pages.

Except when Jenkins tries to redirect (e.g after login, after clicking Build, etc). Whenever Jenkins tries to redirect to any page, it sends me to http:// page (not httpS://)

What I've tried

• I have tried setting setting Jenkins URL in global configuration. It works fine for everything, except that it always redirects to http://, despite the URL saying httpS://
• I have tried following instructions here regarding modifying jenkins.xml with port configuration, however as my setup is not using Jenkins Windows service install, I simply don't have jenkins.xml Is there a different place I can specify the parameters to Jenkins?
• I have tried understanding whatever "mod_proxy with HTTPS" means, but I don't have any virtual hosts configuration. And besides, my Tomcat installation is not the one that handles SSL. The issue seems to be only in Jenkins's redirect mechanism, which is ignoring Jenkins URL protocol part from Global Configuration.

The Jenkins setup

• Apache Tomcat running as Windows service
  1. Jenkins.war renamed to ROOT.war is placed in Tomcat's webapps folder
  2. Executing through bin\tomcat6.exe //RS//Instance_Name
  3. Configured through Tomcat's Windows "Monitor Service" tool
• There are multiple instances configured this way on this machine, differentiated by different Tomcat folders and different Tomcat ports under respective conf\server.xml
• I've inherited this setup. Don't know why they didn't use the native install package with Windows service. There are multiple instances of Jenkins (through multiple instances of Tomcat service) on this computer. Trying to change the installation type for all those instances will incur unacceptable amount of downtime.
• Jenkins' port 8088, cannot use 443 for SSL as there are multiple instances running and they can't all have 443 as the only way Instances are differentiated is by port.

The SSL setup

• We have a global SSL cert (*.mydomain.com) that is hosted on a load balancer hardware. (I don't have access to actual file)
• There is no SSL on actual Windows server hosting Jenkins.
• The DNS for jenkins.mydomain.com resolves to a virtual IP on the load-balancer, which then forwards to traffic to actual Windows server hosting Jenkins.
• There is nothing wrong with this setup, it works fine for all other sites. This SSL setup also works fine for our Jenkins instance.

Solution

I suggest peeking around the server.xml and finding the Connector and adding secure="true" if you are doing an HTTP proxy scheme. Redirect ports may also be involved.

<Connector secure="true" port="8088" protocol="HTTP/1.1" URIEncoding="UTF-8"
           connectionTimeout="20000"
            />

For reference, We run Jenkins behind 2 Apache proxies, one external and one internal:

The relevant parts of our external vhost (jenkins.host.com):

    RequestHeader unset Authorization
    RequestHeader set Authorization "Basic (encrypted password)"
    ProxyPass / ajp://dev.internal:9101/
    ProxyPassReverse / ajp://dev.internal:9101/

The relevant parts of tomcat's server.xml:

<Connector port="9001" protocol="HTTP/1.1" URIEncoding="UTF-8"
           connectionTimeout="20000"
            />

<Connector port="9101" protocol="AJP/1.3" URIEncoding="UTF-8"/>

<Host name="dev.internal" appBase="webapps"
        unpackWARs="true" autoDeploy="true">
       <Alias>jenkins.host.com</Alias>

    <!-- SingleSignOn valve, share authentication between web applications
         Documentation at: /docs/config/valve.html -->
    <!--
    <Valve className="org.apache.catalina.authenticator.SingleSignOn" />
    -->

    <!-- Access log processes all example.
         Documentation at: /docs/config/valve.html
         Note: The pattern used is equivalent to using pattern="common" -->
    <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
           prefix="dev.internal_access_log." suffix=".txt" rotatable="false"
           pattern="%h %l %u %t &quot;%r&quot; %s %b" />

  </Host>

Comments

[user2782001]

Very long time ago, but can you remember if you solved this? For me all the internal links redirect properly, but the login and the logout always redirect to http instead of https

[Slav]

@user2782001 I think I gave up on that

[Slav]

I was hopeful, but restart did not help. Plus like I mentioned, it does store and retain the domain portion... just not the https part

[Slav]

Enabling secure connector did not help. Like I tried to explain, the issue is not in configuring the webserver (Tomcat), as the server hosting Jenkins does not even have the SSL cert and by itself cannot work over SSL with no cert. It's something on Jenkins' configuration...

[Misha Brukman]

Sorry to hear that, but try the Tomcat URL rewriter. It may not the ideal solution (feels more like duct tape), but it would prevent any access over HTTP to Jenkins, which is something you would want even if the HTTPS solution worked.

[Slav]

Maybe I am being stupid here, but how can I setup any kind of HTTPS on the server if I don't have access to a certificate file?

[Misha Brukman]

Sorry if I'm not being clear. I'm assuming that the Tomcat URL rewriter will rewrite http:// URLs into https:// URLs and send a 302 redirect back to the client, as is mentioned on their home page, thus forcing the client's browser to (re-)load the same host:port/path but with an HTTPS connection. This (new) request will then hit the loadbalancer which does have your SSL certificate, so it should work as if the user typed https://host:port/path manually. Essentially, this makes Tomcat prevent any access to your Jenkins servers via HTTP.

[Misha Brukman]

I think I see your point and my mistake: Tomcat and Jenkins will never see the https:// URL because the SSL connection is terminated by the loadbalancer (which is the only one that has the certificate) and the connection from loadbalancer to Tomcat is always HTTP, so my suggestion is not feasible. You'll have to do the URL rewriting at the loadbalancer instead, if that's feasible.

[Misha Brukman]

@Slav, did you have any luck in getting to work? BTW, I'd like to offer that we clean up this discussion and the answer by removing unnecessary comments. I've updated the answer to say that the URL rewriting needs to happen on the loadbalancer, not Tomcat. We can now delete our respective comments except for your first comment on this answer, and I can drop the "edit" paragraph. Thoughts?