Différences entre versions de « HTTPD »

De The Linux Craftsman
Aller à la navigation Aller à la recherche
 
(Une version intermédiaire par le même utilisateur non affichée)
Ligne 60 : Ligne 60 :
 
<syntaxhighlight lang="apache">
 
<syntaxhighlight lang="apache">
 
ServerName web:80
 
ServerName web:80
 +
</syntaxhighlight>
 +
 +
Si vous souhaitez activer HTTP2 n'oubliez pas d'ajouter la ligne suivante dans le fichier ''/etc/httpd/conf/httpd.conf'' :
 +
<syntaxhighlight lang="apache">
 +
Protocols h2 http/1.1
 
</syntaxhighlight>
 
</syntaxhighlight>
  

Version actuelle datée du 22 octobre 2024 à 00:24

HTTP HTTPS
Protocole tcp tcp
Port 80 443
Configuration Iptables iptables -I INPUT 2 -p tcp --dport 80 -j ACCEPT iptables -I INPUT 2 -p tcp --dport 443 -j ACCEPT

Préparation

Dans un premier temps, il faudra avoir une connexion à Internet, utiliser un serveur DNS et désactiver SELinux.

Pour ceux qui auraient manqué des étapes les voici:

Une fois ces étapes effectuées, entrons dans le vif du sujet !

Installation

HTTP

# dnf -y install httpd

HTTP et HTTPS

# dnf -y install httpd mod_ssl

HTTP2

Si vous souhaitez accélérer le chargement de votre site, il est intéressant de passer en HTTP2. Pour ça on va installer le paquetage : 

# dnf -y install mod_http2

Configuration de base

Avant le premier démarrage

Tout d'abord il faut paramétrer le nom de la machine ainsi que l'adresse d'écoute

Pour cela cherchez dans le fichier /etc/httpd/conf/httpd.conf les lignes commençant par :

  • Listen 80
  • #ServerName www.example.com:80

La première doit contenir l'adresse IP de la machine ou * pour que httpd écoute sur toutes les interfaces 

Listen *:80

La deuxième doit être cohérente avec le nom de la machine qui est précisé dans le fichier network 

ServerName web:80

Si vous souhaitez activer HTTP2 n'oubliez pas d'ajouter la ligne suivante dans le fichier /etc/httpd/conf/httpd.conf : 

Protocols h2 http/1.1

Premier démarrage

Maintenant on peut démarrer httpd

  • Pour SystemVInit:
# service httpd start
Démarrage de httpd :                                       [  OK  ]
  • Pour SystemD :
# systemctl start httpd.service

Vérification

On peut vérifier que httpd écoute sur la bonne adresse et les bons ports

  • CentOS 6:
# netstat -atnp | grep httpd
tcp        0      0 :::80                       :::*                        LISTEN      1202/httpd
tcp        0      0 :::443                      :::*                        LISTEN      1202/httpd
  • CentOS 7:
# ss -atnp | grep httpd
LISTEN     0      128     :::80    :::*    users:(("httpd",pid=1483,fd=4),("httpd",pid=1482,fd=4),("httpd",pid=1481,fd=4),("httpd",pid=1480,fd=4),("httpd",pid=1479,fd=4),("httpd",pid=1478,fd=4))

Enregistrement dans le chargeur de démarrage

  • Pour SystemVInit:
# chkconfig httpd on
  • Pour SystemD:
# systemctl enable httpd.service

Ajout d'une page html

Le dossier de travail de httpd est précisé grâce à la variable DocumentRoot qui a la valeur /var/www/html

Vous pouvez donc créer votre premier site web en ajoutant dans ce dossier le fichier désigné par la variable DirectoryIndex (généralement index.html) 

# vi /var/www/html/index.html

Une fois le fichier édité, il ne faut pas oublier de repositionner les bons droits pour qu'apache soit apte à le lire 

# chown apache.apache -R /var/www/html

Parcours des logs

httpd log dans le répertoire /var/log/httpd/ et utilise deux fichiers:

  • access_log → pour journaliser tous les accès
  • error_log → pour journaliser toutes les erreurs

Démarrage et erreurs

