SSL Certificate signed by Authorities

Well, you can sign your SSL certificates your self using OpenSSL library. You can visit this link to learn more about generating SSL CSR and Private Key.  One disadvantage with this kind of approach is that browsers do not trust the certificates signed by you. These type of certificates are called self signed certificates. So, your visitor will face weird situations likecerti1

This will definitely affect your business.


Unfortunately we need to pay certification authorities like Comodo SSL, Digi-Cert, etc to verify our certificates. To get the verified certificate we need to supply the provider with Certificate Signing Request(CSR) file which we generated using OpenSSL or we can get from services like Heroku or Our Hosting service provider.

Note: Giant providers can be much more expensive so you can try re-sellers like for cheaper rates.

Generating CSR Using Heroku

$ heroku certs:generate * -a myherokuapp

will prompt to enter details one-by-one

Generating CRT

Normally you need to open the .csr file in text editor, copy and paste the content into some text-area field in the authority’s website.

Then they will verify if you are the real owner of that particular domain. You can either verify via Email, HTTP or DNS verification. You have to prove that you own that website.

  • Email: A verification email is sent which you need to read and click the verification link.
  • HTTP: They will provide you a plain text file; which you need to put into the server via FTP or SSH and make sure the file is accesible via
  • DNS Verification: You must create a special CNAME record in the DNS records for your domain. This record will be also provided after the activation..

Depending on the certificate type or brand, you may be asked for different types of information. Certificates that require business validation, for example, will require the business’ or company’s information. Non-mandatory fields are shown with an “Optional” tag. Administrator’s contact information must be submitted using latin characters (Aa-Zz) and digits (0-9) only.

After verification they will normally provide you with .crt and .ca-bundle or .p7b file


How Certificate verification works


Setting up your new SSL Certificate


Put your .crt and .key file in a directory. Chdir to that path. and run

$ heroku certs:add [server.crt] [server.key] -a myherokuapp
Resolving trust chain... done
Adding SSL Endpoint to myherokuapp... failed
 ! Only one SSL endpoint is allowed per app (try certs:update instead).

well, then I need to update

$ heroku certs:update server.crt server.key -a myherokuapp
Resolving trust chain... done

! WARNING: Potentially Destructive Action
 ! This command will change the certificate of endpoint on myherokuapp.
 ! To proceed, type "myherokuapp" or re-run this command with --confirm myherokuapp

> thepact
Updating SSL Endpoint for myherokuapp... done
Updated certificate details:
Common Name(s): *

Expires At: 2017-04-17 23:59 UTC
Issuer: /C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
Starts At: 2016-04-15 00:00 UTC
Subject: /OU=Domain Control Validated/OU=PositiveSSL Wildcard/CN=*
SSL certificate is verified by a root authority.

Getting Private Key File if generated by Host Provider

If you have not manually generated .csr then you probably don’t have your Private Key file with you; which is important to set up the certificate to your web server. You probably have access to your host server via FTP or SSH. You can find the corresponding PrivateKey and CSR file over there.

Why would I need to download Private key if its already in my host server and works perfect?

-> Well, if your is hosted in one server and other in another server, then you need the pair (.csr and .key) file to certify your server.

Useful links

SSL Certification and Linux / Nginx

Create the SSL Certificate

We can start off by creating a directory that will be used to hold all of our SSL information. We should create this under the Nginx configuration directory:

sudo mkdir /etc/nginx/ssl

Now that we have a location to place our files, we can create the SSL key and certificate files in one motion by typing:

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/nginx/ssl/nginx.key -out /etc/nginx/ssl/nginx.crt

