© The Author(s), under exclusive license to APress Media, LLC, part of Springer Nature 2022
D. J. HarknessApache Essentialshttps://doi.org/10.1007/978-1-4842-8324-0_5

5. Securing Your Setup

Darren James Harkness1  
(1)
Port Coquitlam, BC, Canada
 

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

Let’s use Homebrew to install Certbot. Open your terminal and type the following.
brew install certbot

This downloads the latest version of Certbot and installs it on your system.

On Linux

On Linux, you need to install Certbot with your package manager. Open a terminal and type the following.
sudo apt-get install certbot

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.

If you’ve already set up Apache for your local subdomains, you can run Certbot with the Apache plugin. Open a terminal and type the following.
sudo certbot certonly —apache

This reads your Apache configuration files and lets you select which configuration to generate a certificate for.

Here’s an example for the subdomain local.apachebook.com.
sudo certbot certonly —apache
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator apache, Installer apache
Which names would you like to activate HTTPS for?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -- - - -
1: local.apachebook.com
2: errors.local
3: nodeapp.local
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  - - - - -
Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel): 1
Cert not yet due for renewal
You have an existing certificate that has exactly the same domains or certificate name you requested and isn't close to expiry.
(ref: /etc/letsencrypt/renewal/local.apachebook.com.conf)
What would you like to do?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  - - - - -
1: Keep the existing certificate for now
2: Renew & replace the certificate (may be subject to CA rate limits)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -- - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2
Renewing an existing certificate for local.apachebook.com
IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/local.apachebook.com/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/local.apachebook.com/privkey.pem
   Your certificate will expire on 2022-08-13. To obtain a new or
   tweaked version of this certificate in the future, simply run
   certbot again. To non-interactively renew *all* of your
   certificates, run "certbot renew"
 - If you like Certbot, please consider supporting our work by:
   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

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.

Now that Certbot has run and installed the new certificates, you can configure Apache by jumping to the “Configuring Apache for HTTPS” section later in this chapter. The certificate you created is stored in the location indicated in Table 5-1, depending on your operating system. Write it down so you can reference it in that section.
Table 5-1

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

Note

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

On macOS, you use Homebrew to install OpenSSL. Open a terminal and type the following.
brew install openssl

Linux

On Ubuntu, OpenSSL is available via its package manager. Open a terminal and type the following.
sudo apt-get install openssl

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.

For UNIX and macOS X systems, your best place to store these is in the /etc/ssl directory. For Windows, store them in the C:OpenSSLca folder.
  1. 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.

     
mkdir –p /etc/ssl/ca/private
  1. 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.

     
chown -R root /etc/ssl/ca/

Generating the CA Private Key

Now that they have a place to go, you can create the key files for the CA. To do so, you must use the OpenSSL utility, supplied with the OpenSSL libraries. To start this tool, change to the directory you just created and type openssl.
dev:/etc/ssl# openssl
Note

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.

To generate an RSA key, run the genrsa command. It takes three parameters: -des3, which selects TripleDES as the encryption format; -out, which specifies the filename to write the RSA key to; and finally, a bit-length for the encrypted key. The recommended bit-length is 2048. As part of the process, you are asked for a password for the private key. Enter a unique, hard-to-guess password for your CA private key. Anyone who gains access to this password can create new certificates using this key, allowing them to successfully identify themselves as your server.
OpenSSL> genrsa –des3 -out ca.key 2048
When you run the command, the utility displays a bunch of information on the screen.
warning, not much extra random data, consider using the -rand option
Generating RSA private key, 1024 bit long modulus
........................++++++
....++++++
e is 65537 (0x10001)
Enter PEM pass phrase:
Verifying password - Enter PEM pass phrase:
OpenSSL>

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.

