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 http://.
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.
HINT: For More Information
To learn more about concepts and definitions of SSL/TSL, refer to http://httpd.apache.org/docs/2.2/ssl/ssl_intro.html.
DummyCertificate
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.
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.
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.
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 (http://www.thawte.com/) or Verisign (http://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.
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.
IMPORTANT: Firewall Configuration
Do not forget to open the firewall for SSL-enabled Apache on port 443. This can be done with YaST as described in Section 35.4.1, Configuring the Firewall with YaST.
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, it should be sufficient to adjust the values for the following directives:
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.