Assurez-vous que les conditions suivantes sont remplies avec d'essayer de mettre en place le serveur web Apache :

Apache n'est pas installé par défaut sur openSUSE. Pour l'installer avec une configuration standard prédéfinie qui fonctionne « out of the box », procédez comme ci-dessous :

L'installation comprend le module de multitraitement apache2-prefork ainsi que le module PHP5. Reportez-vous à Section 20.4, « Installation, activation et configuration de modules » pour plus d'informations sur ces modules.

Vous pouvez lancer Apache automatiquement au démarrage ou le lancer manuellement.

Pour démarrer manuellement Apache avec le terminal, tapez rcapache2 start.

Maintenant que le serveur web fonctionne, vous pouvez ajouter vos propres documents, ajuster la configuration selon vos besoins, ou ajouter des fonctionnalités en installant des modules.

Cette section donne un aperçu des fichiers de configuration d'Apache. Si vous utilisez YaST pour la configuration, vous n'avez pas besoin de toucher à ces fichiers—cependant, ces informations peuvent vous être utiles si vous souhaitez passer à une configuration manuelle plus tard.

Les fichiers de configuration d'Apache peuvent être trouvés dans deux endroits différents :

/etc/apache2/
     |
     |- charset.conv 
     |- conf.d/
     |   |
     |   |- *.conf
     |
     |- default-server.conf
     |- errors.conf
     |- httpd.conf
     |- listen.conf
     |- magic
     |- mime.types
     |- mod_*.conf
     |- server-tuning.conf
     |- ssl.*
     |- ssl-global.conf
     |- sysconfig.d
     |   |
     |   |- global.conf
     |   |- include.conf
     |   |- loadmodule.conf . .
     |
     |- uid.conf
     |- vhosts.d
     |   |- *.conf

La configuration manuelle d'Apache nécessite la modification des fichiers textes de configuration en tant qu'utilisateur root.

20.2.2.1. Configuration de virtualhost¶

Le terme virtualhost fait référence à la capacité d'Apache de servir plusieurs URIs (Universal Resource Identifiers) depuis la même machine physique. Cela signifie que plusieurs domaines, comme www.example.com et www.example.net, sont gérés par un seul serveur web sur une seule machine physique.

Il est courant d'utiliser des virtualhosts pour réduire les tâches d'administration (un seul serveur web doit être maintenu) et les frais de matériel (chaque domaine ne nécessite pas un serveur dédié). Les virtualhosts peuvent être basés sur le nom, l'IP, ou le port.

Pour lister tous les virtualhosts existants, utilisez la commande httpd2 -S. Cela affiche une liste indiquant le serveur par défaut et tous les virtualhosts ainsi que leurs adresses IP et ports d'écoute. En outre, la liste contient aussi une entrée pour chaque virtualhost indiquant son emplacement dans les fichiers de configuration.

Les virtualhosts peuvent être configurés avec YaST comme décrit dans Section 20.2.3.1.4, « Virtual Hosts » ou en éditant manuellement un fichier de configuration. Par défaut, Apache est préparé dans openSUSE pour utiliser un fichier de configuration par virtualhost dans /etc/apache2/vhosts.d/. Tous les fichiers de ce répertoire possédant l'extension .conf sont automatiquement inclus dans la configuration. Un modèle de virtualhost basique est fourni dans ce répertoire (vhost.template ou vhost-ssl.template pour un virtualhost avec le support de SSL).

Toujours créer une configuration de virtualhost

Il est recommandé de toujours créer un fichier de configuration de virtualhost, même si votre serveur web n'héberge qu'un seul domaine. En faisant cela, vous avez non seulement la configuration spécifique au domaine dans un fichier, mais vous pouvez également toujours revenir à une configuration fonctionnelle de base en déplaçant, supprimant ou renommant simplement le fichier de configuration du virtualhost. Pour la même raison, vous devez également créer des fichiers de configuration séparés pour chaque virtualhost. Lors de l'utilisation de virtualhosts basés sur le nom, il est recommandé de mettre en place une configuration par défaut qui sera utilisée quand un nom de domaine ne correspond pas à une configuration de virtualhost. Le virtualhost par défaut est celui dont la configuration est chargée en premier. Étant donné que l'ordre des fichiers de configuration est déterminé par le nom de fichier, débutez le nom du fichier de configuration du virtualhost par défaut avec un caractère underscore (_) pour vous assurer qu'il soit chargé en premier (par exemple : _default_vhost.conf).

