How to implement SSL or TLS secure communications

How to implement SSL or TLS secure communications

Summary: This information is also available as a TechRepublic download.SSL (Secure Socket Layer) and its successor TLS (Transport Layer Security) are two technologies that enable secure communications on a massive global scale.

TOPICS: Servers, Windows

This information is also available as a TechRepublic download.

SSL (Secure Socket Layer) and its successor TLS (Transport Layer Security) are two technologies that enable secure communications on a massive global scale. To facilitate SSL or TLS encryption between any two computers, an X.509 Digital Certificate is required on at least one end of the connection. The Digital Certificate is usually installed at the Server end because it makes it simple for any end user to make a secure SSL or TLS connection to the server without a Digital Certificate on the client end. A trusted third party called a CA (Certificate Authority) like VeriSign, Entrust, GeoTrust, or GoDaddy asserts the authenticity of the Digital Certificate with a Digital Signature so that the client knows that the Server isn't fake. This trust comes from the fact that these Certificate Authorities have their Root Certificates with Public Keys pre-installed in every nearly every Operating System and Application on the market.

Therefore to enable SSL or TLS secure communications on a Server with the general public, Server administrators need to acquire a Digital Certificate from any trusted third party CA and this is usually done through an offline web-based request. Since I've gotten requests from Administrators who read my blog entry "A secure Wireless LAN hotspot for anonymous users" how to go about doing this, I've created the following procedure for buying a Digital Certificate. This procedure works on VPN Concentrators, Web Servers, RADIUS Servers, or anything that uses standard X.509 Digital Certificates.

The Certificate generated using this Windows-based procedure will work for any device or Operating System that uses standard X.509 Digital Certificates. No additional tools are needed if you're running this procedure on Windows Vista computer. On any other version of Windows Client or Server OS, you will need to make sure that the Windows Server 2003 Admin Pack is installed so that the needed command line tools are available to you. You can download a copy here from Microsoft but it is also available on any Windows Server 2003 installation CD. There is an alternative procedure for doing this if Microsoft IIS is installed but this procedure will focus on the command line technique.

The first step is to prepare a text file that contains the desired parameters with the following format. You will need to put in your own server name with your DNS qualifier at the end of it. The "CN" field is the Common Name field and it is the key identifier for our Digital Certificate. If we were going to set up a secure server called for example, the CN field will need to be If we were setting a secure RADIUS server for Wireless LAN authentication, we can call it something like We can create a file called CSRParameters.txt and put in the following text.

[NewRequest] Subject=",C=GB" KeyLength=2048 MachineKeySet=TRUE Silent=TRUE Exportable = TRUE

Assuming you're running Windows Vista or you've installed the Windows Server 2003 Admin Pack on Windows Server 2003 or Windows XP, you will need to start a command prompt. Windows Vista requires the following special procedure to start a command prompt in Administrator mode.

Start a Vista command prompt as Administrator:

Hit the "Start" button on the keyboard (CTRL-ESC) and type "cmd". You'll find cmd.exe returned on the top of the start menu where you will then right click on cmd.exe. Click "Run as administrator" and Windows Vista UAC will ask you for permission to escalate permissions. Click "Continue" and you'll get a command prompt that's running under the context of Administrator. If you're running older versions of Windows, you just log in as any Administrator and hit the "Start" and "Run" command and launch cmd.exe.

Once you're at the command prompt, type the following command to generate a CSR (Certificate Signing Request):

certreq -new CSRParameters.txt CSROutput.txt

Note that this is assuming CSRParameters.txt is in the directory that you're running the command in. If it isn't in the same directory, you'll either need to move it there or type out the entire path of the file for the input parameters. After a few seconds, the output file called CSROutput.txt will be generated and you'll be able to open it up like any text file.

<Next page - Buying a Digital Certificate>

Buying a Digital Certificate

Next you'll need to go to any of the Certificate Authorities I mentioned above and purchase a Digital Certificate using this CSR you just created.

Note: GoDaddy certificates at $20/year happens to be about ten times cheaper than VeriSign and there isn't really a shred of difference in the certificate you buy other than the branding aspect of it which no one will ever see unless they dig deep in to the certificate. If you are under the impression that buying a $200 VeriSign certificate is more secure, understand that any breach of security at the cheaper CA shops mean that all of us are compromised equally since the GoDaddy Root Certificate carries as much weight in our factory installed CTL (Certificate Trust List) as the VeriSign Root Certificate. So ultimately it doesn't matter where you buy your Digital Certificate from a security standpoint.