Le fichier /var/log/httpd/error_log est fait pour ça. Quand vous avez une erreur PHP ou autre, c'est ici qu'il faut venir faire un tour: 

[Sat Feb 15 02:32:53 2014] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Sat Feb 15 02:32:53 2014] [notice] Digest: generating secret for digest authentication ...
[Sat Feb 15 02:32:53 2014] [notice] Digest: done
[Sat Feb 15 02:32:54 2014] [notice] Apache/2.2.15 (Unix) DAV/2 mod_ssl/2.2.15 OpenSSL/1.0.0-fips configured -- resuming normal operations

Vérifier l'accès aux pages

Pour vérifier qui demande quoi sur à votre serveur, c'est dans le fichier /var/log/httpd/access_log qu'il faut venir regarder: 

192.168.200.254 - - [30/Dec/2013:13:43:38 +0100] "GET / HTTP/1.1" 200 130 "-" "Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Firefox/24.0"
192.168.200.254 - - [30/Dec/2013:13:43:39 +0100] "GET / HTTP/1.1" 304 - "-" "Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Firefox/24.0"
192.168.200.254 - - [30/Dec/2013:13:43:42 +0100] "GET / HTTP/1.1" 200 14 "-" "Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Firefox/24.0"
192.168.200.254 - - [30/Dec/2013:13:43:45 +0100] "GET / HTTP/1.1" 200 130 "-" "Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Firefox/24.0"

favicon.ico ??

Quand on parcourt le fichier access_log on peut croiser la ligne suivante 

192.168.200.12 - - [28/Dec/2013:19:58:13 +0100] "GET /favicon.ico HTTP/1.1" 404 278 "-" "Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Firefox/24.0"

Et on peut se demander pourquoi le navigateur demande favicon.ico ?? En fait, il s'agit de l'icône qui figure dans l'onglet, à côté du titre

Fireforx favicon tab.png → Favicon tlc.png

Vous pouvez la générer grâce au site suivant www.favicon.cc et la placer à la racine du site web (/var/www/html)

Plusieurs Vhosts et une seule favicon

Si vous désirez une favicon pour plusieurs vhost, utilisez une expression rationnelle: 

AliasMatch "favicon.ico$" "/chemin/vers/favicon.ico"

L'expression suivante va réévaluer toutes les URLs se terminant ($) par favicon.ico en /chemin/vers/favicon.ico.

Favicon pas dans la DocumentRoot

Si votre favicon n'est pas dans la DocumentRoot (directive d'Apache) de votre site web, il faudra la rendre exécutable pour qu'Apache puisse la servir 

# chmod +x /chemin/vers/favicon.ico

Fonction Virtual Host

La fonction Vhost permet de faire tourner plusieurs sites Web différents sur un même serveur. Les moyens de différenciation sont multiples:

  • le port TCP
  • l'adresse IP
  • le nom DNS
  • un sous-ensemble de ces trois éléments

Emplacement du fichier de configuration

Les fichiers de configuration de httpd se trouvent dans le dossier /etc/httpd/conf.d 

# ll /etc/httpd/conf.d/
total 20
-rw-r--r--. 1 root root  392 13 août  19:28 README
-rw-r--r--. 1 root root 9473  2 août  13:59 ssl.conf
-rw-r--r--. 1 root root  299  2 août  13:59 welcome.conf

Ces fichiers sont importés dans la configuration de httpd grâce à la directive Include présente dans le fichier httpd.conf 

