By default, Jenkins comes with its own built in web server, which listens on port 8080. This is convenient if you run a private Jenkins instance, or if you just need to get something up quickly and don’t care about security. Once you have real production data going to your host, though, it’s a good idea to use a more secure web server like Nginx.
This post will detail how to wrap your site with SSL using the Nginx web server as a reverse proxy for your Jenkins instance. This tutorial assumes some familiarity with Linux commands, a working Jenkins installation, and a Ubuntu 14.04 installation.
You can install Jenkins later in this tutorial, if you don’t have it installed yet.
Step One — Configure Nginx
Nginx has become a favored web server for its speed and flexibility in recents years, so that is the web server we will be using.
The commands in this section assume that you have a user set up with sudo access.
Update your package lists and install Nginx:
It’s not crucial, but you may want to check Nginx’s version in case you need to do any troubleshooting down the road. Newer versions of Nginx provide a few more features as well.
Get a Certificate
Next, you will need to purchase or create an SSL certificate. These commands are for a self-signed certificate, but you should get an officially signed certificate if you want to avoid browser warnings.
Move into the proper directory and generate a certificate:
You will be prompted to enter some information about the certificate. You can fill this out however you’d like; just be aware the information will be visible in the certificate properties. We’ve set the number of bits to 2048 since that’s the minimum needed to get it signed by a CA. If you want to get the certificate signed, you will need to create a CSR.
Edit the Configuration
Next you will need to edit the default Nginx configuration file.
Here is what the final config might look like; the sections are broken down and briefly explained below. You can update or replace the existing config file, although you may want to make a quick copy first.
In our configuration, the cert.crt and cert.key settings reflect the location where we created our SSL certificate. You will need to update the servername and `proxyredirect` lines with your own domain name. There is some additional Nginx magic going on as well that tells requests to be read by Nginx and rewritten on the response side to ensure the reverse proxy is working.
The first section tells the Nginx server to listen to any requests that come in on port 80 (default HTTP) and redirect them to HTTPS.
Next we have the SSL settings. This is a good set of defaults but can definitely be expanded on. For more explanation, please read this tutorial.
The final section is where the proxying happens. It basically takes any incoming requests and proxies them to the Jenkins instance that is bound/listening to port 8080 on the local network interface. This is a slightly different situation, but this tutorial has some good information about the Nginx proxy settings.
A few quick things to point out here. If you don’t have a domain name that resolves to your Jenkins server, then the proxy_redirect statement above won’t function correctly without modification, so keep that in mind. Also, if you misconfigure the proxy_pass (by adding a trailing slash for example), you will get something similar to the following in your Jenkins Configuration page.
So, if you see this error, double-check your proxy_pass and proxy_redirect settings in the Nginx configuration!
Step Two — Configure Jenkins
As stated previously, this tutorial assumes that Jenkins is already installed. This tutorial will show you how to install Jenkins if necessary. You will probably need to switch to the root user for that article.
For Jenkins to work with Nginx, we need to update the Jenkins config to listen only on the localhost interface instead of all (0.0.0.0), to ensure traffic gets handled properly. This is an important step because if Jenkins is still listening on all interfaces, then it will still potentially be accessible via its original port (8080). We will modify the /etc/default/jenkins configuration file to make these adjustments.
Locate the JENKINS\_ARGS line and update it to look like the folowing:
Notice that the httpListenAddress=127.0.0.1 setting needs to be either added or modified.
Then go ahead and restart Jenkins and Nginx.
You should now be able to visit your domain using either HTTP or HTTPS, and the Jenkins site will be served securely. You will see a certificate warning if you used a self-signed certificate.
Optional — Update OAuth URLs
If you are using the GitHub or another OAuth plugin for authentication, it will probably be broken at this point. For example, when attempting to visit the URL, you will get a “Failed to open page” with a URL similar to the following:
To fix this you will need to update a few settings, including your OAuth plugin settings. First update the Jenkins URL (in the Jenkins GUI); it can be found here:
Jenkins — Manage Jenkins — Configure System — Jenkins Location
Update the Jenkins URL to use HTTPS — https:// jenkins.domain.com/
Next, update your OAuth settings with the external provider. This example is for GitHub. On GitHub, this can be found under Settings — Applications — Developer applications, on the GitHub site.
There should be an entry for Jenkins. Update the Homepage URL and Authorization callback URL to reflect the HTTPS settings. It might look similar to the following:
The only thing left to do is verify that everything worked correctly. As mentioned above, you should now be able to browse to your newly configured URL — jenkins.domain.com — over either HTTP or HTTPS. You should be redirected to the secure site, and should see some site information, including your newly updated SSL settings. As noted previously, if you are not using hostnames via DNS, then your redirection may not work as desired. In that case, you will need to modify the proxy_pass section in the Nginx config file.
You may also want to use your browser to examine your certificate. You should be able to click the lock to look at the certificate properties from within your browser.