I'm bringing this issue of branding up because I've had people tell me that they refuse to buy the cheap SSL certificate. But the same people will end up running self-signed Digital Certificates and have their users ignore the invalid Certificate warning when they log in to their corporate web application or they won't even bother running SSL at all. As absurd as these examples are, they're quite common in the world of IT and it's terrible a shame. Buy the expensive certificate if you're worried that other people might look down on you for buying the $20 certificate, but please don't use self-signed certificates or run clear text! Now that you know how cheap it is to do it the right way and you have this tutorial, do the right thing!

So once you've decided where you want to buy your certificate, go to their website and have a Credit Card ready. For example if you go the cheapest route, take the first option of one or two years at less than $20 per year and hit the "ADD" button. Skip all the extra offers section and hit "Continue" and you'll see the shopping cart. Accept the terms and click "Checkout". You'll probably need to use a credit card to pay for the Certificates and once you finish paying, you will be prompted to paste in the CSR text from the file called CSROutput.txt which looks something like the following.

The Certificate Authority will have to verify that you're authorized to buy a certificate for the domain name that you're requesting and they do this by sending an email verification to the administrator of the domain listed under whois. You'll usually get a choice of which administrator email account to send the verification to so make sure you pick one that you have access to or someone within your company has access to. Once the email verification has been completed, you will either see the Digitally Signed Certificate on the web page or you'll get it emailed to you. Don't worry if that email isn't encrypted because a Digital Certificate has no Private Key in it because the Public and Private Keys were generated on the computer that created the CSR. The CA signing process only signs a CSR which contains Public Key information.

Once you've gone through the process of buying a Digitally Certificate, it will look something like the following:

You can take that entire chunk of text and paste it in to a text file called MyCertificate.txt. Once it's pasted, you'll want to rename it to MyCertificate.cer or anything ending with the ".cer" extension. This way you can immediately open it in Windows and it will look like the following.

<Next page - Installing the Digital Certificate>

Installing the Digital Certificate

Once you've created the Digital Certificate by cutting/pasting it in to a text file and you've renamed it with a .cer extension, you'll need to install that Digital Certificate on the machine you generated the CSR on before you can ultimately export it.

To begin, you'll need to open an MMC console by clicking Start | Run. Then type "mmc" and OK. You'll need to do a UAC escalation and you will see the following console appear. From there, you'll click "ADD/Remove Snap-in...". Note that these are screen shots from Vista. The procedure with Windows XP and 2003 will be slightly different but in principle it will be the same. This article shows you what the old procedure looked like on Windows XP and 2003.

You'll then see this screen where you will need to select Certificates and hit the "Add" button.

Click "Computer account" and hit "Next".

Select "Local computer" and click "Finish".

Next you'll expand out the Certificate Console and Import the Certificate

Hit next on the Certificate Import Wizard

Browse or type in the name of the Certificate you purchased. Hit "Next".

Hit "Next". Then hit "Finish" on the following screen.

<Next page - Export the Digital Certificate>

Export the Digital Certificate

The final procedure is to export the Digital Certificate. The newly exported Digital Certificate will contain both the Public Key and the Private Key which means it can be installed on any number of Servers that will host your secure application. So long as the Server is being used for the same purpose or hosting the same website, you can use an identical Digital Certificate on as many Servers as you like. You will need to carefully protect this file containing the Public and Private Key keeping it secret since anyone who possesses the Private Key can decrypt.

To export the Certificate along with the Private Key, right click on the Certificate you purchased shown in the screen shot below and choose "All Tasks" and "Export".

Hit "Next" at the Certificate Export Wizard screen.

Here you'll need to select the "export the private key" option

Hit next on the following screen. You might want to choose the "Delete the private key if the export is successful" option because you don't want to leave this Certificate and Private Key on this computer. Ultimately the Certificate needs to be transferred to the Server that will use it.

You'll have to type a password to secure this Certificate. Be sure to remember it because you won't be able to import this Certificate if you don't know the password.

Next you'll need to pick a filename for the Certificate

Next you'll hit the "Finish" button

Since the Certificate doesn't belong on our workstation, we can delete the Certificate along with the Private Key. Simply highlight the Certificate shown below and click the red X button that I circled.

Now that we have the exported Digital Certificate containing the Private Key, we can transfer that to any number of Servers that will be using the Common Name we selected for our Digital Certificate.

<Return to top>

