Route Jenkins SSL Traffic Via an Apache Proxy Server


How to Route Jenkins HTTP Requests Through Apache

Mapping SSL traffic destined for Jenkins via an Apache proxy server is a continuation of Routing Jenkins HTTP Requests Through Apache.


Jenkins 2 Admin Password Requires SSL

Using Apache to Reverse Proxy Jenkins HTTP Requests

If your Jenkins server is out in the big wide internet, it needs protection. Jenkins 2 brings administrator passwords – if you use plain HTTP your passwords will be visible to someone who hasn’t got your best interests at heart.

In Jenkin’s “global security” the option anyone can do anything is for in-house (behind firewall) deployments.

The Most Common (Web-Facing) Jenkins Configuration

The most common configuration ( like the Build Business Websites Jenkins CI Server ) is read access for anonymous and write access for in-house and customer accounts.

So the next step is to configure HTTPS (SSL) with Jenkins behind Apache. That is the 3rd Jenkins configuration, our journey has taken in the first two.

1. We did not want http://your-domain.com:8080/
2. So we put Jenkins behind Apache http://your-domain.com/jenkins
3. And add HTTPS into the mix https://your-domain.com/jenkins


The need to setup HTTPS (SSL) is covered here.

How to Configure HTTPS (SSL) Traffic for Jenkins Via an Apache Web Server

If you’ve completed the previous configuration there is only 1 step more to get SSL traffic working through an Apache reverse proxy server.

This configuration is done in [/etc/apache2/sites-available/default-ssl.conf].


See The Unabridged default-ssl.conf File

The SSL Configuration Block

The Jenkins SSL configuration is done in this Apache file. You don’t need to configure Jenkins itself, just Apache.


	##### ######################################################### ####
	##### ========================================================= ####
	##### Configuration that hides Jenkins Behind This Apache Proxy ####
	##### ========================================================= ####
	##### ######################################################### ####

	ProxyRequests     Off
	ProxyPreserveHost On
	AllowEncodedSlashes NoDecode

	<Proxy http://localhost:8080/jenkins*>
	   Order deny,allow
	   Allow from all
	</Proxy>

	ProxyPass         /jenkins  http://localhost:8080/jenkins nocanon
	ProxyPassReverse  /jenkins  http://localhost:8080/jenkins
	ProxyPassReverse  /jenkins  http://www.build-business-websites.co.uk/jenkins

	##### ============================================================ ####

        RequestHeader set X-Forwarded-Proto "https"
	RequestHeader set X-Forwarded-Port "443"

	##### ============================================================ ####
	##### ############################################################ ####

Why Set the X Forwarded Proto Header?

If you don’t set it Jenkins will complain saying that it appears that your reverse proxy set up is broken. What does this mean?

It appears that your reverse proxy set up is broken

It means that you have HTTPS (SSL) running up to Apache but HTTP on the final leg of the journey between Apache and Jenkins (usually on the same server).

This is our preferred strategy because running SSL up to each middleware server is overly complex for very little benefit. However if you are running the middle ware server on another machine with an untrusted network in between then you should push the SSL all the way to Jenkins. If you don't - all the passwords and responses will be visible in the untrusted zone.

Set X-Forwarded-Proto to tell Jenkins (or any other middleware services like Jira, MediaWiki, Play2) that the URL from the client is indeed SSL. This allows the middleware services to set their images, css and javascript links with https. Without it (assuming you force all traffic into being SSL) the URLs always go out as http then every client request has to be bounced back and modified.

Why do none of the proxy lines say HTTPs?

Yes it seems strange that none of the lines say HTTPS – why is that?

Again it’s because the SSL(ness) stops at Apache. Like we’ve said – the effort of going the extra 9 yards probably is not worth the trouble for most standard architectures. Let us know if you disagree.

Don’t forget to swap out www.build-business-websites.co.uk for your domain name. Apart from that you need do nothing else.

Once you’ve changed default-ssl.conf – you restart Apache – and you’re done. Lights out and away you go!

Leave a Reply

Your email address will not be published. Required fields are marked *