How to Create Self-Signed SSL Certificates with OpenSSL

Written by Tony Bhimani
Posted on August 14, 2006

Requirements
OpenSSL

Contents
Introduction
Generate Your Private Key
Certificate Signing Request (CSR)
Sign Your Certificate Signing Request
Remove the PassPhrase From Your Private Key
Install Your Certificate and Private Key
Configure Your Apache SSL Virtual Host
Test Your Apache SSL Virtual Host
What to Know When You're Ready to Purchase
Conclusion

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.

openssl genrsa -des3 -out server.key 1024
[enter a password]
[confirm your password]

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.

openssl req -key server.key -out server.csr
[enter your private key password]
[enter your two character country code]
[enter your full state or province name]
[enter your city name]
[enter your company name]
[enter your organizational unit or leave it blank]
[enter your common name or fqdn]
[enter your admin email address]
[leave the rest of the attributes blank]

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).

openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
[enter your private key password]

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.

cp server.key server.key.secure
openssl rsa -in server.key.secure -out server.key
[enter your private key password]

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.

mv server.csr /etc/httpd/conf/ssl.csr/host_domain_tld.csr
mv server.crt /etc/httpd/conf/ssl.crt/host_domain_tld.crt
mv server.key /etc/httpd/conf/ssl.key/host_domain_tld.key
mv server.key.secure /etc/httpd/conf/host_domain_tld.key.secure

After they're moved we'll change permissions so they can only be read by root.

chmod 400 /etc/httpd/conf/ssl.csr/host_domain_tld.csr
chmod 400 /etc/httpd/conf/ssl.crt/host_domain_tld.crt
chmod 400 /etc/httpd/conf/ssl.key/host_domain_tld.key
chmod 400 /etc/httpd/conf/ssl.key/host_domain_tld.key.secure

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.

How would you rate the usefulness of this content? Poor 1 2 3 4 5 6 7 8 9 Outstanding Optional: Tell us why you rated the content this way. Characters remaining: 1024

Average rating: 4.62 out of 9. 1 2 3 4 5 6 7 8 9 159 people have rated this content.