Le bloc <VirtualHost></VirtualHost> comprend les informations qui s'appliquent à un domain particulier. Quand Apache reçoit la demande d'un client pour un virtualhost défini, il utilise les directives incluses dans cette section. Presque toutes les directives peuvent être utilisées dans le contexte d'un virtualhost. Pour plus d'informations sur les directives de configuration d'Apache, consultez http://httpd.apache.org/docs/2.2/mod/quickreference.html.

20.2.2.1.1. Virtualhosts basés sur le nom¶

Avec des virtualhosts basés sur le nom, plusieurs sites web peuvent être desservis par adresse IP. Apache utilise le champ d'hôte dans l'en-tête HTTP qui est envoyée par le client pour connecter la requête à une entrée ServerName correspondante dans l'une des déclarations de virtualhost. Si aucun ServerName correspondant n'est trouvé, le premier virtualhost spécifié est utilisé comme valeur par défaut.

La directive NameVirtualHost indique à Apache sur quelle adresse IP, et éventuellement, quel port il doit écouter pour les requêtes de clients contenant le nom de domaine dans l'en-tête HTTP. Cette option est configurée dans le fichier de configuration /etc/apache2/listen.conf.

Le premier argument peut être un nom de domaine pleinement qualifié (FQDN, Fully Qualified Domain Name), mais il est recommandé d'utiliser l'adresse IP. Le second argument est le port, mais il est optionnel. Par défaut, le port 80 est utilisé et configuré via la directive Listen.

Le joker * peut être utilisé aussi bien pour l'adresse IP que pour le numéro de port afin de recevoir les requêtes sur toutes les interfaces. Les adresses IPv6 doivent être définies entre crochets.

Exemple 20.1. Variations of Name-Based VirtualHost Entries¶

# NameVirtualHost Adresse IP[:Port]
NameVirtualHost 192.168.3.100:80
NameVirtualHost 192.168.3.100
NameVirtualHost *:80
NameVirtualHost *
NameVirtualHost [2002:c0a8:364::]:80

The opening VirtualHost tag takes the IP address (or fully qualified domain name) previously declared with the NameVirtualHost as an argument in a name-based virtual host configuration. A port number previously declared with the NameVirtualHost directive is optional.

Le joker * est aussi autorisé comme substitut pour l'adresse IP. Cette syntaxe n'est valable qu'en association avec l'utilisation du joker dans NameVirtualHost *. Lorsque vous utilisez des adresses IPv6, l'adresse doit figurer entre crochets.

Exemple 20.2. Directives VirtualHost basées sur le nom¶

<VirtualHost 192.168.3.100:80>
  ...
</VirtualHost>

<VirtualHost 192.168.3.100>
  ...
</VirtualHost>

<VirtualHost *:80>
  ...
</VirtualHost>

<VirtualHost *>
  ...
</VirtualHost>

<VirtualHost [2002:c0a8:364::]>
  ...
</VirtualHost>

20.2.2.1.2. Virtualhosts basés sur l'IP¶

Cette configuration de virtualhost alternative nécessite la configuration de plusieurs adresses IP pour une machine. Une seule instance d'Apache héberge plusieurs domaines, dont chacun se voit attribuer une IP différente.

Le serveur physique doit avoir une adresse IP pour chaque virtualhost basé sur l'IP. Si la machine ne dispose pas de plusieurs cartes réseau, des interfaces réseau virtuelles (IP aliasing) peuvent également être utilisées.

L'exemple suivant montre Apache fonctionnant sur une machine avec l'IP 192.168.3.100, hébergeant deux domaines sur les IP additionnelles 192.168.3.101 et 192.168.3.102. Un bloc VirtualHost séparé est nécessaire pour chaque serveur virtuel.

Exemple 20.3. Directives VirtualHost basées sur l'IP¶

<VirtualHost 192.168.3.101>
  ...
</VirtualHost>

<VirtualHost 192.168.3.102>
  ...
</VirtualHost>

Ici, les directives VirtualHost sont spécifiées uniquement pour les interfaces autres que 192.168.3.100. Quand une directive Listen est également configurée pour 192.168.3.100, un hôte virtuel distinct basé sur l'IP doit être créé pour répondre aux requêtes HTTP vers cette interface—dans le cas contraire, les directives trouvées dans la configuration par défaut du serveur (/etc/apache2/default-server.conf) sont appliquées.