To create the public CA certificate, you must use OpenSSL utility’s req command. The req command takes three parameters: -new tells OpenSSL to create a new key; -key tells it which CA key to base it on, and -out specifies the file to which the certificate is written.
OpenSSL> req -new -x509 -days 365 -key ca.key -out ca.crt
When run, the req command asks for some information about your installation. The following is an example of the type of information it asks for and sample responses. You can leave fields blank if you wish, but the more information you supply with the certificate, the more confidence the end users have that it is secure.
Using configuration from /usr/lib/ssl/openssl.cnf
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]:CA
State or Province Name (full name) [Some-State]:British Columbia
Locality Name (eg, city) []:Port Coquitlam
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Apache Essentials
Organizational Unit Name (eg, section) []:
Common Name (eg, YOUR name) []:localhost
Email Address []:[email protected]
OpenSSL>
A new key, ca.csr, is written to the directory, and you are returned to the OpenSSL> prompt. Before you can use this new public key, you must sign it. The x509 command does this. The following command makes a new certificate (ca.crt) that expires after one year (365 days). After it expires, you must generate a new CA public key. The following shows the syntax of the x509 command and its output.
OpenSSL> x509 -req -days 365 -in ca.csr -signkey ca.key -out ca.crt
Signature ok
subject=/C=CA/ST=Alberta/L=Edmonton/O=Apache Essentials/OU=Admin/CN=Darren James Harkness/[email protected]
Getting Private key
OpenSSL>

Signing Your Own Certificates

In most OpenSSL distributions, a script named sign.sh is included. This script signs new certificates from the CA. There are a couple of things you need to make sure of before running the sign.sh script.
  1. 1.

    Ensure that you have created a server private key and a certificate request file (server.csr).

     
  2. 2.

    Copy the server.csr file to the CA private directory (/etc/ssl/ca/private).

     
Once you’ve got everything in the right place, you can run the sign.sh script, and tell it which file to sign. It looks something like the following.
./sign.sh server.csr
Here’s a sample of the sign.sh script output.
CA signing: server.csr -> server.crt.
Using configuration from ca.config
Check that the request matches the signature
Signature ok
The Subjects Distinguished Name is as follows
countryName           :PRINTABLE:'CA'
stateOrProvinceName   :PRINTABLE:'British Columbia'
localityName          :PRINTABLE:'Port Coquitlam'
organizationName      :PRINTABLE:'Apache Essentials'
commonName            :PRINTABLE:'http://apache.local'
emailAddress          :IA5STRING:'[email protected]'
Certificate is to be certified until May  1 00:49:36 2023 GMT (365 days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
CA verifying: server.crt <-> CA cert
server.crt: OK

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

If you don’t have a sign.sh script, you can create it using the following code.
#!/bin/sh
##
##  sign.sh -- Sign a SSL Certificate Request (CSR)
##  Copyright (c) 1998-2001 Ralf S. Engelschall, All Rights Reserved.
##
#   argument line handling
CSR=-1
if [ -# -ne 1 ]; then
    echo "Usage: sign.sign <whatever>.csr"; exit 1
fi
if [ ! -f -CSR ]; then
    echo "CSR not found: -CSR"; exit 1
fi
case -CSR in
   *.csr ) CERT="`echo -CSR | sed -e 's/.csr/.crt/'`" ;;
       * ) CERT="-CSR.crt" ;;
esac
#   make sure environment exists
if [ ! -d ca.db.certs ]; then
    mkdir ca.db.certs
fi
if [ ! -f ca.db.serial ]; then
    echo '01' >ca.db.serial
fi
if [ ! -f ca.db.index ]; then
    cp /dev/null ca.db.index
fi
#   create an own SSLeay config
cat >ca.config <<EOT
[ ca ]
default_ca              = CA_own
[ CA_own ]
dir                     = .
certs                   = -dir
new_certs_dir           = -dir/ca.db.certs
database                = -dir/ca.db.index
serial                  = -dir/ca.db.serial
RANDFILE                = -dir/ca.db.rand
certificate             = -dir/ca.crt
private_key             = -dir/ca.key
default_days            = 365
default_crl_days        = 30
default_md              = md5
preserve                = no
policy                  = policy_anything
[ policy_anything ]
countryName             = optional
stateOrProvinceName     = optional
localityName            = optional
organizationName        = optional
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional
EOT
#  sign the certificate
echo "CA signing: -CSR -> -CERT:"
openssl ca -config ca.config -out -CERT -infiles -CSR
echo "CA verifying: -CERT <-> CA cert"
openssl verify -CAfile ca.crt -CERT
#  cleanup after SSLeay
rm -f ca.config
rm -f ca.db.serial.old
rm -f ca.db.index.old
#  die gracefully
exit 0

Configuring Apache for HTTPS

Now that you have generated SSL keys and certificates for your subdomain, you can configure Apache to use them. There are a few steps to this.
  1. 1.

    First, you must load the SSL module.

     
  2. 2.

    Next, you need to configure the global SSL options.

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

