Home » Web Servers » NGINX » Nginx SSL configuration guide (Ubuntu 12.04 LTS)

About Gabriel Canepa

Gabriel Canepa

Gabriel Canepa is a Linux Foundation Certified System Administrator (LFCS-1500-0576-0100) and web developer from Villa Mercedes, San Luis, Argentina. He works for a worldwide leading consumer product company and takes great pleasure in using FOSS tools to increase productivity in all areas of his daily work. When he’s not typing commands or writing code or articles, he enjoys telling bedtime stories with his wife to his two little daughters and playing with them, the great pleasure of his life.

Nginx SSL configuration guide (Ubuntu 12.04 LTS)

This article is part of our Academy Course titled Introduction to Nginx.

This course will introduce you to the magic of nginx. You will learn to install and configure nginx for a variety of software platforms and how to integrate it with Apache. Additionally, you will get involved with more advanced concepts like Load Balancing, SSL configuration and Websockets proxying. Check it out here!
 
 
 
 
 

1. Introduction

The SSL (Secure Socket Layer) protocol was created by Netscape to ensure secure transactions between web servers and browsers (using secure pages often identified with https://). The protocol uses a third party, a Certificate Authority (CA), to identify one end or both ends of the transactions. [1]

2. Adding support for SSL to Nginx

Since The Linux Documentation Project website offers a comprehensive explanation of how this procedure is performed, we will limit this tutorial to show how to set up SSL with Nginx on Ubuntu 12.04 LTS. We will need to compile Nginx with SSL support (see Fig. 1).

id="attachment_2969" align="aligncenter" width="1094"

Figure 1: Compiling Nginx with SSL support

However, the ssl module requires the OpenSSL library (see Fig. 2) to be installed on the system beforehand. We will install the libssl-dev package, which includes the said library (see Fig. 3).

Figure 2: The ssl module needs the OpenSSL library to be installed

Figure 2: The ssl module needs the OpenSSL library to be installed

Figure 3: Installing the libssl-dev package, which provides the OpenSSL library

Figure 3: Installing the libssl-dev package, which provides the OpenSSL library

3. Creating, signing, and using a certificate

  1. We will create a directory to store our public key and ssl certificate (see Fig. 4).
    Figure 4: Creating a directory to store the public key and ssl certificate

    Figure 4: Creating a directory to store the public key and ssl certificate

  2. Now let’s generate the server private key (see Fig. 5)
    Figure 5

    Figure 5

  3. Create a certificate signing request (see Fig. 6)
    Figure 6

    Figure 6

  4. Sign your certificate (see Fig. 7). Please note that this certificate will only last one day (you can modify this setting by changing the argument to the – days option).
    Figure 7: Signing your ssl certificate

    Figure 7: Signing your ssl certificate

  5. Set up the certificate. Edit the nginx.conf file (see Fig. 8). Note that even though there is a ssl directive (ssl on | off) available, it is recommended to use the ssl parameter of the listen directive instead of this directive.
Figure 8

Figure 8

It should be kept in mind that due to the HTTPS protocol limitations virtual servers should listen on different IP addresses (see Fig. 9). Refer to the nginx.conf file to perform the following modifications if needed:

Figure 9

Figure 9 [2]

Otherwise the first server’s certificate will be issued for the second site.

In order to allow to share a single IP address between multiple HTTPS servers is to use a certificate with a wildcard name, for example, *.example.org. A wildcard certificate secures all subdomains of the specified domain, but only on one level. This certificate matches www.example.org, but does not match example.org and www.sub.example.org. These two methods can also be combined. A certificate may contain exact and wildcard names in the SubjectAltName field, for example, example.org and *.example.org.

If we want to allow Subject Alternative Names (SANs) for our certificates we need to enable the following options in the file openssl.cnf file (located in /etc/ssl/openssl/):

1. Include the X509 Version 3 (RFC 2459) extension to allow an SSL certificate to specify multiple names that the certificate should match. We need the [ req ] section to read as follows (see Fig 10). This tells openssl to include the v3_req section while generating certificate requests:

Figure 10

Figure 10

2. Edit the [ v3_req ] section as follows (see Fig. 11):

Figure 11

Figure 11

Please note that whatever we put in the file openssl.cnf will appear on all certificate requests generated from this point on: if at a later date you want to generate a CSR with different SANs, you’ll need to edit this file by hand and change the DNS.x entries.

It is better to place a certificate file with several names and its private key file at the http level of configuration to inherit their single memory copy in all servers (see Fig. 12).

Figure 12: Using a certificate in two server blocks (nginxtest.com y www.nginxtest.com)

Figure 12: Using a certificate in two server blocks (nginxtest.com y www.nginxtest.com)

3. Now we can either browse to https://nginxtest.com or https://www.nginxtest.com and we’ll see the warning of a self-signed security certificate (see Fig. 13):

Figure 13: A self-signed certificate works but presents this warning screen

Figure 13: A self-signed certificate works but presents this warning screen

4. Click on “Add Exception” (see Fig. 14) and then on “Confirm Security Exception”:

Figure 14: Confirming a Security Exception

Figure 14: Confirming a Security Exception

If you get a Wrong Site message (see Fig. 15), it means that your certificate belongs to a different site, or that the necessary SANs have not been specified.

Figure 15

Figure 15

On the other hand, when the SANs have been defined correctly, they can be viewed using the browser’s built-in certificate viewer (see Fig. 16).

Figure 16: Subject Alternative Names

Figure 16: Subject Alternative Names

or using (see Fig. 17)

openssl req –text –noout –in server.csr from the command line 
Figure 17

Figure 17

As we mentioned earlier, a certificate will only be valid within the time frame that was specified when it was first created (1 day, in our case, refer to Figs. 18a, 18b, and 18c)

Figure 18a

Figure 18a

Figure 18b

Figure 18b

Figure 18c

Figure 18c

Once that period of time is over, the certificate will expire (see Fig. 19).

Figure 19: The SSL certificate expired

Figure 19: The SSL certificate expired

Unless you have a certificate from a trusted third party, your users will get the same warning as above in Fig. 13. Aside from the fact that it looks unprofessional, it’s also a real risk due to the fact that in a large organization, it is not likely that all users will know the difference between a legitimate key generated by your IT department, and keys generated by a malicious third party. In this case, you need to buy a certificate from a trusted third party, such as GeoTrust (used by Google), Digicert, Comodo, Thawte, or VeriSign (used by Facebook, for example). For other cases, especially when you want to use https for your own use (i.e. securing your admin panel), a self-signed certificate will do just fine.

4. Download the files

Here you can download the configuration files used in this tutorial: ConfigFile.zip

Also you can download a usefull pdf file: Openssl.pdf

[1]: The Linux Documentation Project
[2]: Image source: Nginx Wiki
Do you want to know how to develop your skillset to become a sysadmin Rockstar?
Subscribe to our newsletter to start Rocking right now!
To get you started we give you our best selling eBooks for FREE!
1. Introduction to NGINX
2. Apache HTTP Server Cookbook
3. VirtualBox Essentials
4. Nagios Monitoring Cookbook
5. Linux BASH Programming Cookbook
6. Postgresql Database Tutorial
and many more ....
Email address:

Leave a Reply

Be the First to Comment!

Notify of
avatar
wpDiscuz