20.2.2.1.3. Configuration de virtualhost basique¶

Au minimum, les directives suivantes doivent être présentes dans chaque configuration de virtualhost afin de mettre en place un virtualhost. Consultez /etc/apache2/vhosts.d/vhost.template pour plus d'informations.

ServerName

The fully qualified domain name under which the host should be addressed.

DocumentRoot

Path to the directory from which Apache should serve files for this host. For security reasons, access to the entire file system is forbidden by default, so you must explicitly unlock this directory within a Directory container.

ServerAdmin

Adresse e-mail de l'administrateur du serveur. Cette adresse apparait, par exemple, sur les pages d'erreur créées par Apache.

ErrorLog

The error log file for this virtual host. Although it is not necessary to create separate error log files for each virtual host, it is common practice to do so, because it makes the debugging of errors much easier. /var/log/apache2/ is the default directory for Apache's log files.

CustomLog

The access log file for this virtual host. Although it is not necessary to create separate access log files for each virtual host, it is common practice to do so, because it allows the separate analysis of access statistics for each host. /var/log/apache2/ is the default directory for Apache's log files.

Comme mentionné ci-dessus, l'accès à l'intégralité du système de fichiers est interdit par défaut pour des raisons de sécurité. Par conséquent, déverrouillez explicitement les répertoires dans lesquels vous avez placé les fichiers qu'Apache doit servir—par exemple le DocumentRoot :

<Directory "/srv/www/www.example.com/htdocs">
  Order allow,deny
  Allow from all
</Directory>

Le fichier de configuration complet ressemble à ceci :

Exemple 20.4. Configuration VirtualHost basique¶

<VirtualHost 192.168.3.100>
  ServerName www.example.com
  DocumentRoot /srv/www/www.example.com/htdocs
  ServerAdmin webmaster@example.com
  ErrorLog /var/log/apache2/www.example.com_log
  CustomLog /var/log/apache2/www.example.com-access_log common
  <Directory "/srv/www/www.example.com/htdocs">
    Order allow,deny
    Allow from all
  </Directory>
</VirtualHost>

To configure your Web server with YaST, start YaST and select Network Services+HTTP Server. When starting the module for the first time, the HTTP Server Wizard starts, prompting you to make a few basic decisions concerning administration of the server. After having finished the wizard, the HTTP Server Configuration dialog starts each time you call the HTTP Server module. For more information, see Section 20.2.3.2, « HTTP Server Configuration ».

20.2.3.1. HTTP Server Wizard¶

The HTTP Server Wizard consists of five steps. In the last step of the dialog, you are given the opportunity to enter the expert configuration mode to make even more specific settings.

20.2.3.1.1. Network Device Selection¶

Here, specify the network interfaces and ports Apache uses to listen for incoming requests. You can select any combination of existing network interfaces and their respective IP addresses. Ports from all three ranges (well-known ports, registered ports, and dynamic or private ports) that are not reserved by other services can be used. The default setting is to listen on all network interfaces (IP addresses) on port 80.

Check Open Port In Firewall to open the ports in the firewall that the Web server listens on. This is necessary to make the Web server available on the network, which can be a LAN, WAN, or the public Internet. Keeping the port closed is only useful in test situations where no external access to the Web server is necessary. If you have multiple network interfaces, click Firewall Details... to specify on which interface(s) the port(s) should be opened.

Click Next to continue with the configuration.

20.2.3.1.2. Modules¶

The Modules configuration option allows for the activation or deactivation of the script languages that the Web server should support. For the activation or deactivation of other modules, refer to Section 20.2.3.2.2, « Server Modules ». Click Next to advance to the next dialog.

20.2.3.1.3. Default Host¶

This option pertains to the default Web server. As explained in Section 20.2.2.1, « Configuration de virtualhost », Apache can serve multiple virtual hosts from a single physical machine. The first declared virtual host in the configuration file is commonly referred to as the default host. Each virtual host inherits the default host's configuration.

To edit the host settings (also called directives), choose the appropriate entry in the table then click Edit. To add new directives, click Add. To delete a directive, select it and click Delete.

Figure 20.1. HTTP Server Wizard: Default Host¶

Here is list of the default settings of the server:

Document Root

Path to the directory from which Apache serves files for this host. /srv/www/htdocs is the default location.

Alias