Obviously, before using SSL, you need to ensure that the mod_ssl module is loaded. This is done through two lines in ssl.conf.
LoadModule ssl_module /usr/lib/apache/1.3/mod_ssl.so
AddModule mod_ssl.c

Mac users find the module located at lib/httpd/modules/mod_ssl.so. Windows users find it at modules/ssl/mod_ssl.so.

The LoadModule directive tells the Apache server the module’s name and where it can find the files for it. Consult Table 5-2 to find the location on your operating system.
Table 5-2

Location of Apache Modules

Operating System

Location

Linux

/usr/lib/apache/modules/

macOS

/usr/local/lib/httpd/modules

Windows

C:xamppapachelib

Once the module is loaded, you need to add the module to the server. Use the AddModule directive to do so. Here is an example of adding the SSL module to httpd.conf for Linux.
# Depends: setenvif mime socache_shmcb
LoadModule ssl_module /usr/lib/apache2/modules/mod_ssl.so
Note

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.

There are three ways to configure this directive, but only one that is useful for UNIX, Windows, and macOS users: sem. This uses a common lock file format that works across all operating systems.
SSLMutex sem
If, for some reason, sem doesn’t work on your system, you can specify a location for the lock file by using the file option. This would look something like the following.
SSLMutex file:/var/log/apache/ssl_mutex

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.

More than one SSLRandomSeed directive can be configured—and it’s recommended.
SSLRandomSeed startup builtin
SSLRandomSeed startup file:/dev/urandom 1024
SSLRandomSeed connect file:/dev/urandom 1024
Next, you need to tell Apache how to deal with its session cache. By default, SSL already handles its own session cache. However, if you’re running an extremely busy site, you may notice some performance issues with the default session cache. The mod_ssl documentation says that the SSLSessionCache directive is useful when parallel requests are made; that is, when requests for a page and the graphics within it are made. The default value for this is
SSLSessionCache none

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.

If you decide to enable SSLSessionCache, use the following syntax.
SSLSessionCache dbm:/var/log/apache/ssl_cache
SSLSessionCache shm:/var/log/apache/ssl_cach(256000)
Finally, you need to tell Apache where to save its log data for secure connections. This is identical to the ErrorLog configuration discussed in another chapter.
SSLLog /var/logs/apache/ssl.log
SSLLogLevel info
The next chapter talks about configuring custom access logs. When the mod_ssl module is installed on your server, you can extend custom access logs to SSL. The following log records the time, remote host, SSL protocol, the HTTP protocol and file requested, and finally, the amount of data transferred.
CustomLog logs/ssl_request "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x "%r" %b"
The mod_ssl module adds the ability to use a set of preconfigured server variables outlined in Table 5-3 (www.modssl.org/docs/2.8/ssl_reference.html#table4).
Table 5-3

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 ]

Your SSL configuration should look something like the following.
<IfModule mod_ssl.c>
        # Random Seeding
        SSLRandomSeed startup builtin
        SSLRandomSeed startup file:/dev/urandom 512
        SSLRandomSeed connect builtin
        SSLRandomSeed connect file:/dev/urandom 512
        # MIME configuration
        AddType application/x-x509-ca-cert .crt
        AddType application/x-pkcs7-crl .crl
       # How Apache configures dialogs in the terminal
        SSLPassPhraseDialog  exec:/usr/share/apache2/ask-for-passphrase
       # Session Caching
        SSLSessionCache         shmcb:-{APACHE_RUN_DIR}/ssl_scache(512000)
        SSLSessionCacheTimeout  300
       # Encryption algorithms
        SSLCipherSuite HIGH:!aNULL
        SSLProtocol all -SSLv3
</IfModule>

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.

In the end, your site configuration file should look like the following.
<IfModule mod_ssl.c>
<VirtualHost *:443>
    DocumentRoot "/var/www/sites/local.apachebook.com"
    ServerName local.apachebook.com
    # Other directives here
    ErrorLog -{APACHE_LOG_DIR}/local.apachebook.com-error.log
    CustomLog -{APACHE_LOG_DIR}/local.apachebook.com-access.log combined
    # SSL Configuration
    Include /etc/letsencrypt/options-ssl-apache.conf
    SSLCertificateFile /etc/letsencrypt/live/local.apachebook.com-0001/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/local.apachebook.com-0001/privkey.pem
</VirtualHost>
</IfModule>

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.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset