Introduction

This is a brief and superficial tutorial on creating self-signed SSL
certificates using OpenSSL. So what is a SSL certificate and why would
you want one? Without getting overly complex, SSL certificates verify
your identity to an end user and make it possible to encrypt the communication
between two hosts. In short, SSL works like this. The browser would check
the web server's certificate to see if it's valid or not. If the certificate
is valid and not someone trying to impersonate the intended destination
web server, the browser and web server negotiate on an encryption algorithm
they both can understand. Once a negotiation has been reached they use
unique keys or codes (public key and private key) to be used for encrypting
and decrypting the data on both sides. Finally the browser and web server
communicate securely so no one can eavesdrop on their conversation.

Secure Sockets Layer (SSL) is used in e-commerce and other applications
where the information being transmitted must be secure and not visible
to anyone watching the network traffic. A practical e-commerce example
would be making a purchase form an online store. When you enter your credit
card information and click a submit button, your information is sent from
your web browser to the store's server. It's encrypted using SSL so no
one else can read it as it travels across the internet. An application
example could be acquiring UPS shipping rates in real-time. When you have
an account with UPS you must establish a userid, password, and are then
assigned a license key. You would transmit these credentials programmatically
to their server to request pricing for maybe sending a package to New
York from your location. You wouldn't want your credentials being sent
in plain text because it'd be possible for someone to steal your account
information, so to combat this UPS offers their XML service through a
SSL enabled URL.

Now that you have a general understanding of SSL we come to the certificate
signing part. SSL certificates must be signed by a trusted authority or
more commonly known as Certificate Authorities (CA). CA's confirm your
identity by adding their signature to your SSL certificate. On the web
browser side, browsers like FireFox and Internet Explorer have a list
of CA fingerprints to match against the SSL certificates they come across.
For example, when you go to a SSL enabled URL, that certificate would
be signed by a company like Verisign, Thawte, Comodo, or some other CA.
Your web browser would check the certificate's CA fingerprint to make
sure it hasn't been forged and is a valid and trusted certificate. If
all goes well your browser would accept the certificate and give no complaints,
however, if it doesn't have the fingerprint on file it would complain
and typically throw up a window saying the certificate is bad or shouldn't
be trusted. CA's usually ask for proof of your company like a copy of
your DBA (Doing Business As) before they'll sign your certificate. Also,
be prepared to hand over some cash because CA's won't sign your certificate
for free.

So where does that leave us individuals and non-commercial entities that
want to use SSL to encrypt our data? The answer is using self-signed certificates.
Self-signed certs are the same as signed versions except for the fact
that a CA doesn't stamp it with their approval, instead you stamp it with
yours. Self-signed certs offer the same amount of protection but at the
cost of dealing with the annoying popup alert the browser displays and
someone being able to forge your identity, however they are completely
free and easy to make using OpenSSL. If you want to create your own private
use SSL certificate then keep reading this tutorial and you'll learn how
to. Make sure you're logged in as root and are in your home directory.
Also, be sure to create a directory called ssl and move into
it (we'll create our SSL files here temporarily).

Generate Your Private Key

The first step in creating a self-signed SSL certificate is to generate
your private key. Its purpose is to encrypt data to be decrypted by the
public key and vice versa, so basically one cannot work without the other
since they are both mathematically linked. The private key is stored on
the web server and should never be shared with anyone (protect it at all
costs!). Your private key can be either RSA or DSA based with a minimum
of 1024 bits using a cipher such as TripleDES. For our private key we'll
use RSA, 1024 bits, and TripleDES (I've gone as far as to use 4096 bits
- more secure but slower to encrypt/decrypt). Our private key password
should contain a minimum of 12 characters and they should be alpha-numeric
with some special characters like spaces, dollar signs, asterisks, etc.
The point is to choose a very hard password to crack and not be dictionary
based. When you figure out what password you're going to use for your
private key then you should write it down and keep it in a safe place.
Don't lose this password because when it comes time to renew your certificate
you'll have to trash it and start over from scratch.

Our private key has been created and saved as server.key. We can now
move on to creating the certificate signing request (public key).

Certificate Signing Request (CSR)

The certificate signing request (CSR) is an unsigned copy of the SSL
certificate. The CSR contains the public key and X.509 certificate attributes
including your country, state, organization name, server's common name
or FQDN (fully qualified domain name), and other information. Before you
can get a digital certificate from a CA you'll need to generate a CSR
on the server you'll be using the SSL certificate on. The most important
attribute you should pay close attention to is the common name. You must
use the FQDN of the server you'll be protecting by SSL. For example, if
you want to use https://secure.yourdomain.com then the common
name would be secure.yourdomain.com. You'll need to configure
DNS and your web server to respond to requests for this address. Another
thing to know is that when you enter your organizational name, you should
use the word 'and' instead of an ampersand '&' character if you have
a company name like Law Offices of Smith & Klein. Certificate Authorities
like Verisign are very picky about the ampersand and will likely make
you redo your CSR if you use one. Play it safe and use 'and' instead of
'&'. Now we'll create our certificate signing request.

Our CSR has been generated and saved as server.csr. At this point you
could send in the request to a CA, pay the fee, prove your identity, and
then they would issue you a SSL certificate. All they need is the contents
of server.csr which can be retrieved by using the cat
command.

cat server.csr

You would send everything to the CA starting from the first hyphen to
the last one (the entire file).

Sign Your Certificate Signing Request

With our CSR generated we come to the heart of this tutorial which is
signing your CSR to create a SSL cert for your web server. Since we're
signing our own certificate we have much more control over the process.
When you have a CA sign your CSR you pay for a year, two years, or possibly
more. In our case we can specify how many days our certificate is good
for before it expires and needs to be resigned. We'll be using 365 days
but feel free to use a value greater than one year (maybe 5475 days or
15 years...that should take a while for the clock to run out).

Our self-signed certificate has been created and saved as server.crt.
You will use this certificate and the private key for Apache to enable
SSL on your server, however before we do that we will remove the passphrase
from our private key.

Remove the PassPhrase From Your Private Key

When your private key has a passphrase, Apache will have no idea what
it is and prompt you for your password whenever the service is started.
As you can imagine, this would be a major inconvenience if you need to
edit any virtual hosts and reload the changes or if your server crashed
or rebooted itself. Apache would just sit there and wait for you to key
in the password for each SSL enabled host. The solution to this dilemma
would be to remove the passphrase from the private key file. Of course
something that simple isn't without another problem. When you remove the
encryption from your private key you're also removing its security. If
your private key was ever to be stolen then you would need to have your
certificate revoked. One course of action is to make your private key
readable by only root (chmod 400). Let's remove the passphrase from our
private key.

So now we have two copies of our private key, a secure version (server.key.secure)
and an unsecure one (server.key).

Install Your Certificate and Private Key

We're going to copy our four SSL files (server.csr, server.crt, server.key,
server.key.secure) to some directories created by Apache's mod_ssl. The
locations may differ but if you're using CentOS like I am then these directories
(ssl.csr, ssl.crt, ssl.key) will be in /etc/httpd/conf. What we'll do
is move our SSL files to these directories, rename them, and change their
permissions to protect them from the average user. What I like to do is
rename the certificate files to the format of host_domain_tld
since server.* is isn't very friendly. When I created my CSR I used secure.xenocafe.com
for my host's common name. Yours will obviously be different. Where you
see secure_xenocafe_com in the commands below you will replace with your
common name following the same format.