With the help of Alias directives, URLs can be mapped to physical file system locations. This means that a certain path even outside the Document Root in the file system can be accessed via a URL aliasing that path.

The default openSUSE Alias /icons points to /usr/share/apache2/icons for the Apache icons displayed in the directory index view.

ScriptAlias

Similar to the Alias directive, the ScriptAlias directive maps a URL to a file system location. The difference is that ScriptAlias designates the target directory as a CGI location, meaning that CGI scripts should be executed in that location.

Directory

With Directory settings, you can enclose a group of configuration options that will only apply to the specified directory.

Access and display options for the directories /srv/www/htdocs, /usr/share/apache2/icons and /srv/www/cgi-bin are configured here. It should not be necessary to change the defaults.

Include

With include, additional configuration files can be specified. Two Include directives are already preconfigured: /etc/apache2/conf.d/ is the directory containing the configuration files that come with external modules. With this directive, all files in this directory ending in .conf are included. With the second directive, /etc/apache2/conf.d/apache2-manual.conf, the apache2-manual configuration file is included.

Server Name

This specifies the default URL used by clients to contact the Web server. Use a fully qualified domain name (FQDN) to reach the Web server at http://FQDN/ or its IP address. You cannot choose an arbitrary name here—the server must be « known » under this name.

Server Administrator E-Mail

E-mail address of the server administrator. This address is, for example, shown on error pages Apache creates.

After finishing with the Default Host step, click Next to continue with the configuration.

20.2.3.1.4. Virtual Hosts¶

In this step, the wizard displays a list of already configured virtual hosts (see Section 20.2.2.1, « Configuration de virtualhost »). If you have not made manual changes prior to starting the YaST HTTP wizard, no virtual host is present.

To add a host, click Add to open a dialog in which to enter basic information about the host, such as Server Name, Server Contents Root (DocumentRoot), and the Administrator E-Mail. Server Resolution is used to determine how a host is identified (name based or IP based). Specify the name or IP address with Change Virtual Host ID

Clicking Next advances to the second part of the virtual host configuration dialog.

In part two of the virtual host configuration you can specify whether or not to enable CGI scripts and which directory to use for these scripts. It is also possible to enable SSL. If you do so, you must specify the path to the certificate as well. See Section 20.6.2, « Configuring Apache with SSL » for details on SSL and certificates. With the Directory Index option, you can specify which file to display when the client requests a directory (by default, index.html). Add one or more filenames (space-separated) if you want to change this. With Enable Public HTML, the content of the users public directories (~user/public_html/) is made available on the server under http://www.example.com/~user.

	Creating Virtual Hosts
It is not possible to add virtual hosts at will. If using name-based virtual hosts, each hostname must be resolved on the network. If using IP-based virtual hosts, you can assign only one host to each IP address available.

20.2.3.1.5. Summary¶

This is the final step of the wizard. Here, determine how and when the Apache server is started: when booting or manually. Also see a short summary of the configuration made so far. If you are satisfied with your settings, click Finish to complete configuration. If you want to change something, click Back until you have reached the desired dialog. Clicking HTTP Server Expert Configuration opens the dialog described in Section 20.2.3.2, « HTTP Server Configuration ».

Figure 20.2. HTTP Server Wizard: Summary¶

20.2.3.2. HTTP Server Configuration¶

The HTTP Server Configuration dialog also lets you make even more adjustments to the configuration than the wizard (which only runs if you configure your Web server for the first time). It consists of four tabs described in the following. No configuration option you change here is effective immediately—you always must confirm your changes with Finish to make them effective. Clicking Abort leaves the configuration module and discards your changes.

20.2.3.2.1. Listen Ports and Addresses¶

In HTTP Service, select whether Apache should be running (Enabled) or stopped (Disabled). In Listen on Ports, Add, Edit, or Delete addresses and ports on which the server should be available. The default is to listen on all interfaces on port 80. You should always check Open Port In Firewall, because otherwise the Web server is not reachable from outside. Keeping the port closed is only useful in test situations where no external access to the Web server is necessary. If you have multiple network interfaces, click Firewall Details... to specify on which interface(s) the port(s) should be opened.

With Log Files, watch either the access log or the error log. This is useful if you want to test your configuration. The log file opens in a separate window from which you can also restart or reload the Web server. For details, see Section 20.3, « Démarrage et arrêt d'Apache ». These commands are effective immediately and their log messages are also displayed immediately.

