Implementing SSL

By Paladion

October 15, 2005

In the September issue of Palisade we discussed how SSL works, what it actually protects against and what it does not. After understanding this, let’s look at how to implement SSL.


In the September issue of Palisade we discussed how SSL works, what it actually protects against and what it does not. After understanding this, let’s look at how to implement SSL.

The steps to implement SSL

Contrary to popular misgivings, moving from HTTP to HTTPS does not require costly redesign or code level changes. The process for securing web pages with SSL is quite straight forward. To enable SSL on your site, you must complete these four steps:

  1. Generate your server's key pair (public and private keys)
  2. Generate a “Certificate Signing Request” from your server and send that to the Certificate Authority (CA
  3. Install the certificate the CA sends you
  4. Configure web pages to require HTTPS access

Step1: Generate a key pair

First, generate a key-pair file that holds the public and private keys for your server. These are the keys used during SSL communication. Different web servers have different methods to generate the key pair. The steps to generate key pairs for IIS and Apache are well documented.  Remember that the private key is stored encrypted on the server with a password you provide. The server key file shouldn't be kept in a directory where people have access to it.

Step2: Generate a Certificate Signing Request

Generate a Certificate Signing Request (CSR) from your server via accessing a Trusted CA’s web page. Verisign and Thawte are two popular Trusted CAs. Why require a Trusted CA? We answer that question later in this article.

The CSR requires certain details about your company and Web server. It requires the fully qualified domain name of the web server. It is important that domain name field be filled in with the fully qualified domain name of the server to be protected by SSL. If the website to be protected is, then is the value to be filled in.

Submit CSR to CA along with documentary proof of identity. The request contains the information provided by you and also your public key. This information is signed with your private key.

The CA then uses your public key information from the certificate request to verify information signed with your private key. The CA also verifies the information supplied in the request.

Step3: Install Certificate sent by CA on the web server

After the CA verifies that the request is legitimate, it issues a signed certificate and sends that over e-mail. This is the server certificate - install in on your server. The installation of the certificate is simple - it is usually a wizard-driven process or Command-line tool depending on the web server you are using.

Step4: Configure Web pages  to Require SSL Access

You can specify which files, directories, or virtual directories require SSL to connect to. Clients must use the HTTPS protocol to access all such resources. Remember that SSL is quite resource intensive, so you want to encrypt only pages that will be dealing with sensitive data. Encrypting all pages can slow down the site considerably.
It is essential to secure the login “post” which submits the login credentials. It is not so essential to enable SSL on the html page containing the login form, but it is a good thing to do as it assures the users of the site being protected via SSL.

That’s it, congratulations! You've implemented SSL on your Web server.
Changes to make to code
To have your web site direct requests to a secure page, all you have to do is prefix the URL (of resources specified in step4) with the HTTPS protocol designation. For example, if ‘page2’ now requires SSL to access then all references to should be changed to
Why only ‘trusted’ Certificate Authority
Now we look at why the certificate should be signed only by a trusted Certificate Authority (CA)? Why can’t you self sign and save money?

If a certificate is not signed by a well known CA, you could still have a server certificate and have encrypted; but it does not give assurance to the user that the certificate holder is really who he claims to be. ‘Trusted’/‘known’ CA’s certificates are already installed as "trustworthy" – their public keys are embedded in the popular browsers. Hence whenever the user’s browser encounters a certificate signed by an ‘unknown’ CA, it pops up a Security Alert dialog box. The user can view the Certificate to see the identity of the issuing CA for the Web server certificate. The user has the option to install the CA's certificate as trusted on the browser. The figures below show the trusted CAs stored in Internet Explorer and Mozilla Firefox. Hence the security alert message is not displayed.

CAs in Internet Explorer
Fig 1. List of trusted CAs in Internet Explorer.
Open ‘IE’ browser > Tools > Internet Options > Contents > Certificates > Trusted Root CA


CAs in Mozilla Firefox
Fig 2. List of trusted CAs in Mozilla Firefox.
Open ‘Firefox’ browser > Tools > Options > Advanced > Manage Certificates > Authorities

The server certificate must be purchased from a Trusted CA. Your investment might not be useful if the web browser starts popping up security warnings to the user.


  1. Public Key Issues
  2. Secure Sockets Layer: Protect Your E-Commerce Web Site with SSL and Digital Certificates
  3. Microsoft Windows 2000 Public Key Infrastructure
  4. Getting Started with XML Digital Signatures
  5. X.509 Certificates and Certificate Revocation Lists (CRLs)
  6. SSL/TLS Strong Encryption: FAQ

Tags: Technical