Topics: Servers, Windows

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Informative post - Thanks George

  • Why not a free certificate?

    Why did you not mention that it's possible to get a free certificate from It seems that many individuals and small businesses could benefit.
    • Because it's not trusted by the public by default

      Because it's not trusted by the public by default. It's possible to do that if you can get the users to install a Cert from, but is that really worth supporting and trying to explain to thousands of users? Is it worth $20 to you?

      Now back in the day when the only cert you could buy was $300, then you might have a good case to make.
      • Self-signed certificates

        george ou wrote, in response to a comment about generating your own certificates:

        [i]Because it's not trusted by the public by default. It's possible to do that if you can get the users to install a Cert from, but is that really worth supporting and trying to explain to thousands of users? Is it worth $20 to you?[/i]

        Sure, but if we're taking about a certificate for TLS/SSL encrypted email transport, we're not talking about "the public." The only time you need a 3rd party validation of a certificate is when their is no prior trust relationship between the sender and receiver. Clearly, this is not the case for an employer providing secure email transport for employees. The employer/employee relationship can be trusted (at least to the extend of exchanging email), and the employee should recognize that a certificate signed by their employer is adequate for that purpose.

        Using e.g. "TinyCA" to generate your own certificates can also allow a home user to secure remote email exchange with their home network at no cost.
        • For encrypted email transport, you're dealing with the entire Internet

          For encrypted email transport, you're dealing with the entire Internet. How do you know the SMTP server on the other end has Root Certificates installed? Now I signed up for CACert and I hope they do well, and I believe it's popular with Mail Server Admins so it may be worth it. However, if there's a single domain that doesn't have that configured, it's going to be a lot of trouble to just make the phone call to get it straightened out. So saving $20 just isn't worth the trouble. If we're talking about $400 certificates then it may be worth considering.
          • Fingerprint

            All the user need do to verify that the self-signed certificate is valid is check the key fingerprint on the certificate with that obtained directly from the employer. This is more secure than simply blindly trusting a 3rd party Certificate Authority anyway. Wasn't it only a couple years ago that Microsoft's certificate was compromised by by inept fact checking by Verisign? How much security is that $400 buying you anyway?
          • Sorry, that just doesn't work in the real world

            Asking users to manually check the Digital Signature doesn't fly. The third party cert is only $20. You're right that Verisign botched a code signing certificate.
          • indeed

            It's always good to see that someone "gets it" on some matter of security where most people don't. All a certifying authority protects you from is people from whom the CA doesn't get any money. It's better to get people used to the idea that they have to use their own judgment from time to time. Real trust can't be automated.
    • You could just as easily generate your own certificates.

      This is something that is easy to do with OpenSSL for Apache servers (or others). This does not resolve the trust issues, but it does allow for TLS based VPNs like [url=]OpenVPN[/url] or a commercial equivalent. Depends on what and why you are using SSL/TLS for. Generating a SSL/TLS certificate is a trivial process.
  • ot the right area for security

    Security at this level has been around for a long time, and while any improvement is very welcome, the main vulnerabilities are still on the desktop. In the phrase Personal Computer what part of Personal do Microsoft have a problem with.
  • Linux

    Okay so how do I do the same thing but in linux with shared hosting? Anyone?
    • You'd probably use OpenSSL

      You'd probably use OpenSSL. Note that this procedure produces a Digital Certificate that can be exported to Windows, Linux, or Hardware Appliances.
      • ANY OS

        What was throwing me was the line command in DOS. I am amazed at the host out there that do not realize that their standard FTP is sent in clear text. And there are so many users that then use their admin passwords for their FTP to make the situation worse. Again, thanks for your help.
        • FTP usage is just crazy

          FTP usage is just crazy, espcially those integrated in to Active Directory. I've known Domain Admins use clear text FTP authentication with their Domain Admin credentials and it's scary.

          Unfortunately, Secure FTP with SSL/TLS or the SSH isn't built in to the standard browser and you need a special client for that. The result is that hardly anyone uses secure FTP.
          • Not in the windows world anyway.

            openssh includes secure ftp in the same transport.

            /Just sayin'
          • Open SSH works in Windows too

            You also have free FTPS solutions on Windows.

            The point is that these mechanisms are independent of
            the OS so it's silly to turn this in to a religious OS
    • SSL on Linux shared hosting

      If you have an account with a shared hosting provider, you need to work out an SSL setup with the webhost -- regardless of what OS you're using. George's instructions only work for situations where you have control of the machine you're using (even if it's a virtual machine). With a shared hosting provider, usually every account on a given server (or maybe every account with that webhost) will use the same SSL certificate, unless you're very lucky -- and it usually involves a redirect through a separate SSL server.

      If you're setting up a webserver yourself, as George points out, OpenSSL is probably what you'll want to use for SSL software. You'll still need to generate your own certificate(s), or buy them off some certifying authority.
  • Personal Cert

    And show us how to make a personal cert for logins that no one is going to be using but ourselves. :)
    • magic

      I forgot the magic word. PLEASE :)
    • I have a Self-Signed procedure that I linked to

      I have a Self-Signed procedure that I linked to in this blog. Here's the link again.