Figure 20.3. HTTP Server Configuration: Listen Ports and Addresses¶

20.2.3.2.2. Server Modules¶

You can change the status (enabled or disabled) of Apache2 modules by clicking Toggle Status. Click Add Module to add a new module that is already installed but not yet listed. Learn more about modules in Section 20.4, « Installation, activation et configuration de modules ».

Figure 20.4. HTTP Server Configuration: Server Modules¶

20.2.3.2.3. Main Host or Hosts¶

These dialogs are identical to the ones already described. Refer to Section 20.2.3.1.3, « Default Host » and Section 20.2.3.1.4, « Virtual Hosts ».

Si vous avez fait une installation par défaut comme décrit dans Section 20.1.2, « Installation », les modules suivants sont déjà installés : tous les modules de base et d'extension, le module multi-processus Prefork MPM, et les modules externes mod_php5 et mod_python.

Vous pouvez installer des modules externes supplémentaires en lançant YaST et en choisissant Logiciel+Installer et supprimer des logiciels. Choisissez maintenant Vue+Rechercher et cherchez apache. Parmi les autres paquets, la liste des résultats contient tous les modules externes disponibles pour Apache.

Activez ou désactivez des modules particuliers soit manuellement, soit avec YaST. Dans YaST, les modules de langage de script (PHP5, Perl, and Python) doivent être activés ou désactivés avec la configuration du module comme décrit dans Section 20.2.3.1, « HTTP Server Wizard ». Tous les autres modules peuvent être activés ou désactivés comme décrit dans Section 20.2.3.2.2, « Server Modules ».

Si vous préférez activer ou désactiver les modules manuellement, utilisez respectivement les commandes a2enmod mod_foo ou a2dismod mod_foo. a2enmod -l affiche une liste de tous les modules actuellement activés.

Inclusion de fichiers de configuration pour des modules externes

Si vous avez activé des modules externes manuellement, assurez-vous de charger leurs fichiers de configuration dans toutes les configurations de virtualhosts. Les fichiers de configuration pour les modules externes sont situés dans /etc/apache2/conf.d/ et ne sont pas chargés par défaut. Si vous avez besoin des mêmes modules dans chaque virtualhost, vous pouvez inclure *.conf à partir de ce répertoire. Dans le cas contraire, incluez les fichiers individuellement. Consultez /etc/apache2/vhost.d/vhost.template pour des exemples.

Tous les modules de base et d'extension sont décrits en détails dans la documentation Apache. Seule une brève description des principaux modules est disponible ici. Référez-vous à http://httpd.apache.org/docs/2.2/mod/ pour plus de détails sur chaque module.

openSUSE provides two different multiprocessing modules (MPMs) for use with Apache:

20.4.4.1. Prefork MPM¶

The prefork MPM implements a nonthreaded, preforking Web server. It makes the Web server behave similarly to Apache version 1.x. In this version it isolates each request and handles it by forking a separate child process. Thus problematic requests cannot affect others, avoiding a lockup of the Web server.

While providing stability with this process-based approach, the prefork MPM consumes more system resources than its counterpart, the worker MPM. The prefork MPM is considered the default MPM for Unix-based operating systems.

	MPMs in This Document
This document assumes Apache is used with the prefork MPM.

20.4.4.2. Worker MPM¶

The worker MPM provides a multi-threaded Web server. A thread is a « lighter » form of a process. The advantage of a thread over a process is its lower resource consumption. Instead of only forking child processes, the worker MPM serves requests by using threads with server processes. The preforked child processes are multi-threaded. This approach makes Apache perform better by consuming fewer system resources than the prefork MPM.

One major disadvantage is the stability of the worker MPM: if a thread becomes corrupt, all threads of a process can be affected. In the worst case, this may result in a server crash. Especially when using the Common Gateway Interface (CGI) with Apache under heavy load, internal server errors might occur due to threads being unable to communicate with system resources. Another argument against using the worker MPM with Apache is that not all available Apache modules are thread-safe and thus cannot be used in conjunction with the worker MPM.

	Using PHP Modules with MPMs
Not all available PHP modules are thread-safe. Using the worker MPM with mod_php is strongly discouraged.

Find a list of all external modules shipped with openSUSE here. Find the module's documentation in the listed directory.

Apache can be extended by advanced users by writing custom modules. To develop modules for Apache or compile third-party modules, the package apache2-devel is required along with the corresponding development tools. apache2-devel also contains the apxs2 tools, which are necessary for compiling additional modules for Apache.

