At long last, my wonderful readers, here is your promised OpenSSL how-to for Apache, and next week you get SSL for Dovecot. In this two-part series, we’ll learn how to create our own OpenSSL certificates and how to configure Apache and Dovecot to use them.
The examples here build on these tutorials:
- Apache on Ubuntu Linux For Beginners
- Apache on Ubuntu Linux For Beginners: Part 2
- Apache on CentOS Linux For Beginners
Creating Your Own Certificate
Debian/Ubuntu/Mint store private keys and symlinks to certificates in
/etc/ssl. The certificates bundled with your system are kept in
/usr/share/ca-certificates. Certificates that you install or create go in
This example for Debian/etc. creates a private key and public certificate, converts the certificate to the correct format, and symlinks it to the correct directory:
$ sudo openssl req -x509 -days 365 -nodes -newkey rsa:2048 -keyout /etc/ssl/private/test-com.key -out /usr/local/share/ca-certificates/test-com.crt Generating a 2048 bit RSA private key .......+++ ......................................+++ writing new private key to '/etc/ssl/private/test-com.key' ----- 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) :Seattle Organization Name (eg, company) [Internet Widgits Pty Ltd]:Alrac Writing Sweatshop Organizational Unit Name (eg, section) :home dungeon Common Name (e.g. server FQDN or YOUR name) :www.test.com Email Address :email@example.com $ sudo update-ca-certificates Updating certificates in /etc/ssl/certs... 1 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.d... Adding debian:test-com.pem done. done.
CentOS/Fedora use a different file structure and don’t use
update-ca-certificates, so use this command:
$ sudo openssl req -x509 -days 365 -nodes -newkey rsa:2048 -keyout /etc/httpd/ssl/test-com.key -out /etc/httpd/ssl/test-com.crt
The most important item is the Common Name, which must exactly match your fully qualified domain name. Everything else is arbitrary.
-nodes creates a password-less certificate, which is necessary for Apache.
- days defines an expiration date. It’s a hassle to renew expired certificates, but it supposedly provides some extra security. See Pros and cons of 90-day certificate lifetimes for a good discussion.
Now configure Apache to use your new certificate. If you followed Apache on Ubuntu Linux For Beginners: Part 2, all you do is modify the
SSLCertificateKeyFile lines in your virtual host configuration to point to your new private key and public certificate. The
test.com example from the tutorial now looks like this:
SSLCertificateFile /etc/ssl/certs/test-com.pem SSLCertificateKeyFile /etc/ssl/private/test-com.key
CentOS users, see Setting up an SSL secured Webserver with CentOS in the CentOS wiki. The process is similar, and the wiki tells how to deal with SELinux.
Testing Apache SSL
The easy way is to point your web browser to https://yoursite.com and see if it works. The first time you do this you will get the scary warning from your over-protective web browser how the site is unsafe because it uses a self-signed certificate. Ignore your hysterical browser and click through the nag screens to create a permanent exception. If you followed the example virtual host configuration in Apache on Ubuntu Linux For Beginners: Part 2 all traffic to your site will be forced over HTTPS, even if your site visitors try plain HTTP.
The cool nerdy way to test is by using OpenSSL. Yes, it has a nifty command for testing these things. Try this:
$ openssl s_client -connect www.test.com:443 CONNECTED(00000003) depth=0 C = US, ST = WA, L = Seattle, O = Alrac Writing Sweatshop, OU = home dungeon, CN = www.test.com, emailAddress = firstname.lastname@example.org verify return:1 --- Certificate chain 0 s:/C=US/ST=WA/L=Seattle/O=Alrac Writing Sweatshop/OU=home dungeon/CN=www.test.com/emailAddressemail@example.com i:/C=US/ST=WA/L=Seattle/O=Alrac Writing Sweatshop/OU=home dungeon/CN=www.test.com/emailAddressfirstname.lastname@example.org --- Server certificate -----BEGIN CERTIFICATE----- [...]
This spits out a giant torrent of information. There is a lot of nerdy fun to be had with
openssl s_client; for now it is enough that we know if our web server is using the correct SSL certificate.
Creating a Certificate Signing Request
Should you decide to use a third-party certificate authority (CA), you will have to create a certificate signing request (CSR). You will send this to your new CA, and they will sign it and send it back to you. They may have their own requirements for creating your CSR; this a typical example of how to create a new private key and CSR:
$ openssl req -newkey rsa:2048 -nodes -keyout yourdomain.key -out yourdomain.csr
You can also create a CSR from an existing key:
$ openssl req -key yourdomain.key -new -out domain.csr
That is all for today. Come back next week to learn how to properly set up Dovecot to use OpenSSL.
Advance your career in system administration! Check out the Essentials of System Administration course from The Linux Foundation.