You will be asked a series of questions. Before we go over that, let’s take a look at what is happening in the command we are issuing:

  • openssl: This is the basic command line tool for creating and managing OpenSSL certificates, keys, and other files.
  • req: This subcommand specifies that we want to use X.509 certificate signing request (CSR) management. The “X.509” is a public key infrastructure standard that SSL and TLS adheres to for its key and certificate management. We want to create a new X.509 cert, so we are using this subcommand.
  • -x509: This further modifies the previous subcommand by telling the utility that we want to make a self-signed certificate instead of generating a certificate signing request, as would normally happen.
  • -nodes: This tells OpenSSL to skip the option to secure our certificate with a passphrase. We need Nginx to be able to read the file, without user intervention, when the server starts up. A passphrase would prevent this from happening because we would have to enter it after every restart.
  • -days 365: This option sets the length of time that the certificate will be considered valid. We set it for one year here.
  • -newkey rsa:2048: This specifies that we want to generate a new certificate and a new key at the same time. We did not create the key that is required to sign the certificate in a previous step, so we need to create it along with the certificate. The rsa:2048 portion tells it to make an RSA key that is 2048 bits long.
  • -keyout: This line tells OpenSSL where to place the generated private key file that we are creating.
  • -out: This tells OpenSSL where to place the certificate that we are creating.

As we stated above, these options will create both a key file and a certificate. We will be asked a few questions about our server in order to embed the information correctly in the certificate.

Fill out the prompts appropriately. The most important line is the one that requests the Common Name (e.g. server FQDN or YOUR name). You need to enter the domain name that you want to be associated with your server. You can enter the public IP address instead if you do not have a domain name.

The entirety of the prompts will look something like this:

Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:New York
Locality Name (eg, city) []:New York City
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Bouncy Castles, Inc.
Organizational Unit Name (eg, section) []:Ministry of Water Slides
Common Name (e.g. server FQDN or YOUR name) []
Email Address []

Both of the files you created will be placed in the /etc/nginx/ssl directory.

Wildcard certificate

In computer networking, a wildcard certificate is a public key certificate which can be used with multiple subdomains of a domain. The principal use is for securing web sites with HTTPS, but there are also applications in many other fields.

Common Name (e.g. server FQDN or YOUR name) []:*
# This make the certificate also applicable to sub-domains.

Step Two — Configure Nginx to Use SSL

We have created our key and certificate files under the Nginx configuration directory. Now we just need to modify our Nginx configuration to take advantage of these by adjusting our server block files. You can learn more about Nginx server blocks in this article.

Nginx versions 0.7.14 and above (Ubuntu 14.04 ships with version 1.4.6) can enable SSL within the same server block as regular HTTP traffic. This allows us to configure access to the same site in a much more succinct manner.

Your server block may look something like this:

server {
        listen 80 default_server;
        listen [::]:80 default_server ipv6only=on;

        root /usr/share/nginx/html;
        index index.html index.htm;


        location / {
                try_files $uri $uri/ =404;

The only thing we would need to do to get SSL working on this same server block, while still allowing regular HTTP connections, is add a these lines:

server {
        listen 80 default_server;
        listen [::]:80 default_server ipv6only=on;

        listen 443 ssl;

        root /usr/share/nginx/html;
        index index.html index.htm;

        ssl_certificate /etc/nginx/ssl/nginx.crt;
        ssl_certificate_key /etc/nginx/ssl/nginx.key;

        location / {
                try_files $uri $uri/ =404;

When you are finished, save and close the file.

Now, all you have to do is restart Nginx to use your new settings:

sudo service nginx restart

This should reload your site configuration, now allowing it to respond to both HTTP and HTTPS (SSL) requests.

Step Three — Test your Setup

Your site should now have SSL functionality, but we should test it to make sure.

First, let’s test to make sure we can still access the site with using normal HTTP. In your web browser, go to your server’s domain name or IP address:



Sources for references

Linux Distributions : Nginx : Configuration Basics

Nginx is a light weight high-performance HTTP server and reverse proxy, as well as an IMAP/POP3 proxy server. Nginx is known for its high performance, stability, rich feature set, simple configuration, and low resource consumption.

This guide describes how to start and stop Nginx, and reload its configuration, explains the structure of the configuration file and describes how to set up Nginx to serve out static content and how to configure Nginx as a proxy server.

Continue reading