apxs2 enables the compilation and installation of modules from source code (including the required changes to the configuration files), which creates dynamic shared objects (DSOs) that can be loaded into Apache at runtime.

The apxs2 binaries are located under /usr/sbin:

Install and activate a module from source code with the following commands:

cd /path/to/module/source; apxs2 -cia
    mod_foo.c

where -c compiles the module, -i installs it, and -a activates it. Other options of apxs2 are described in the apxs2(1) man page.

In openSUSE, the execution of CGI scripts is only allowed in the directory /srv/www/cgi-bin/. This location is already configured to execute CGI scripts. If you have created a virtual host configuration (see Section 20.2.2.1, « Configuration de virtualhost ») and want to place your scripts in a host-specific directory, you must unlock and configure this directory.

ScriptAlias /cgi-bin/ "/srv/www/www.example.com/cgi-bin/"

<Directory "/srv/www/www.example.com/cgi-bin/">
 Options +ExecCGI
 AddHandler cgi-script .cgi .pl
 Order allow,deny
 Allow from all
</Directory>

CGI programming differs from "regular" programming in that the CGI programs and scripts must be preceded by a MIME-Type header such as Content-type: text/html. This header is sent to the client, so it understands what kind of content it receives. Secondly, the script's output must be something the client, usually a Web browser, understands—HTML in most cases or plain text or images, for example.

A simple test script available under /usr/share/doc/packages/apache2/test-cgi is part of the Apache package. It outputs the content of some environment variables as plain text. Copy this script to either /srv/www/cgi-bin/ or the script directory of your virtual host (/srv/www/www.example.com/cgi-bin/) and name it test.cgi.

Files accessible by the Web server should be owned by the user root. For additional information see Section 20.7, « Avoiding Security Problems ». Because the Web server runs with a different user, the CGI scripts must be world-executable and world-readable. Change into the CGI directory and use the command chmod 755 test.cgi to apply the proper permissions.

Now call http://localhost/cgi-bin/test.cgi or http://www.example.com/cgi-bin/test.cgi. You should see the « CGI/1.0 test script report ».

If you do not see the output of the test program but an error message instead, check the following:

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.

	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.

20.6.1.1. Creating a « Dummy » Certificate¶

Generating a dummy certificate is simple. Just call the script /usr/bin/gensslcert. It creates or overwrites the files listed below. Make use of gensslcert's optional switches to fine-tune the certificate. Call /usr/bin/gensslcert -h for more information.

• /etc/apache2/ssl.crt/ca.crt

• /etc/apache2/ssl.crt/server.crt

• /etc/apache2/ssl.key/server.key

• /etc/apache2/ssl.csr/server.csr

• /root/.mkcert.cfg

A copy of ca.crt is also placed at /srv/www/htdocs/CA.crt for download.

	For Testing Purposes Only
A dummy certificate should never be used on a production system. Only use it for testing purposes.

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

Procédure 20.4. Creating a Self-Signed Certificate with mkcert.sh¶

1. Decide the signature algorithm used for certificates

   Choose RSA (R, the default), because some older browsers have problems with DSA.

2. Generating RSA private key for CA (1024 bit)

   No interaction needed.

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

   	Common Name of the CA
   The common name of the CA must be different from the server's common name, so do not choose the fully qualified hostname in this step.

4. Generating X.509 certificate for CA signed by itself

   Choose certificate version 3 (the default).

5. Generating RSA private key for SERVER (1024 bit)

   No interaction needed.

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

   	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.

7. Generating X.509 certificate signed by own CA

   Choose certificate version 3 (the default).

8. Encrypting RSA private key of CA with a passphrase for security

   It is strongly recommended to encrypt the private key of the CA with a password, so choose Y and enter a password.

9. Encrypting RSA private key of SERVER with a passphrase 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.

   	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.

	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 for a public shop, for example.

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.

	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 « Configuring the Firewall with YaST » (Chapitre 13, Masquerading and Firewalls, ↑Security Guide).

The SSL module is enabled by default in the global server configuration. In case it has been disabled on your host, activate it with the following command: a2enmod ssl. To finally enable SSL, the server needs to be started with the flag « SSL ». To do so, call a2enflag SSL. If you have chosen to encrypt your server certificate with a password, you should also increase the value for APACHE_TIMEOUT in /etc/sysconfig/apache2, 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 Section 20.2.2.1, « Configuration de virtualhost » 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:

20.6.2.1. Name-Based Virtual Hosts and SSL¶

By default it is not possible to run multiple SSL-enabled virtual hosts on a server with only one IP address. Name-based virtual hosting requires that Apache knows which server name has been requested. The problem with SSL connections is, that such a request can only be read after the SSL connection has already been established (by using the default virtual host). As a result, users will receive a warning message stating that the certificate does not match the server name.

openSUSE comes with an extension to the SSL protocol called Server Name Indication (SNI) addresses this issue by sending the name of the virtual domain as part of the SSL negotiation. This enables the server to « switch » to the correct virtual domain early and present the browser the correct certificate.

SNI is enabled by default on openSUSE. In order to enable Name-Based Virtual Hosts for SSL, configure the server as described in Section 20.2.2.1.1, « Virtualhosts basés sur le nom » (note that you need to use port 443 rather than port 80 with SSL).

SNI Browser Support

SNI must also be supported on the client side. Although SNI is supported by most browsers, some browsers for mobile hardware as well as Internet Explorer and Safari on Windows* XP lack SNI support. See http://en.wikipedia.org/wiki/Server_Name_Indication for details. Configure how to handle non-SNI capable browser with the directive SSLStrictSNIVHostCheck. When set to on in the server configuration, non-SNI capable browser will be rejected for all virtual hosts. When set to on within a VirtualHost directive, access to this particular Host will be rejected. When set to off in the server configuration, the server will behave as if not having SNI support. SSL requests will be handled by the first Virtual host defined (for port 443).

If there are vulnerabilities found in the Apache software, a security advisory will be issued by SUSE. It contains instructions for fixing the vulnerabilities, which in turn should be applied as soon as possible. The SUSE security announcements are available from the following locations:

By default in openSUSE, the DocumentRoot directory /srv/www/htdocs and the CGI directory /srv/www/cgi-bin belong to the user and group root. You should not change these permissions. If the directories are writable for all, any user can place files into them. These files might then be executed by Apache with the permissions of wwwrun, which may give the user unintended access to file system resources. Use subdirectories of /srv/www to place the DocumentRoot and CGI directories for your virtual hosts and make sure that directories and files belong to user and group root.

By default, access to the whole file system is denied in /etc/apache2/httpd.conf. You should never overwrite these directives, but specifically enable access to all directories Apache should be able to read. For details, see Section 20.2.2.1.3, « Configuration de virtualhost basique ». In doing so, ensure that no critical files, such as password or system configuration files, can be read from the outside.

Interactive scripts in Perl, PHP, SSI, or any other programming language can essentially run arbitrary commands and therefore present a general security issue. Scripts that will be executed from the server should only be installed from sources the server administrator trusts—allowing users to run their own scripts is generally not a good idea. It is also recommended to do security audits for all scripts.

To make the administration of scripts as easy as possible, it is common practice to limit the execution of CGI scripts to specific directories instead of globally allowing them. The directives ScriptAlias and Option ExecCGI are used for configuration. The openSUSE default configuration does not allow execution of CGI scripts from everywhere.

All CGI scripts run as the same user, so different scripts can potentially conflict with each other. The module suEXEC lets you run CGI scripts under a different user and group.

When enabling user directories (with mod_userdir or mod_rewrite) you should strongly consider not allowing .htaccess files, which would allow users to overwrite security settings. At least you should limit the user's engagement by using the directive AllowOverRide. In openSUSE, .htaccess files are enabled by default, but the user is not allowed to overwrite any Option directives when using mod_userdir (see the /etc/apache2/mod_userdir.conf configuration file).

For a list of new features in Apache 2.2, refer to http://httpd.apache.org/docs/2.2/new_features_2_2.html. Information about upgrading from version 2.0 to 2.2 is available at http://httpd.apache.org/docs-2.2/upgrading.html.

More information about external Apache modules that are briefly described in Section 20.4.5, « Modules externes » is available at the following locations:

More information about developing Apache modules or about getting involved in the Apache Web server project are available at the following locations:

If you experience difficulties specific to Apache in openSUSE, take a look at the openSUSE wiki at http://old-en.opensuse.org/Apache. The history of Apache is provided at http://httpd.apache.org/ABOUT_APACHE.html. This page also explains why the server is called Apache.