With our SSL files in place we will edit our SSL virtual host configuration
to make use of them.

Configure Your Apache SSL Virtual Host

You should already have your Apache SSL virtual host configured, but
if you don't then you can read my lengthy Apache
Web Server tutorial to get it up and running. Open your virtual host
configuration in a text editor. It may be httpd.conf or if you followed
my Apache tutorial then the SSL virtual host file in the vhosts directory.
We need to edit two directives (SSLCertificateFile and SSLCertificateKeyFile)
and point them to our self-signed certificate and unsecured private key
file respectively. If you're installing a certificate signed by a CA then
you might have a bundle or chain file to install too. Each CA does things
differently and you should read the documentation on their web site for
installing your certificate and any dependency files.

Save your changes and exit the text editor. The last thing we need to
do is restart Apache to reload our virtual hosts and test our secure web
site.

Test Your Apache SSL Virtual Host

With our SSL virtual host file updated with our new certificate files
information, we need to restart Apache so the changes will get reloaded
and our certificate goes live.

service httpd restart

Now open up a web browser and try out your new SSL secured web site.
Be sure to use the https:// prefix instead of http://
when going there. You will be prompted with a security alert informing
you that your certificate is not signed by a trusted authority. Accept
the certificate for the session so your page will load. Once your secure
site loads you can click the padlock in the address bar to view your self-signed
certificate details if you're using FireFox. Internet Explorer users can
double-click the padlock in the bottom right corner of the window in the
status bar.

That's all there is to making a self-signed certificate with OpenSSL
and configuring Apache to use it to create a SSL secured web site.

What to Know When You're Ready to Purchase

Prices vary from the CA's so try and find the best deal from a well established
company. I've dealt with the Comodo
Group many times and have never had any significant problems. The
first time I purchased a SSL certificate from them was a couple years
ago and it was for the company I'm working at now. Comodo wanted all kinds
documentation to verify our company's identity and the employees here
were not the greatest when it came to the internet (and still aren't).
We were in between moves from one building to another so our domain whois
information was actually two addresses behind, the phone numbers were
wrong, and the business license had the wrong address. I spent a week
trying to straighten that all out because the domain was registered through
a third party and the boss had no idea who it was (two different names
on the administrative and technical contacts). To cut this short, after
I got it all corrected and faxed Comodo a copy the business license and
screenshots of the whois information and we received our certificate by
email in two days. Comodo has gotten better recently since it only took
a day to get a certificate for the second web site we're starting. If
I had to recommend a SSL certificate provider it'd be Comodo. On the other
hand, if I had to steer people away from a CA it'd be Verisign. They may
support a larger browser base but they are extremely overpriced for the
service they provide. My friend had nothing but trouble when he had to
get a SSL certificate for his work's web site. Trust me, stay away from
Verisign. The point to this section is to make sure all your company information
is up to date, be it legal papers or domain whois information, because
when you're ready to make a purchase and get your CSR signed it may be
held up because your identity can't be confirmed.

Conclusion

Self-signed certificates are a cost effective way to secure your web
site for personal or internal use. You can use them with a variety of
applications including securing your webmail
access, database management with phpMyAdmin,
or even accessing an administration section of your site if you have one.
The only drawback is you can't use them for e-commerce because they're
not signed by a certificate authority. Do you think a customer will trust
a transaction with a security alert window popping up when they try and
checkout? Nope, I sure wouldn't and you wouldn't either. If you want to
sell on the internet then you'll have to buy a SSL certificate, but at
least there are many choices out there and you don't have to spend a bundle
to gain your customer's trust.