Include conf.d/*.conf

Nous allons donc créer un fichier spécifique pour nos VHost que nous appellerons vhost.conf 

# touch /etc/httpd/conf.d/vhost.conf

VHost par ports TCP

Ce choix permet avec une seule adresse IP d'avoir plusieurs sites qui sont accessibles sur des ports différents. C'est généralement le cas quand on veut installer des interfaces d'administration.

Tout d'abord le serveur httpd doit écouter sur les ports en question 

Listen 80 # Ne pas ajouter si déjà dans httpd.conf
Listen 8080
ServerName www.tala-informatique.fr

Ensuite les VHost possèderont une directive VirtualHost différente 

<VirtualHost *:80>
    DocumentRoot /var/www/html/public
</VirtualHost>

<VirtualHost *:8080>
    DocumentRoot /var/www/html/admin
</VirtualHost>

VHost par adresses IP

Des contenus différents

Ce choix est inintéressant quand le serveur Web possède deux cartes réseaux sur deux réseaux différents (vers Internet et vers l'intranet).

Tout d'abord on déclare un serveur httpd principal et cette configuration est généralement déjà dans httpd.conf. 

Listen 192.168.200.251:80
DocumentRoot /var/www/html/
ServerName www.tala-informatique.fr

Ensuite le VHost possèdera une directive VirtualHost différente 

<VirtualHost 192.168.200.250:80>
    DocumentRoot /var/www/html/intranet
</VirtualHost>

Le même contenu

Le serveur web peut avoir plusieurs interfaces, sur des réseaux différents, et en plus une interface d'administration sur laquelle on ne veut pas que httpd écoute.

Tout d'abord le serveur httpd doit écouter sur le port TCP/80 (en général) 

Listen *:80

Puis on précise les interfaces d'écoute 

<VirtualHost 192.168.200.250 192.168.200.251>
    DocumentRoot /var/www/html/intranet
    ServerName www.tala-informatique.fr
</VirtualHost>

VHost par noms DNS

C'est le type le plus courant de VHost. En effet, le plus souvent les gens ne possèdent qu'une seule adresse IP publique et il est donc plus simple de faire pointer plusieurs noms de domaine vers la même adresse.

Tout d'abord le serveur httpd doit écouter sur le port TCP/80 (en général) mais cette fois-ci on doit lui spécifier que l'on va utiliser des VHost par nom. Pour cela on utilise la directive NameVirtualHost soit:

  • en utilisant un nom différent de celui utilisé pour les VHost (c'est le cas dans cet exemple)
  • soit en utilisant une adresse IP
NameVirtualHost web.tala-informatique.fr:80

web.tala-informatique.fr = www.tala-informatique.fr = wiki.tala-informatique.fr = une adresse IP

Ensuite les VHost possèderont une variable ServerName différente 

<VirtualHost *:80>
    DocumentRoot /var/www/html/informatique
    ServerName www.tala-informatique.fr
</VirtualHost>

<VirtualHost *:80>
    DocumentRoot /var/www/html/wiki
    ServerName wiki.tala-informatique.fr
</VirtualHost>

Rediriger les brebis égarées

Il peut être utile d'utiliser la directive Redirect pour rediriger quelqu'un qui arrive en http si votre site est en https. Pour cela nous allons créer un Vhost http identique à celui en https et qui aura pour unique rôle d'effectuer une règle de redirection: 

<VirtualHost www.tala-informatique.fr:80>
        ServerName www.tala-informatique.fr
        Redirect "/" "https://www.tala-informatique.fr/"
</VirtualHost>

<VirtualHost www.tala-informatique.fr:443>
        ServerName www.tala-informatique.fr
        DocumentRoot /var/www/html/

        SSLEngine on
        SSLCertificateFile /opt/ssl/www.tala-informatique.fr.crt
        SSLCertificateKeyFile /opt/ssl/www.tala-informatique.fr.key
</VirtualHost>

Rediriger vers un autre serveur

Il est possible d'utiliser Apache en frontal comme reverse proxy. Cela va rediriger la requête entrante vers un autre serveur web: 

<VirtualHost *:80>
    ProxyPreserveHost On

    ProxyPass / http://192.168.1.1:8080/
    ProxyPassReverse / http://192.168.1.1:8080/

    ServerName kfserver.tala-informatique.fr
</VirtualHost>

Dans cet exemple, le serveur Apache va rediriger toutes les requêtes à destination du vhost kfserver.tala-informatique.fr vers le serveur http://192.168.1.1:8080/

On peut aussi ajouter une authentification par mot de passe dans le virtual host : 

<VirtualHost *:80>
        ...
        <Proxy *>
                AuthUserFile /etc/httpd/conf.d/kfserver.pwd
                AuthName "Protected access !"
                AuthType Basic
                Require valid-user
        </Proxy>
</VirtualHost>

Le fichier .htaccess

Les fichiers .htaccess sont des fichiers de configuration d'Apache, permettant de définir des règles dans un répertoire et dans tous ses sous-répertoires.

Possibilités

Les principales raisons d'utilisation des fichiers .htaccess sont :

  • gérer l'accès à certains fichiers;
  • ajouter un mime-type;
  • protéger l'accès à un répertoire ou un fichier par un mot de passe;
  • définir des pages d'erreurs personnalisées.

Principe

Le fichier .htaccess est placé dans le répertoire dans lequel il doit agir. Il agit ainsi sur les permissions du répertoire qui le contient et sur tous ses sous-répertoires.

Vous pouvez placer un autre fichier .htaccess dans un sous-répertoire d'un répertoire déjà contrôlé par un fichier .htaccess. Le fichier .htaccess du répertoire parent reste en « activité » tant que les fonctionnalités n'ont pas été réécrites.

Exemples d'utilisation

Avant d'aller plus loin, assurez-vous qu'Apache lise les .htaccess en passant la directive AllowOverride de None à All dans le fichier /etc/httpd/conf/httpd.conf

Pour cela éditez le fichier et cherchez la ligne <Directory "/var/www/html" >. Plus loin, il vous suffit de modifier la ligne AllowOverride None en AllowOverride All.

Bloquer l'accès à des ressources

Un fichier .htaccess est composé de deux sections :

  • une première qui contient les chemins vers les fichiers contenant les définitions de groupes et d'utilisateurs;
  • une deuxième qui précise les conditions d'accès.
# Définition
AuthUserFile /path/to/.htpasswd 
AuthGroupFile /path/to/.htgroup
AuthName "Accès protégé" 
AuthType Basic
#Conditions d'accès
Require valid-user
  • AuthUserFile définit le chemin d'accès absolu vers le fichier de mot de passe;
  • AuthGroupFile définit le chemin d'accès absolu vers le fichier de groupe;
  • AuthName entraîne l'affichage dans le navigateur Internet de : « Tapez votre nom d'utilisateur et votre mot de passe. Domaine: "Accès protégé" »;
  • AuthType Basic précise qu'il faut utiliser AuthUserFile pour l'authentification;
  • Require valid-user précise que l'on autorise uniquement les personnes identifiées. Il est possible de préciser le nom des personnes autorisées : Require user {username}

Création du fichier de mot de passe

Pour créer le fichier de mot de passe, il faut utiliser la commande htpasswd 

# htpasswd -c /path/to/.htpasswd jcf
New password:
Re-type new password:
Adding password for user jcf

On vérifie que le fichier est bien crypté: 

# cat .htpasswd
jcf:RM1/WS9zqOV8o

La prochaine fois que l'on veut ajouter un compte il ne faut pas utiliser l'option -c (pour create): 

# htpasswd /path/to/.htpasswd magali
New password:
Re-type new password:
Adding password for user magali

Redirections

Vous vous demandez comment rediriger les âmes égarées qui se retrouvent à la racine de votre serveur Web...

Dans le fichier ou vous avez déclaré vos Vhost il vous suffit d'ajouter la ligne suivante: 

RedirectMatch ^/$ /wiki/

Comme cela, lorsque l'on arrive à la racine / (^/$ → ^ signifie début de ligne et $ fin de ligne) on est redirigé vers /wiki/.

Réécriture d'URLs (mod_rewrite)

La réécriture d'URLs et très utilisée dans l'élaboration d'APIs ou d'applications où la sémantique des URLs est importante. Le module de réécriture peut, en fonction d'expressions régulières, modifier les URLs envoyées par le navigateur (à la volé) pour limiter l'adhérence avec les fichiers sur le disque dur.

Par exemple, plus besoin d'utiliser /user.php?id=1 pour accéder à l'utilisateur qui possède l'identifiant 1 mais simplement /user/1.

Mise en place

La réécriture des URLs se fait sur un répertoire donc:

si elle est déclarée dans un fichier vhost, il faut qu'elle se trouve entre les balises Directory sinon, elle peut se renseigner dans un fichier .htaccess 
<VirtualHost *:80>
        <Directory /opt/site>
                Require all granted
                # On active le module de réécriture
                RewriteEngine on
                # On test si un fichier existe et on l'affiche
                RewriteCond %{REQUEST_FILENAME} !-f
                # On test si un répertoire existe et on l'affiche
                RewriteCond %{REQUEST_FILENAME} !-d
                # Si aucun fichier ou répertoire n'existe on applique la règle de réécriture
                # Dans ce cas on prend toute l'URL est on la met dans $_GET['url']
                RewriteRule ^(.*)$ index.php?url=$1 [QSA,L]
        </Directory>
        DocumentRoot /opt/site
        ServerName wis.local
</VirtualHost>

# On active le module de réécriture
RewriteEngine on
# On test si un fichier existe et on l'affiche
RewriteCond %{REQUEST_FILENAME} !-f
# On test si un répertoire existe et on l'affiche
RewriteCond %{REQUEST_FILENAME} !-d
# Si aucun fichier ou répertoire n'existe on applique la règle de réécriture
# Dans ce cas on prend toute l'URL est on la met dans $_GET['url']
RewriteRule ^(.*)$ index.php?url=$1 [QSA,L]

Il ne reste plus qu'à créer le fichier index.php suivant: 

<?php

var_dump($_GET['url']);

Pour voir s'afficher l'URL:

Mod rewrite var dump index.png

Digestion des URLs

Il ne nous reste plus qu'à digérer les URLs pour aiguiller vers la bonne page ! La technique consiste à exploser l'URL pour la lire grâce à un automate à états fini déterministe: 

<?php
function digestUrl(){
	if(isset($_GET['url']) && !empty($_GET['url'])){
		// Si l'URL n'est pas vide, on la met dans un tableau
		$url[] = $_GET['url'];
		if(strpos($url[0], '/') !== FALSE){
			// L'URL possède plusieurs morceaux, découpage dans le tableau
			$url = explode('/', $url[0]);
		}
		// Lecture de la première partie
		if($url[0] == 'user'){
			// première partie de l'URL 'user'...
			...
		}else if(...){
			// deuxième traitement ici...
		}else{
			// URL inconnue
			http_response_code(404);
			echo "File not found";
		}
	}else{
		// L'URL est vide
		http_response_code(200);
		echo "Page d'index";
	}
}
digestUrl();

Certificats

C'est la première chose que les utilisateurs vont voir lorsqu'ils se connectent à votre site, alors autant en prendre soin. On n'est pas en confiance lorsque l'on se connecte à un serveur qui fait parti de l'entreprise SomeOrganization et du département SomeOrganizationUnit... On va remédier à cela !

Auto-signé

Génération

Pour ce faire, nous allons utiliser openssl et notamment la commande suivante: 

# mkdir /opt/ssl
# cd /opt/ssl
# openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout www.tala-informatique.fr.key -out www.tala-informatique.fr.crt
Generating a 2048 bit RSA private key
...............+++
..........................................+++
writing new private key to 'www.tala-informatique.fr.key'
-----
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) [XX]:FR
State or Province Name (full name) []:Herault
Locality Name (eg, city) [Default City]:Juvignac
Organization Name (eg, company) [Default Company Ltd]:Tala
Organizational Unit Name (eg, section) []:Informatique
Common Name (eg, your name or your server's hostname) []:www.tala-informatique.fr
Email Address []:tala.informatique@gmail.fr

Utilisation de la clé et du certificat

Il faut maintenant les faire utiliser par Apache, ce qui se fait dans le fichier où vous avez déclaré vos hôtes virtuels. 

...

SSLEngine on
SSLCertificateFile /opt/ssl/www.tala-informatique.fr.crt
SSLCertificateKeyFile /opt/ssl/www.tala-informatique.fr.key

...

On n’oublie pas de donner les droits à Apache: 

# chown -R apache. /opt/ssl

Automatisation

Maintenant nous allons faire un script Shell, que j'ai nommé gen_ssl_tokens.sh, pour automatiser tout cela: 

#!/bin/bash

###########################
# Key name
KEY=valhalla.tala-informatique.fr.key
# Cert name
CRT=valhalla.tala-informatique.fr.crt
# Validity period
VALIDITY=365
# Destination directory
DST_DIR="/opt/ssl"
###########################

echo -n "Generating key and certificate: "
openssl req -x509 -nodes -days ${VALIDITY} -newkey rsa:2048 -keyout ${KEY} -out ${CRT} << EOF
FR
Herault
Juvignac
Tala
Informatique
www.tala-informatique.fr
tala.informatique.fr

EOF

echo ""
echo "ok."

echo -n "Copying key and certificate: "
mv -f ${KEY} ${DST_DIR}/
mv -f ${CRT} ${DST_DIR}/
echo "ok."

echo -n "Giving rights to Apache: "
chown -R apache. ${DST_DIR}
echo "ok."

On n'aura plus qu'à lancer le script pour générer automatiquement la clé et le certificat pour le renouvellement... Vous pouvez également utiliser cron !

Let's Encrypt

On peut également utiliser une autorité de certification pour générer le certificat à notre place. L'avantage est que le certificat sera reconnu par les navigateurs.

Utilisation du client ACME (obsolète avec mod_md)

Installation de acme.sh

Pour cela nous allons utiliser un script qui va faire le travail à notre place : 

# wget -O - --no-check-certificate https://get.acme.sh | sh 
--2016-10-10 15:10:16--  https://get.acme.sh/
Résolution de get.acme.sh... 195.154.91.106
Connexion vers get.acme.sh|195.154.91.106|:443...connecté.
AVERTISSEMENT : impossible de vérifier l'attribut get.acme.sh du certificat, émis par «/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3» :
  Le certificat émis a expiré.
requête HTTP transmise, en attente de la réponse...200 OK
Longueur: 671 [text/plain]
Sauvegarde en : «STDOUT»

100%[======================================================>] 671         --.-K/s   ds 0s      

2016-10-10 15:10:16 (95,3 MB/s) - envoi vers sortie standard [671/671]

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  100k  100  100k    0     0   478k      0 --:--:-- --:--:-- --:--:-- 1277k
[lun. oct. 10 15:10:17 CEST 2016] Installing from online archive.
[lun. oct. 10 15:10:17 CEST 2016] Downloading https://github.com/Neilpang/acme.sh/archive/master.tar.gz
[lun. oct. 10 15:10:18 CEST 2016] Extracting master.tar.gz
[lun. oct. 10 15:10:18 CEST 2016] It is recommended to install nc first, try to install 'nc' or 'netcat'.
[lun. oct. 10 15:10:18 CEST 2016] We use nc for standalone server if you use standalone mode.
[lun. oct. 10 15:10:18 CEST 2016] If you don't use standalone mode, just ignore this warning.
[lun. oct. 10 15:10:18 CEST 2016] Installing to /root/.acme.sh
[lun. oct. 10 15:10:18 CEST 2016] Installed to /root/.acme.sh/acme.sh
[lun. oct. 10 15:10:18 CEST 2016] OK, Close and reopen your terminal to start using acme.sh
[lun. oct. 10 15:10:18 CEST 2016] Installing cron job
[lun. oct. 10 15:10:19 CEST 2016] Good, bash is found, so change the shebang to use bash as prefered.
[lun. oct. 10 15:10:19 CEST 2016] OK
[lun. oct. 10 15:10:19 CEST 2016] Install success!

Une fois le script acme.sh installé, il suffit de recharger le contexte en exécutant la commande : 

# cd
# . .bash_profile

Création des certificats

Mainteant le script acme.sh est accessible dans le shell: 

acme.sh --issue -d tala-informatique.fr -d www.tala-informatique.fr -w /var/www/html

Vous devriez voir la commande se finir par : Cert success.

Utilisation de la clé et du certificat

Il faut maintenant les faire utiliser par Apache, ce qui se fait dans le fichier où vous avez déclaré vos hôtes virtuels. 

...

SSLEngine on
SSLCertificateFile /opt/ssl/www.tala-informatique.fr.crt
SSLCertificateKeyFile /opt/ssl/www.tala-informatique.fr.key

...

Installation des certificats

Il ne reste plus qu'a les installer dans le répertoire /opt/ssl/ : 

# acme.sh --installcert -d www.tala-informatique.fr --certpath /opt/ssl/www.tala-informatique.fr.crt --keypath /opt/ssl/www.tala-informatique.fr.key --reloadcmd "service httpd restart"

Cela va installer les certificats et redémarrer le serveur Apache !

Maintenant, lorsque l'on se connecte on peut vérifier que le certificat est approuvé :

Www.tala-informatique.fr-cert-letsencrypt.png

Automatisation avec mod_md

Il est possible de faire toutes les étapes précédentes de manière transparente grâce au module Apache mod_md.

Commençons par l'installer: 

# yum -y install mod_md

Une fois le module installé, nous allons ajouter la configuration suivante dans le fichier de votre hôte virtuel: 

# Répertoire de stockage des certificats
MDStoreDir "/opt/ssl"
# Acceptation des accords de licence
MDCertificateAgreement accepted
# Domaine utilisé pour l’enrôlement, doit correspondre à votre DNS 
MDomain www.tala-informatique.fr
# Administrateur du serveur, obligatoire pour Let's Encrypt
ServerAdmin tala.informatique@gmail.com
<VirtualHost *:443>
    ...
    # Nom de l'hôte virtuel
    ServerName www.tala-informatique.fr
    # Démarrage du moteur SSL/TLS sans préciser de certificats (mod_md s'en charge)
    SSLEngine on
    ...

Vous devez maintenant redémarrer votre serveur et nous allons le faire sans couper les connexions actives : 

# httpd -k graceful

vous devriez apercevoir dans les logs /var/log/httpd/error_log les lignes suivantes: 

...
AH10085: Init: www.tala-informatique.fr:443 will respond with '503 Service Unavailable' for now. There are no SSL certificates configured and no other module contributed any.
...
AH10059: The Managed Domain www.tala-informatique.fr has been setup and changes will be activated on next (graceful) server restart.
...

Si vous ne voyez pas ces lignes, il y a une problème à l'enrôlement et vous devrez certainement activer le protocole HTTP sur le port 80.

Il ne reste plus qu'a relancer le serveur pour prendre en compte les certificats : 

# httpd -k graceful

Il ne vous reste plus qu'a tester avec un navigateur !

Un peu de sécurité

Pour tester le niveau de sécurité offert par votre serveur, vous pouvez le faire tester par ssllabs. Gardez à l'esprit que plus le niveau de sécurité et élevé et plus les clients auront de mal à visiter votre site.

A la fin de vos modifications, vous devriez avoir quelque chose comme ça !

Ssllabs A grade.png

Modification des algorithmes de chiffrement

Cette modification permet la suppression des protocoles SSL-V2, SSL-V3 et TLS-V1 dont certains comportent la faille POODLE ainsi que le retrait de tous les algorithmes reposant en partie sur RC4 et CBC (cipher block chain) vulnérables à l'attaque Lucky13.

Dans votre fichier de configuration d'Apache, de préférence dans une section globale, ajoutez les lignes suivantes : 

SSLProtocol All -SSLv2 -SSLv3 -TLSv1
SSLCipherSuite HIGH:!aNULL:!MD5
SSLHonorCipherOrder on

Ajout de la chaine de certification

Certain navigateur ne vont pas avoir confiance si le serveur ne fournit pas la chaine de certification complète en plus du certificat. Pour éviter ce problème, il suffit de l'inclure dans le fichier de configuration d'Apache mais, avant ça, de demander la génération de ce fichier. Ci dessous un exemple pour Let's Encrypt: 

/root/.acme.sh/acme.sh --force --issue -d www.tala-informatique.fr -w /var/www/html
/root/.acme.sh/acme.sh --installcert -d www.tala-informatique.fr --certpath /opt/ssl/www.tala-informatique.fr.crt --keypath /opt/ssl/www.tala-informatique.fr.key --fullchain-file /opt/ssl/www.tala-informatique.fr.pem

On voit l'ajout de --fullchain-file /opt/ssl/www.tala-informatique.fr.pem pour avoir la chaine de certification complète !

Maintenant on peut modifier le fichier de configuration d'Apache. En dessous des lignes: 

SSLEngine on
SSLCertificateFile /opt/ssl/www.tala-informatique.fr.crt
SSLCertificateKeyFile /opt/ssl/www.tala-informatique.fr.key

On ajoute : 

SSLCertificateChainFile /opt/ssl/www.tala-informatique.fr.pem

Agrafage OCSP

Le protocole de contrôle du statut des certificats en ligne (Online Certificate Status Protocol) est un mécanisme permettant de déterminer si un certificat a été révoqué ou non. L'agrafage OCSP permet au serveur de maintenir une liste des réponses OCSP actuelles pour ses certificats et de les envoyer aux clients. Cela permet au client de vérifier, très rapidement, si le certificat est valide sans avoir besoin d'ouvrir une nouvelle connexion vers l'autorité OSCP.

Pour activer cette fonctionnalité ajoutez les lignes suivantes dans la section globale: 

SSLUseStapling On
SSLStaplingCache "shmcb:ssl_stapling(32768)"

Attention, la mémoire de 32768 Ko doit être modifiée en fonction du nombre de certificats que vous possédez sur le serveur. Certain certificats, avec la chaine complète, peuvent peser jusqu'à 10Ko...

Vous pouvez tester le bon fonctionnement de l’agrafage avec la commande suivante : 

# openssl s_client -connect www.tala-informatique.fr:443 -status -servername www.tala-informatique.fr

Dans le résultat, cherchez les lignes suivantes : 

OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
...
    Cert Status: good
...

Exemple de configuration

Directive Valeur par défaut Config httpd Config Vhost Utilisation
ServerTokens OS X Permet de ne pas donner trop d'informations sur les modules qui sont installés. Généralement on passe cette directive à Prod
ServerRoot "/etc/httpd" X Permet d'indiquer le répertoire d'installation d'Apache. Normalement les scripts d'installation ont bien renseigné cette ligne. Vérifiez quand même.
PidFile run/httpd.pid X Indique au script de démarrage d'enregistrer le numéro de processus d'Apache pour que lors de l'arrêt du système le processus Apache soit stoppé correctement.
Timeout 60 X Temps en secondes avant que le serveur n'envoie ou ne reçoive un timeout . Quand le serveur attend une réponse qui dépasse le temps définit par 'Timeout, il va s'interrompre et prévenir l'utilisateur de l'erreur. Laissez cette valeur par défaut à moins que vous n'effectuiez des traitements dépassant cette limite. Ne pas monter trop haut cette valeur non plus car si le programme externe à "planté", ou si une erreur est survenue, vous risquez de rendre inaccessible le serveur Apache pour trop de temps (il est toujours désagréable d'attendre pour rien).
KeepAlive Off X X Autorise ou non les connexions persistantes (plusieurs requêtes par connexions). En fait cela permet aux utilisateurs de votre serveur de lancer plusieurs requêtes à la fois, et donc d'accélérer les réponses du serveur. Laissez cette valeur par défaut la plupart du temps. Pour de petits serveurs laissez cette option sur on . Pour un serveur très sollicité, dès que vous vous apercevez que le système ralentit énormément ou devient indisponible assez souvent, essayez avec la valeur off . Mais avant, essayez de baisser la valeur de l'option suivante.
MaxKeepAliveRequests X X En combinaison avec l'option précédente, indique le nombre de requêtes pour une connexion. Laissez cette valeur assez haute pour de très bonnes performances. Si vous mettez 0 comme valeur, vous en autorisez en fait un nombre illimité (attention donc). Laissez la valeur par défaut là aussi.
KeepAliveTimeout 15 X X Valeur d'attente en secondes avant la requête suivante d'un même client, sur une même connexion, avant de renvoyer un timeout. Laisser la valeur par défaut.
Listen 80 X X Indique au serveur des ports ou des adresses IP, ou les deux, où il doit écouter les demandes de connexions.
LoadModule, ClearModuleList & AddModule

LoadModule xxxxxx.mod libexec/yyyyyy.so
ClearModuleList
AddModule zzzz.c

X Support pour les modules DSO (Dynamic Shared Object). LoadModule permet de charger un module. Avant Apache 2, les directives ClearModuleList et AddModule permettaient de spécifier l'ordre d'exécution des modules, à cause de problèmes de dépendances. Apache 2 peut maintenant faire cela automatiquement, car les APIs de modules leur permet de spécifier eux-mêmes leur ordre. Sous Apache 1.*, il faut cependant y prêter une grande attention, et le maintenir à jour à l'ajout de tout nouveau module.
Récupérée de « https://tala-informatique.fr/index.php?title=HTTPD&oldid=4076 »