In this post, we feature a comprehensive Nginx SSL configuration guide. 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!
Table Of Contents
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. 
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).
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).
- We will create a directory to store our public key and ssl certificate (see Fig. 4).
- Now let’s generate the server private key (see Fig. 5)
- Create a certificate signing request (see Fig. 6)
- 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 –
- 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.
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: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,
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:
2. Edit the
[ v3_req ] section as follows (see Fig. 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).
4. Click on “Add Exception” (see Fig. 14) and then on “Confirm 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.
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).
or using (see Fig. 17)
openssl req –text –noout –in server.csr from the command line
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)
Once that period of time is over, the certificate will expire (see Fig. 19).
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.
Here you can download the Nginx SSL configuration guide files used in this tutorial: ConfigFile.zip
Also you can download a usefull pdf file: Openssl.pdf
|: The Linux Documentation Project|
|: Image source: Nginx Wiki|