|
 |
|
| |
28.6 Setting Up a Secure Web Server with SSL
Whenever sensitive data, such as credit card information, is transferred
between Web server and client, it would be desirable to have a secure,
encrypted connection with authentication. mod_ssl provides strong
encryption using the secure sockets layer (SSL) and transport layer
security (TLS) protocols for HTTP communication between a client and the
Web server. Using SSL/TSL, a private connection between Web server and
client is established. Data integrity is ensured and client and server
are able to authenticate each other.
For this purpose, the server sends an SSL certificate that holds
information proving the server's valid identity before any request to a
URL is answered. In turn, this guarantees that the server is the uniquely
correct end point for the communication. Additionally, the certificate
generates an encrypted connection between client and server that can
transport information without the risk of exposing sensitive, plain-text
content.
mod_ssl does not implement the SSL/TSL protocols itself, but acts as an
interface between Apache and an SSL library. In
openSUSE,
the OpenSSL library is used. OpenSSL is automatically installed with
Apache.
The most visible effect of using mod_ssl with Apache is that URLs are
prefixed with https:// instead of
https://.
28.6.1 Creating an SSL Certificate
In order to use SSL/TSL with the Web server, you need to create an SSL
certificate. This certificate is needed for the authorization between
Web server and client, so that each party can clearly identify the other
party. To ensure the integrity of the certificate, it must be signed by
a party every user trusts.
There are three types of certificates you can create: a
dummy certificate for testing purposes only, a
self-signed certificate for a defined circle of users that trust you,
and a certificate signed by an independent, publicly-known certificate
authority (CA).
Creating a certificate is basically a two step process. First, a private
key for the certificate authority is generated then the server
certificate is signed with this key.
Creating a Dummy Certificate
Generating a dummy certificate is simple. Just call the script
/usr/bin/gensslcert. It creates or overwrites the
following files:
-
/etc/apache2/ssl.crt/ca.crt
-
/etc/apache2/ssl.crt/server.crt
-
/etc/apache2/ssl.key/server.key
-
/etc/apache2/ssl.csr/server.csr
A copy of ca.crt is also placed at
/srv/www/htdocs/CA.crt for download.
IMPORTANT:
A dummy certificate should never be used on a production system. Only
use it for testing purposes.
Creating a Self-Signed Certificate
If you are setting up a secure Web server for an Intranet or for a
defined circle of users, it might be sufficient if you sign a
certificate with your own certificate authority (CA).
Creating a self-signed certificate is an interactive nine-step process.
Change into the directory
/usr/share/doc/packages/apache2 and run the
following command: ./mkcert.sh make --no-print-directory
/usr/bin/openssl /usr/sbin/ custom. Do not attempt to run
this command from outside this directory. The program provides a series
of prompts, some of which require user input.
Creating a Self-Signed Certificate with mkcert.sh
-
Decide the signature algorithm used for certificates
Choose RSA (R, the default), because some older
browsers have problems with DSA.
-
Generating RSA private key for CA (1024 bit)
No interaction needed.
-
Generating X.509 certificate signing request for
CA
Create the CA's distinguished name here. This requires you to answer
a few questions, such as country name or organization name. Enter
valid data, because everything you enter here later shows up in the
certificate. You do not need to answer every question. If one does
not apply to you or you want to leave it blank, use . .
Common name is the name of the CA itself—choose a significant
name, such as My company CA.
-
Generating X.509 certificate for CA signed by
itself
Choose certificate version 3 (the default).
-
Generating RSA private key for SERVER (1024 bit)
No interaction needed.
-
Generating X.509 certificate signing request for
SERVER
Create the distinguished name for the server key here. Questions are
almost identical to the ones already answered for the CA's
distinguished name. The data entered here applies to the Web server
and does not necessarily need to be identical to the CA's data (for
example, if the server is located elsewhere).
IMPORTANT: Selecting a Common Name
The common name you enter here must be the fully qualified hostname
of your secure server (for example, www.example.com). Otherwise the
browser issues a warning that the certificate does not match the
server when accessing the Web server.
-
Generating X.509 certificate signed by own CA
Choose certificate version 3 (the default).
-
Encrypting RSA private key of CA with a pass phrase for
security
It is strongly recommended to encrypt the private key of the CA with
a password, so choose Y and enter a password.
-
Encrypting RSA private key of SERVER with a pass phrase for
security
Encrypting the server key with a password requires you to enter this
password every time you start the Web server. This makes it difficult
to automatically start the server on boot or to restart the Web
server. Therefore, it is common sense to say N to
this question. Keep in mind that your key is unprotected when not
encrypted with a password and make sure that only authorized persons
have access to the key.
IMPORTANT: Encrypting the Server Key
If you choose to encrypt the server key with a password, increase
the value for APACHE_TIMEOUT in
/etc/sysconfig/apache2. Otherwise you do not
have enough time to enter the passphrase before the attempt to start
the server is stopped unsuccessfully.
The script's result page presents a list of certificates and keys it
has generated. Contrary to what the script outputs, the files have not
been generated in the local directory conf, but to
the correct locations under /etc/apache2/.
The last step is to copy the CA certificate file from
/etc/apache2/ssl.crt/ca.crt to a location where
your users can access it in order to incorporate it into the list of
known and trusted CAs in their Web browsers. Otherwise a browser
complains that the certificate was issued by an unknown authority. The
certificate is valid for one year.
IMPORTANT: Self-Signed Certificates
Only use a self-signed certificate on a Web server that is accessed by
people who know and trust you as a certificate authority. It is not
recommended to use such a certificate on a public shop, for example.
Getting an Officially Signed Certificate
There are a number of official certificate authorities that sign your
certificates. The certificate is signed by a trustworthy third party,
so can be fully trusted. Publicly operating secure Web servers usually
have got an officially signed certificate.
The best-known official CAs are Thawte
(https://www.thawte.com/) or Verisign
(https://www.verisign.com). These and other CAs are
already compiled into all browsers, so certificates signed by these
certificate authorities are automatically accepted by the browser.
When requesting an officially signed certificate, you do not send a
certificate to the CA. Instead, issue a Certificate Signing Request
(CSR). To create a CSR, call the script
/usr/share/ssl/misc/CA.sh -newreq.
First the script asks for a password with which the CSR should be
encrypted. Then you are asked to enter a distinguished name. This
requires you to answer a few questions, such as country name or
organization name. Enter valid data—everything you enter here
later shows up in the certificate and is checked. You do not need to
answer every question. If one does not apply to you or you want to
leave it blank, use . . Common name is the name of the CA
itself—choose a significant name, such as My
company CA. Last, a challenge password and an alternative
company name must be entered.
Find the CSR in the directory from which you called the script. The
file is named newreq.pem.
28.6.2 Configuring Apache with SSL
The default port for SSL and TLS requests on the Web server side is 443.
There is no conflict between a regular Apache listening
on port 80 and an SSL/TLS-enabled Apache listening on port 443. In fact,
HTTP and HTTPS can be run with the same Apache instance. Usually
separate virtual hosts are used to dispatch requests to port 80 and port
443 to separate virtual servers.
To use SSL, it must be activated in the global server configuration.
Open /etc/sysconfig/apache2 in an editor and search
for APACHE_MODULES. Add ssl to
the list of modules if it is not already present (mod_ssl is activated
by default). Next, search for
APACHE_SERVER_FLAGS and add SSL .
If you have chosen to encrypt your server certificate with a password,
you should also increase the value for
APACHE_TIMEOUT, so you have enough time to
enter the passphrase when Apache starts. Restart the server to make
these changes active. A reload is not sufficient.
The virtual host configuration directory contains a template
/etc/apache2/vhosts.d/vhost-ssl.template with
SSL-specific directives that are extensively documented. Refer to
Virtual Host Configuration for the
general virtual host configuration.
To get started, copy the template to
/etc/apache2/vhosts.d/mySSL-host.conf
and edit it. Adjusting the values for the following directives should be
sufficient:
-
DocumentRoot
-
ServerName
-
ServerAdmin
-
ErrorLog
-
TransferLog
IMPORTANT: Name-Based Virtual Hosts and SSL
It is not possible to run multiple SSL-enabled virtual hosts on a
server with only one IP address. Users connecting to such a setup
receive a warning message stating that the certificate does not match
the server name every time they visit the URL. A separate IP address or
port is necessary for every SSL-enabled domain to achieve communication
based on a valid SSL certificate.
|
|
|
