This article covers a version of Ubuntu that is no longer supported. If you are currently operate a server running Ubuntu 12.04, we highly recommend upgrading or migrating to a supported version of Ubuntu:
Reason: Ubuntu 12.04 reached end of life (EOL) on April 28, 2017 and no longer receives security patches or updates. This guide is no longer maintained.
See Instead:
This guide might still be useful as a reference, but may not work on other Ubuntu releases. If available, we strongly recommend using a guide written for the version of Ubuntu you are using. You can use the search functionality at the top of the page to find a more recent version.
You can host multiple SSL certificates on one IP Address using Server Name Identification (SNI).
Although hosting several sites on a single virtual private server is not a challenge with the use of virtual hosts, providing separate SSL certificates for each site traditionally required separate IP addresses. The process has recently been simplified through the use of Server Name Indication (SNI), which sends a site visitor the certificate that matches the requested server name.
SNI can only be used for serving multiple SSL sites from your web server and is not likely to work at all on other daemons, such as mail servers, etc. There are also a small percentage of older web browsers that may still give certificate errors. Wikipedia has an updated list of software that does and does not support this TLS extension.
SNI does need to have registered domain names in order to serve the certificates.
The steps in this tutorial require the user to have root privileges. You can see how to set that up in the Initial Server Setup Tutorial in steps 3 and 4.
Nginx should already be installed and running on your VPS.
If this is not the case, you can download it with this command:
sudo apt-get install nginx
You can make sure that SNI is enabled on your server:
nginx -V
After displaying the nginx version, you should see the line:
TLS SNI support enabled
For the purposes of this tutorial, both certificates will be self-signed. We will be working to create a server that hosts both example.com and example.org.
The SSL certificate has 2 parts main parts: the certificate itself and the public key. To make all of the relevant files easy to access, we should create a directory for each virtual host’s SSL certificate.
mkdir -p /etc/nginx/ssl/example.com
mkdir -p /etc/nginx/ssl/example.org
First, create the SSL certificate for example.com.
Switch into the proper directory:
cd /etc/nginx/ssl/example.com
Start by creating the private server key. During this process, you will be asked to enter a specific passphrase. Be sure to note this phrase carefully, if you forget it or lose it, you will not be able to access the certificate.
sudo openssl genrsa -des3 -out server.key 1024
Follow up by creating a certificate signing request:
sudo openssl req -new -key server.key -out server.csr
This command will prompt terminal to display a lists of fields that need to be filled in.
The most important line is "Common Name". Enter your official domain name here or, if you don't have one yet, your site's IP address. Leave the challenge password and optional company name blank.
You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:US State or Province Name (full name) [Some-State]:New York Locality Name (eg, city) []:NYC Organization Name (eg, company) [Internet Widgits Pty Ltd]:Awesome Inc Organizational Unit Name (eg, section) []:Dept of Merriment Common Name (e.g. server FQDN or YOUR name) []:example.com Email Address []:webmaster@awesomeinc.com
We are almost finished creating the certificate. However, it would serve us to remove the passphrase. Although having the passphrase in place does provide heightened security, the issue starts when one tries to reload nginx. In the event that nginx crashes or needs to reboot, you will always have to re-enter your passphrase to get your entire web server back online.
Use this command to remove the password:
sudo cp server.key server.key.org sudo openssl rsa -in server.key.org -out server.key
Your certificate is all but done, and you just have to sign it.
Keep in mind that you can specify how long the certificate should remain valid by changing the 365 to the number of days you prefer. As it stands this certificate will expire after one year.
sudo openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
You are now done making the certificate for your first host.
To create the second certificate, switch into the second directory:
cd /etc/nginx/ssl/example.org
Repeat the previous three steps for the second certificate. Once both are squared away, you can start adding the certificates to your virtual hosts.
Once you have the certificates saved and ready, you can add in your information in the virtual host file.
Although it’s not required, we can create two virtual host files to store virtual hosts in a separate files.
sudo nano /etc/nginx/sites-available/example.com
Each file will then contain the virtual host configuration (make sure to edit the server_name, ssl_certificate, and ssl_certificate_key lines to match your details):
server { listen 443; server_name example.com; root /usr/share/nginx/www; index index.html index.htm; ssl on; ssl_certificate /etc/nginx/ssl/example.com/server.crt; ssl_certificate_key /etc/nginx/ssl/example.com/server.key; }
You can then put in the appropriate configuration into the other virtual host file.
sudo nano /etc/nginx/sites-available/example.org
server { listen 443; server_name example.org; root /usr/share/nginx/www; index index.html index.htm; ssl on; ssl_certificate /etc/nginx/ssl/example.org/server.crt; ssl_certificate_key /etc/nginx/ssl/example.org/server.key; }
The last step is to activate the hosts by creating a symbolic link between the sites-available directory and the sites-enabled directory.
sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/example.com
sudo ln -s /etc/nginx/sites-available/example.org /etc/nginx/sites-enabled/example.org
With all of the virtual hosts in place, restart nginx.
sudo service nginx restart
You should now be able to access both sites, each with its own domain name and SSL certificate.
You can view the sites both with and without the signed SSL certificates by typing in just the domain (eg. example.com or example.org) or the domain with the https prefix (https://example.com or https://example.org).
Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
@gustav: SNI is an extension to the TLS protocol that fixes the said issue: <a href=“http://en.wikipedia.org/wiki/Server_Name_Indication”>http://en.wikipedia.org/wiki/Server_Name_Indication</a>. So, assuming the browser supports SNI (which most do), you should be able to run multiple SSL-enabled virtualhosts on a single IP address.
Quick critiques while skimming the openssl aspects of this guide:
1024-bit keys? That’s not especially secure, is it? Aren’t they deprecated in favor of 2048 nowadays? I’m not sure all CAs even accept them anymore…
Why do you create an encrypted key in one step, and then decrypt it a couple steps later? Why not…not encrypt it in the first place?
In general, it seems like pretty much all of steps 2 through 4 could be replaced with one:
openssl req -days 365 -new -newkey rsa:2048 -nodes -keyout server.key -out server.csr
Trying to help with SSL while I should be in the shower’ly yours, Matt Nordhoff
These kind of articles are what make Digital Ocean better than the rest. I hope you keep writing and updating them rather than deprecating…
I assume this would also work with Let’s Encrypt generated certs?
Thanks, I’m trying to do exactly the same, but including IP6 support (adding a line like:
listen [::]:443 ipv6only=on; ) It is working with only one Virtual Host, but as I add the second, ngix refuses to restart and logs something like:
duplicate listen options for [::]:443 in /etc/nginx/sites-enabled/config_file
Any ideas why this is happenig? Works fine if I remove the IP6 support line from second Virtual Host.
Cheers :)
For those that have bought or are using PositiveSSL from Comodo, you’ll need to concatenate what you receive in your ZIP file. To do this, login as root / sudo user and:
If you receive an error when validating the certificate, drop the root certificate like so:
The order does matter, so make sure you follow the order as shown above. If you get a chain issue, then you need to drop the external root CA.
This was helpful. I already had a single host configured for ssl, with the line
So adding another server with the “listen 443” didn’t work. The trick was to follow what the article says, and use “listen 443” in both configs. I also added the “ssl on” line to both. It’s working great, thanks!
I have bought 2 PositiveSSL certificates and How do I implemente them instead of using self signing? I am stuck on Step 4 because I do not know how to implement the PositiveSSl.
Does anyone know how I proceed?
Beware of using SNI as long as a major part (~ 25 % !) of internet users is still using Windows XP: Wikipedia: Usage share of operating systems
Multi-Domain SSL (SAN) certificates are available as low as US$59/yr, so I do not see the point in locking out 1/4 of all internet users: Multi-Domain (SAN) SSL certificates
But I would also like to see an option at DO for buying more IP addresses…
@rcs
Did you manage to sort out your issue?
If so, could you please share how you did it?
I have multiple ssl domains on a droplet but they are conflicting with one of them which the server is making default somehow.