Il s’agit de configurer un acces par https sur un serveur Apache2 tel que distribué par Suse.
Tout d’abord, il faut activer le module ssl dans la configuration. pour celà, éditer le fichier de paramétrage général /etc/sysconfig/apache2 et ajouter à la variable APACHE_MODULES le mot clef ssl. Il faut ensuite ajouter SSL à la variable APACHE_SERVER_FLAGS. Dès lors au prochain démarrage le module SSL sera activé. La configuration par défaut des modules doit suffire.

Il faut ensuite créer les clefs nécessaires à l’établissement de la session crypté. Pour un usage de test ou privé, il est possible de créer soit même ses clef :

• La première est la clef serveur : elle doit être enregistrée dans le répertoire /etc/apache2/ssl.key sous le nom server.key. Sa création se fait à l’aide de la commande suivantes :
  openssl genrsa -des3 -rand file1:file2:file3 -out /etc/apache2/ssl.key/server.key 1024 pour une clef de 1024bit RSA cryptée par triple DES utilisant pour la génération de nombre aléatoire les fichier file1 à file3 (ou plus) passés en paramètre. Il est conseillé d’utiliser des fichiers gzip comme source aléatore. Un mot de passe sera demandé pour protéger la clef.
  Créé de cette façon là, le serveur demandera de lui fournir le mot de passe à chaque démarrage pour décrypter le certificat. il est donc possible de stocker une version non cryptée de la clef à l’aide de la commande suivante : openssl rsa -in server.key -out server.pem. Bien sure cette solution plus simple est de moindre sécurité et l’accès à la clef doit être restraint.

• La seconde clef est le certificat X509 à proprement parlé. Il est stocké dans le fichier /etc/apache2/ssl.csr et sa création se fait à partir de la clef RSA précédemment calculée. Sa génération est obtenu à l’aide de la commande suivante :
  openssl req -new -key /etc/apache2/ssl.key/server.key -out /etc/apache2/ssl.csr/server.csr : la commande vous demandera quelques informations permettant de remplir le certificat.

• Le certificat doit ensuite être signé ; normalement c’est un organisme spécialisé (et payant) qui peut réaliser celà. Pour un usage de test, cette signature peut être faite soit même par la commande suivante :
  openssl x509 -req -days 365 -in /etc/apache2/ssl.csr/server.csr -signkey /etc/apache2/ssl.key/server.key -out /etc/apache2/ssl.crt/server.crt

La configuration de l’hôte ou de l’hôte virtuel se fait de la façon suivante en ajoutant les lignes :

SSLEngine on
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:-eNULL
SSLCertificateFile /etc/apache2/ssl.crt/server.crt
SSLCertificateKeyFile /etc/apache2/ssl.key/server.pem
SetEnvIf User-Agent “.*MSIE.*” nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0

Les logs doivent être du type suivant : ssl_combined
Au passage, pour que cela fonctionne, il faut, selon votre config initiale avoir :

• NameVirtualHost *:80
• NameVirtualHost *:443

Ainsi apache va scanner les virtuals hosts à la fois pour le port 80 et le port 443. Sans celà le même (le premier) vhost avec un port 443 sera pris à chaque fois.

A la fin il reste à redemmarrer le serveur apache et tester …

Pour connaitre le type de serveur web a qui l’on a affaire, une solution est de se connecter à l’aide de la commande telnet sur le serveur et de l’interroger :

telnet adresse_serveur 80
puis tapez (rien ne va s’afficher)
GET / HTTP / 1.0
suivit de 2 carriage return

Le serveur doit vous renvoyer un message avec en entête sa version et son nom.

Lors du passage de ce site sur Apache2, j’ai été confronté à des problèmes d’affichage des caractères, Mozilla n’affichait d’ailleurs même pas tous les caratères.
Ce problème vient de l’encodage par défaut des caractère qui est en UTF-8. Ce format ne semble pas totalement supporté par les borwsers ou alors mes documents sources n’utilisent pas ce format.

La solution consiste donc à modifier le format par défaut pour revenir à quelque chose de standard. Pour celà, il faut éditer /etc/apache2/mod_mime-default.conf et changer l’option AddDefaultCharset … pour AddDefaultCharset ISO-8859-1 par exemple.

Dans le cas de l’utilisation d’apache1, la solution est la même hors mis que le fichier doit être /etc/httpd/httpd.conf.

Notez que cet encodage est plutot obsolete et ne gère entre autre pas l’euro, ISO-8859-15 serait peut être plus adapté.

Complément : A noter que j’ai aussi rencontré des problèmes avec les accents lorsque je faisais des include de pages html depuis une jsp. Je ne saurais vraiment en expliquer la cause mais la solution simple et rapide que j’ai utilisé a été de renomer mes fichiers .html en .jsp ! depuis ça fonctionne vraiement mieux.