You use the secure web every day without even thinking about it. With privacy laws, trillions of dollars, euros, and yen, and corporate communications have grown exponentially over the past 20 years. It was important to find a way for information on the Internet to be transmitted securely. Browsers do this through HTTPS (HyperText Transfer Protocol Secure). Whenever you see a small lock beside the website’s name in your browser, you’re accessing it through HTTPS.
HTTPS uses a technology called Secure Socket Layers (SSL) that encrypts traffic between a web server and a web browser.
SSL at a Glance
SSL is used for much more than just serving websites securely. It protects confidential email and secure FTP sessions over the Internet and can be applied to other Internet communications. It’s basically an extremely complicated, prime number-driven form of pig Latin.
Netscape developed SSL in 1994 to solve a distinct problem. People discovered that the web wasn’t nearly as secure as they’d hoped. They had already started to want to use the Internet for something other than mindless entertainment and email joke lists. They wanted to start using it to sell merchandise, create employee-only sites, and conduct financial transactions. It was clear that standard HTTP wouldn’t cut it since all the data traveled on plain text. They needed a secure way to transfer information between the browser and the server.
Several people came up with solutions for the problem; since Netscape had the lion’s share of the browser market, their solution won. Netscape wanted to make SSL as seamless as possible for the user, beyond giving them a notice that they were about to enter a secure connection, the user shouldn’t have to do anything.
They achieved that goal: people use SSL daily without thinking about it. Unfortunately, if you want to configure Apache to support secure socket layers, you do have to think about it. So, let’s move on.
Configuring SSL for Subdomains
Configuring SSL for subdomains is much easier now than when this book's first edition was written. Two tools are now available that greatly simplify the process: LetsEncrypt and Certbot.
When the first edition of Apache Essentials was written, obtaining a secure certificate that worked with SSL was difficult and expensive. LetsEncrypt.org was created in 2012 to make it easier to set up secure websites, removing both financial and technical barriers to adoption. Certbot is a companion utility that automates registering and renewing SSL certificates from LetsEncrypt.
This section explains using these tools to create a signed certificate for your subdomain.
Installing Certbot
First, you need to install the Certbot application on your system. This tool registers and renews certificates from LetsEncrypt and installs them in Apache for you.
On macOS
This downloads the latest version of Certbot and installs it on your system.
On Linux
On Windows
On Windows, you need to download the installer and install it on your system. You can find the current Windows installer at https://certbot.eff.org.
Running Certbot
Once Certbot is installed, you can run it to generate a certificate for your subdomains.
This reads your Apache configuration files and lets you select which configuration to generate a certificate for.
Pay attention to those important notes at the end of Certbot’s output. It contains the full paths for the certificates it’s created (or renewed). Jot these paths down because you’ll use them later in this chapter.
Location of Certificate Files Downloaded by Certbot
Operating System | Location |
---|---|
macOS | /opt/etc/letsencrypt/live/subdomain.domain.tld/ |
Linux | /etc/letsencrypt/live/subdomain.domain.tld/ |
Windows | C:Certbotlivesubdomain.domain.tld |
Configuring HTTPS for Local Domains
Unfortunately, Certbot and LetsEncrypt aren’t available to use for localhost or domains ending in the .local TLD. For this, let’s dig into things in much more detail.
Setting up a Local SSL Certificate Authority
As I mentioned earlier, every certificate must have a certificate authority to verify its authenticity. If the authenticity of a certificate can’t be verified, then the browser won’t trust the connection. When you set up a local development environment and want to use SSL, you must set up your own certificate authority (CA).
Most browsers notify end users that the certificate they use does not come from a known CA. For your first visit to a local development environment, you must instruct your browser to trust and install the certificate.
Installing OpenSSL
Local SSL certificates are managed through an application called OpenSSL. You must install the OpenSSL application on your operating system to create and manage local certificates.
macOS
Linux
Windows
If you’re using XAMPP, you’re done! XAMPP comes preinstalled with a server certificate, and no additional configuration is required. OpenSSL is installed, however, and available at C:xamppapacheinopenssl.exe.
Storing Your Certificates
First, you must have a secure place to store your CA certificates and key files.
You find them in /usr/local/etc/openssl on macOS.
You find them in /etc/ssl on Linux.
You find them stored in c:xamppapacheconfssl.crt and C:xamppapacheconfssl.key on Windows.
- 1.
Create the certificate authority directory. In Linux, this should be stored in /etc/ssl/ca/private; in Windows, I’d suggest storing it in C:OpenSSLcaprivate. Create the CA private keys directory.
- 2.
Then, set the permissions of the certificate authority directory to be readable by root or administrator only. Nobody but the root user or administrator should have access to the directory that your root certificates are in. If other people can access the root certificates, they can use them to decode the encrypted data between the server and a browser. For Linux or macOS X, type the following at the command prompt.
Generating the CA Private Key
Windows users need to specify the full path to the OpenSSL utility, which is at C:xamppapacheinopenssl.exe.
After you start the OpenSSL utility, you are presented with an OpenSSL> prompt. Now, you can start entering commands to create your CA files. The first file you need to create is the actual key file. This file contains a random string that creates your encrypted data. There are several different encryption types. RSA is the most popular because it is the most supported encryption among browser makers.
Next, you must request a new certificate from the CA through the req command. This uses the CA’s private key and some distinct information about your installation to create a unique public certificate. This command creates the public key you distribute to your website users and creates new server certificates.
Creating a Public CA Certificate
The public CA certificate creates and/or signs new server certificates. This is also the file that is distributed to users of your server to authenticate that the server key is correct.
Signing Your Own Certificates
- 1.
Ensure that you have created a server private key and a certificate request file (server.csr).
- 2.
Copy the server.csr file to the CA private directory (/etc/ssl/ca/private).
When the server.crt file has been written, you can move it and the original server.key file to /etc/apache/ssl. Ensure that the server.key file is made readable only to root or the administrator. Review the “Creating a Public CA Certificate” section for more information on how to do this.
The sign.sh Script
Configuring Apache for HTTPS
- 1.
First, you must load the SSL module.
- 2.
Next, you need to configure the global SSL options.
- 3.
Finally, you need to configure the specific server options.
The next sections walk you through the final steps to getting an SSL server up and running.
Creating a Separate Configuration File
I’d suggest creating a separate configuration file for your SSL settings and naming it ssl.conf. This file contains your SSL server's directives and <Directory> statements. By keeping this file separate, you can easily make changes to it, without scrolling through your main httpd.conf to find the relevant sections.
Loading the SSL Module
Mac users find the module located at lib/httpd/modules/mod_ssl.so. Windows users find it at modules/ssl/mod_ssl.so.
Location of Apache Modules
Operating System | Location |
---|---|
Linux | /usr/lib/apache/modules/ |
macOS | /usr/local/lib/httpd/modules |
Windows | C:xamppapachelib |
The SSL module also requires that the setenvif, mime, and socache_shmcb modules be enabled in Apache.
Configuring the Apache’s SSL Module
Once you’ve loaded the module, you can start configuring it for use in Apache.
Configuring the Global Options
First, you must set up some default directives for the Apache server.
The first directive is SSLMutex. This directive configures the SSL lock file, which stores session data used by Apache with regard to its operations. You can leave this unconfigured if you’re not using session data with your SSL server.
Next, you need to start the random seed generator through the SSLRandomSeed directive; this, combined with the certificate, ensures that the key to encrypt a session isn’t generated using a predictable number. Two parameters are passed to the SSLRandomSeed directive: the method to generate random numbers and the context where the random number generator is accessed.
There are several different methods available with the SSLRandomSeed directive, but only two that you use: builtin and file. The builtin method uses Apache’s internal pseudo-random number generator. The upside is that it doesn’t take any additional processor power away from your server. The downside is that it isn’t as secure as other methods. Windows users want to use this method since no random device exists on a Windows server.
The file: method is available to UNIX servers, but not Windows users, and uses the /dev/random or /dev/urandom devices. These devices are included with most UNIX servers and exist solely to generate random data. Since they are part of the operating system, neither of these devices takes extra processor time to run. If you add a number after the file: method, this limits the amount of data returned from the random device.
Two contexts are available for the SSLRandomSeed directive: startup and connect. The startup context starts the random generator when Apache starts; the connect context starts it when an SSL connection is initiated.
If your server is experiencing performance issues, you may want to enable the SSLSessionCache option. There are two options you can use: dbm and shm. The dbm option is recommended in the mod_ssl documentation and promises a noticeable speed increase. The shm option gives an even higher performance increase, as it stores the session data to a configured amount of RAM instead of to disk. However, it’s not supported by every operating system, so you may be unable to use it.
SSL Server Variables
Variable | Type | Description |
---|---|---|
HTTPS | flag | HTTPS is being used |
SSL_PROTOCOL | String | The SSL protocol version |
SSL_SESSION_ID | string | The hex-encoded SSL session ID |
SSL_CIPHER | string | The cipher specification name |
SSL_CIPHER_EXPORT | string | true if cipher is an export cipher |
SSL_CIPHER_USEKEYSIZE | number | Number of cipher bits (actually used) |
SSL_CIPHER_ALGKEYSIZE | number | Number of cipher bits (possible) |
SSL_VERSION_INTERFACE | string | The mod_ssl program version |
SSL_VERSION_LIBRARY | string | The OpenSSL program version |
SSL_CLIENT_M_VERSION | string | The version of the client certificate |
SSL_CLIENT_M_SERIAL | string | The serial of the client certificate |
SSL_CLIENT_S_DN | string | Subject DN in client's certificate |
SSL_CLIENT_S_DN_x509 | string | Component of client's Subject DN |
SSL_CLIENT_I_DN | string | Issuer DN of client's certificate |
SSL_CLIENT_I_DN_x509 | string | Component of client's Issuer DN |
SSL_CLIENT_V_START | string | Validity of client’s certificate (start time) |
SSL_CLIENT_V_END | string | Validity of client's certificate (end time) |
SSL_CLIENT_A_SIG | string | Algorithm for the signature of client's certificate |
SSL_CLIENT_A_KEY | string | Algorithm for the public key of client's certificate |
SSL_CLIENT_CERT | string | PEM-encoded client certificate |
SSL_CLIENT_CERT_CHAINn | string | PEM-encoded certificates in the client certificate chain |
SSL_CLIENT_VERIFY | string | NONE, SUCCESS, GENEROUS or FAILED:reason |
SSL_SERVER_M_VERSION | string | The version of the server certificate |
SSL_SERVER_M_SERIAL | string | The serial of the server certificate |
SSL_SERVER_S_DN | string | Subject DN in server's certificate |
SSL_SERVER_S_DN_x509 | string | Component of server's Subject DN |
SSL_SERVER_I_DN | string | Issuer DN of server's certificate |
SSL_SERVER_I_DN_x509 | string | Component of server's Issuer DN |
SSL_SERVER_V_START | string | Validity of server's certificate (start time) |
SSL_SERVER_V_END | string | Validity of server's certificate (end time) |
SSL_SERVER_A_SIG | string | Algorithm for the signature of server's certificate |
SSL_SERVER_A_KEY | string | Algorithm for the public key of server's certificate |
SSL_SERVER_CERT | string | PEM-encoded server certificate |
[ where x509 is a component of a X.509 DN: C,ST,L,O,OU,CN,T,I,G,S,D,UID,Email ] |
Configuring the Secure Site in Apache
Now that you have the global SSL settings, you must tell Apache about the SSL server. This follows the form of a virtual host, which was covered in the previous chapter; in fact, Apache makes complete use of its virtual host functionality to configure SSL, and all directives used for virtual hosts are available for SSL servers. One difference, however, is that SSL-specific directives are included in the <VirtualHost> section.
The SSLEngine directive turns the SSL module on for this site; without this option set, you don’t have a secure server. So don’t forget this directive!
Next, you need to tell Apache where the certificate and certificate key files are. You should have noted these in the previous sections of this chapter. The SSLcertificateFile directive tells the server where the public certificate file is located. If you remember, these files were obtained from Certbot and LetsEncrypt, or by becoming our own certificate authority, and placed in the /etc/ssl directory.
Once you have Apache configured and your server key and the public certificate installed, you can restart Apache and test your secure server. Test the server by loading it up using the https:// prefix. For example, if your server existed at http://local.apachebook.com, you would load the secure server by loading https://local.apachebook.com in your browser.
If everything works well, you should see your page and a lock icon next to the URL in your browser window that indicates you are connected to a secure server.
Summing It Up
In this chapter, you learned about SSL and how to use it to secure your Apache web server. It covered securing your Apache web server easily through LetsEncrypt and Certbot and how to create a manual certificate for domains that LetsEncrypt can’t reach. You now know how to install the certificate on your computer or server and how to configure Apache for it.
The next chapter covers the last piece of Apache’s configuration, log files. You learn about what they are, how to configure them in Apache, and how they can be useful for your projects.