OpenSUSE Linux Tips, tricks, how-tos, opinions, and news
My Resume - My LinkedIn Profile - twitter: @scottmmorrisOriginally written Jun 2, 2008, and updated on May 21, 2009
At some point or another, you’ll likely end up needing an SSL certificate for a Web site somewhere along the line. For a commercial site, your hosting provider can or will help you get this all squared away. This article is not for people in that situation.
What we’re doing here will be to create our own Certificate Authority. Then, we’ll create our own server key and a signing request. Then, we’ll sign our own certificate using the key and certificate from our own Certificate Authority. In other words, we’re not just going to create an SSL certificate, but we’re going to sign that bad boy, too.
This is useful for personal websites that need a little security, or when you’re waiting for your real cert from a real Certificate Authority. Perhaps you need it for transmitting data from an external server to your Intranet. Or perhaps you need it in any of the three hundred thousand seven hundred forty-two other situations that may arise.
The first thing that you’ll need is root access to the server. SSH in and head somewhere secure like /root.
Next, we’ll go ahead and generate our own Certificate Authority key. In this step, we are impersonating someone like Verisign or Thawte. Well, not impersonating, but we are going to do the same thing for ourselves that they would normally do.
To create our key, we’ll run this command:
openssl genrsa -des3 -out ca.key 4096
When we do that, it looks something like this:
[1257][root@mail:~/cert]$ openssl genrsa -des3 -out ca.key 4096 Generating RSA private key, 4096 bit long modulus ...............................................................................................................................++ .................................................++ e is 65537 (0x10001) Enter pass phrase for ca.key: [enter a pass phrase here for the CA key] Verifying - Enter pass phrase for ca.key: [verify the same pass phrase here] [1258][root@mail:~/cert]$
Note that those pass phrases are something you make up right then. You are not authenticating anything, but rather setting up a pass phrase for authenticating later.
Next, we’ll need to use that key to create a certificate. Before we do this, the information that you will enter here is NOT the information you will enter later for your own server. Remember, we are emulating a Certificate Authority here. When we generate our server certificate, we will put in the real information which must differ from what is here. With that, let’s whip out the certificate. Notice that we are making it good for 3650 days, or 10 years. Adjust to your taste. So let’s make the cert, now. This is done with the following command:
openssl req -new -x509 -days 3650 -key ca.key -out ca.crt
And doing this may resemble something like this:
[1306][root@mail:~/cert]$ openssl req -new -x509 -days 3650 -key ca.key -out ca.crt Enter pass phrase for ca.key: [enter the CA pass phrase from above here] You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:US State or Province Name (full name) [Some-State]:WA Locality Name (eg, city) []:Redmond Organization Name (eg, company) [Internet Widgits Pty Ltd]:Microsoft Corporation Organizational Unit Name (eg, section) []: Common Name (eg, YOUR name) []:www.microsoft.com Email Address []:bill.gates@microsoft.com [1307][root@mail:~/cert]$
Next up on the list is to create a key that corresponds to our server. The first one we made was for the Certificate Authority. This one will be generated by and for our own server. We will do that with this command:
openssl genrsa -des3 -out server.key 4096
The output should look familiar:
[1310][root@mail:~/cert]$ openssl genrsa -des3 -out server.key 4096 Generating RSA private key, 4096 bit long modulus ................................++ ....++ e is 65537 (0x10001) Enter pass phrase for server.key: [enter a pass phrase here for our server key] Verifying - Enter pass phrase for server.key: [verify the same pass phrase here] [1313][root@mail:~/cert]$
Again, those pass phrases are something you make up right then. You are not authenticating anything, but rather setting up a pass phrase for authenticating later.
Now… let’s see… oh yeah. Now, we have to create a signing request, or CSR, from the server key we just made. This signing request will usually make a trip to a genuine Certificate Authority to have the key signed and a real, verified, bonafide signed certificate returned back to us. So, to generate our signed certificate, we’ll need to first have a signing request so we can make the signed cert. See how that works?
To create the CSR, we do this:
openssl req -new -key server.key -out server.csr
Now remember, kids. This is the part where we do put in our actual real information because the server does in fact belong to us. Put in the real domain where it says “Common Name (eg, YOUR name) []:”. Fill out everything correctly. And so we do:
[1313][root@mail:~/cert]$ openssl req -new -key server.key -out server.csr Enter pass phrase for server.key: [enter the pass phrase here for our server key from above] You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:US State or Province Name (full name) [Some-State]:UT Locality Name (eg, city) []:Eagle Mountain Organization Name (eg, company) [Internet Widgits Pty Ltd]:Suse Blog Organizational Unit Name (eg, section) []: Common Name (eg, YOUR name) []:www.suseblog.com Email Address []:my-address@suseblog.com [put in your real email address here] Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []: [1323][root@mail:~/cert]$
Now, we are going to take all these files and make them do some voodoo. We are going to sign the signing request using the Certificate Authority certificate and key that we made at the beginning. What we will get is our perfectly forged signed certificate. OK, not perfectly, because we are not a real CA. But we’ll get a pretty darn good signed cert that will work for us rather nicely.
The command we’re going to run looks like this:
openssl x509 -req -days 3650 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out server.crt
And when we run it, we see something hopefully resembling this:
[1326][root@mail:~/cert]$ openssl x509 -req -days 3650 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out server.crt Signature ok subject=/C=US/ST=UT/L=Eagle Mountain/O=Suse Blog/CN=www.suseblog.com/emailAddress=my-address@suseblog.com Getting CA Private Key Enter pass phrase for ca.key: [enter the CA pass phrase from above here] [1332][root@mail:~/cert]$
Now, we have a little problem. Our server.key file will cause apache2 to prompt us for a password every time it starts. We need to fix it so that doesn’t happen. We’ll do that with these three commands:
openssl rsa -in server.key -out server.key.insecure mv server.key server.key.secure mv server.key.insecure server.key
When we run these commands, here’s our output:
[1354][root@mail:~/cert]$ openssl rsa -in server.key -out server.key.insecure Enter pass phrase for server.key: [enter the pass phrase here for our server key from above] writing RSA key [1354][root@mail:~/cert]$ mv server.key server.key.secure [1354][root@mail:~/cert]$ mv server.key.insecure server.key [1354][root@mail:~/cert]$
At this stage, you should now have a bunch of files. These, in fact:
[1354][root@mail:~/cert]$ ll total 32 drwxr-xr-x 2 root root 4096 2008-06-02 13:54 . drwx------ 10 root root 4096 2008-06-02 13:35 .. -rw-r--r-- 1 root root 2529 2008-06-02 13:07 ca.crt [CA certificate] -rw-r--r-- 1 root root 3311 2008-06-02 12:58 ca.key [CA key] -rw-r--r-- 1 root root 2049 2008-06-02 13:32 server.crt [our server certificate] -rw-r--r-- 1 root root 1748 2008-06-02 13:23 server.csr [our server signing request] -rw-r--r-- 1 root root 3243 2008-06-02 13:54 server.key [our password-less server key] -rw-r--r-- 1 root root 3311 2008-06-02 13:13 server.key.secure [our passworded server key] [1355][root@mail:~/cert]$
Just having them doesn’t get us anywhere, so let’s get them installed. First, we are going to change some permissions, because we don’t want just anyone having access to these files. To apply the appropriate permissions, run this:
chmod 0600 server.key.secure server.key server.csr server.crt
Now, here’s where things depend on the distribution that you are using. I will describe what I am doing so that if you are not on OpenSUSE, you will still be able to get this working.
In OpenSUSE, the apache2 config directory is located at /etc/apache2. Underneath that, there are a handful of directories. The three we care about are /etc/apache2/ssl.crt, /etc/apache2/ssl.csr, and /etc/apache2/ssl.key. The server.crt needs to be moved to /etc/apache2/ssl.crt. The server.csr file needs to be moved to /etc/apache2/ssl.csr. And the server.key file needs to be moved to /etc/apache2/ssl.key:
[1348][root@mail:~/cert]$ mv server.key /etc/apache2/ssl.key/server.key [1349][root@mail:~/cert]$ mv server.crt /etc/apache2/ssl.crt/server.crt [1349][root@mail:~/cert]$ mv server.csr /etc/apache2/ssl.csr/server.csr [1349][root@mail:~/cert]$
Yep, pretty complex stuff, moving files.
Now, we need to make a handful more edits to some files, and we’re just about there.
First thing is to edit /etc/sysconfig/apache2. Search through that file for the directive called APACHE_MODULES. Make sure you see ’ssl’ in there. If not, add it. Then, search through the file and find APACHE_SERVER_FLAGS. Make sure it has ‘SSL’ in it. If not, add it. Save and close the file.
You can also manage apache’s modules with the ‘a2enmod’ command. To view the list of loaded modules, run ‘a2enmod -l’.
Next, open up the config file that tells apache2 which ports to listen on. In OpenSUSE, this file is /etc/apache2/listen.conf. Rip that bad boy open. You will see the following line:
Listen 80
Add a new line for port 443, our HTTPS port, so that it looks like this:
Listen 80 Listen 443
Then, look for the following line:
NameVirtualHost *:80
Add a new line for port 443, our HTTPS port, so that it looks like this:
NameVirtualHost *:80 NameVirtualHost *:443
Save and quit.
In OpenSUSE, it’s really easy to have virtual hosts on a machine. I have like 10 on mine. One of them is my blog, www.suseblog.com. Well, to make this easy, in OpenSUSE, the virtual domain configuration files are located in /etc/apache2/vhosts.d, each with their own name. My www.suseblog.com configuration file is called suseblog.conf. To set up SSL for this virtual host, just duplicate the file and give it another name. In my case, I named it ssl-suseblog.conf.
Now, we’re going to open up that file and add like 4 lines to it. No sweat.
At the top of the file, there is a line that looks like this:
<VirtualHost *:80>
Change the port from 80 to 443, so it looks like this:
<VirtualHost *:443>
Then, go down a ways and add these lines:
SSLEngine on SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL SSLCertificateFile /etc/apache2/ssl.crt/server.crt SSLCertificateKeyFile /etc/apache2/ssl.key/server.key
Save and quit on that one, too.
We can configure this thing perfectly, but if the firewall doesn’t know to let traffic through, we will not have HTTPS access to the server. Let’s check the firewall really quick to make sure.
Fire up YAST. Go to the Security & Users option on the right, and select FIREWALL from the left. If you do not have a firewall running on the machine, you can just exit now. If you do, you will need to go to ALLOWED SERVICES. In the SERVICES TO ALLOW drop-down on the right, select HTTPS Server. Then click ADD. Then click NEXT, and finally FINISH. You should now have port 443 opened for HTTPS business.
Now, let’s go ahead and restart apache and enjoy our new self-signed self-generated SSL cert on our HTTPS service:
[1426][root@mail:/etc/apache2]$ /etc/init.d/apache2 restart Syntax OK Shutting down httpd2 (waiting for all children to terminate) done Starting httpd2 (prefork) done [1427][root@mail:/etc/apache2]$
Well, we’ve concluded. Enjoy.
If you enjoyed this post, make sure you subscribe to my RSS feed!| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
| « Feb | ||||||
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 | 31 | |||
51 queries. 0.774 seconds
June 9th, 2008 at 2:36 pm
And for those who likes UI (and YaST) there are yast2-ca-management and yast2-http-server modules
June 23rd, 2008 at 10:55 pm
Great tutorial. I am very green to all this and was able to follow it with ease. Thank you.
June 24th, 2008 at 9:03 am
Robb,
Glad to help out! Have a good one and thanks for stopping by.
August 14th, 2008 at 6:03 pm
Thanks for that step by step tutorial. Worked perfectly. I hadn’t used SuSE for about 7 years (SuSE 5.4 or 5.6 was the first Linux distro I ever got installed). I recently returned to using OpenSuSE 10.3 and have found it very good indeed. I have plans to use SuSE in a deployment of hundreds of servers.
September 10th, 2008 at 3:48 am
Nice Tutorial mate,
Saved my TAFE teacher an entire lessons prep!!
no but seriously, easy to follow and very quick to set up
September 10th, 2008 at 11:23 am
dude,
Thank you, glad I could help your teacher. Have a good one and thanks for stopping by.
May 21st, 2009 at 6:23 pm
Found it very useful while setting up openLDAP with TLS/SSL which need self-sign certificate.
Thank you.
May 31st, 2009 at 2:16 pm
I never cease to be amazed that we build a GUI Interface for everything, and we want people to use it, and yet when we get down to teaching others, we use the console prompt.
Dont get me wrong, I love my console prompt for a lot of things but we do have a
CA Manager that is an optional install in Yast -
which takes you through managing all your self signed certificates and pars etc.
Why dont we teach people how to use the CA Manager in Yast.
One other thing that I thought I would mention is , if you use a self signed SSL Server/Client certificate, every user will be asked to ‘TRUST and ACCEPT’ a certificate of ‘unknown origin who’s validity cannot be obtained’…well something like that warning.
Not every one is going to trust your self signed SSL client part of the SSL Server Certificate – Some people will only accept a Server/Client certificate that is validated by a CA.
The other issue with self Signed SSL Server/Client Certificates is, once issued, I do not know of any mechanism to globally revoke them.
The advantage with a CA issued certificate is that you have the authority to instruct your CA to revoke the certificate should it start to be mischievously used.
Dont get me wrong, self signed SSL Server/Client certificates have their place, but personally I would have an issue when anyone asked me for me credit card number by an untrusted certificate that was not issued by a CA, mostly because anyone can create the pair, but more importantly the pair cannot be revoked.
Oh! I look forward to a lesson on how to use the CA Manager in Yast, particularly as we can then cover the hierarchical structure of certificates and their pairs with the graphic illustration and graphic tools.
I must say, all credit to you for tackling a hugely complex subject so very well and I look forward to a tutorial on S/MIME X.509 Email certificate creation and use.
Well Done!!!!!!
May 31st, 2009 at 9:29 pm
Absolutely not ideal for all situations, to be sure. Especially for customers with credit card data, as you mentioned. Absolutely great point. However, when you need quick and dirty encryption between a satellite office and your intranet, it will work in a pinch.
Thanks for the message and thoughts. Great points. Thanks for stopping by.
June 10th, 2009 at 3:13 am
Have tried Yast, but as I hadn’t a clue what I was trying to do, I wasn’t very happy using it. Having been thru this process with its explanations I now feel a lot more confident knowing that I have something that will work on other distros as well as a suse system in single user mode for recovery. Next time I’ll probably use Yast to save getting my notes out, but will at least understand what its trying to do. Thanks for the excellent posting.
June 11th, 2009 at 9:25 pm
Peter,
Thank you. Glad you found it helpful. And yeah, I did try to make it non-distro-specific where I could. Thanks for stopping by.
June 11th, 2009 at 9:26 pm
Vavai,
Glad it was helpful. Thanks for stopping by!
June 18th, 2009 at 10:13 am
[...] Article By: SuseBlog [...]