Comment configurer SSL/TLS avec Apache httpd sur Red Hat

Objectif

L'objectif est de configurer le serveur Web Apache avec prise en charge SSL/TLS sur Red Hat Linux, en utilisant les packages fournis avec la distribution.

Versions du système d'exploitation et du logiciel

Système d'exploitation : Red Hat Enterprise Linux 7.5
Logiciel : Apache httpd, mod_ssl

Exigences

Accès privilégié au serveur Web.

Difficulté

FACILE

Congrès

# - nécessite que les commandes linux données soient exécutées avec les privilèges root soit directement en tant qu'utilisateur root, soit en utilisant sudo commande
$ – commandes linux données à exécuter en tant qu'utilisateur normal non privilégié

Présentation

L'installation d'un serveur Web est assez facile sur les distributions modernes, car les cas d'utilisation d'un serveur Web sont si courants que la plupart des distributions, sinon toutes, fournissent des packages dans leurs référentiels. Apache httpd est un serveur Web fiable utilisé par une grande partie d'Internet, et de nombreux modules sont disponibles pour étendre ses fonctionnalités.

L'actualité technologique de nos jours est remplie de failles de sécurité, de vols/fuites de données et d'une envie croissante d'utiliser le cryptage
là où c'est possible. Bien que l'utilisation de HTTPS entraîne une certaine surcharge de calcul côté serveur et côté client, ne pas l'utiliser signifie que toutes les données envoyées dans les deux sens sont en texte clair, lisibles par toute personne capable de lire le trafic pendant qu'il passe sur le réseau.

Supposons que vous disposiez d'un service Web où les clients peuvent se connecter à l'aide de leur nom d'utilisateur et de leur mot de passe - une méthode d'authentification courante - pour accéder à leurs propres données, y compris les administrateurs du site. Si vous fournissez ce service via http, toutes ces informations peuvent être enregistrées, afin que quelqu'un puisse obtenir tous les identifiants de connexion, se connecter en tant qu'administrateur du site et verrouiller les vrais administrateurs ou publier du contenu préjudiciable aux visiteurs.

La possibilité d'utiliser le cryptage lors de la navigation est intégrée depuis longtemps à tous les principaux navigateurs modernes, et de la même manière que le cryptage est disponible pour les serveurs Web depuis de nombreuses années maintenant.

Installer le serveur Web Apache avec prise en charge SSL/TLS

Pour installer les packages requis, exécutez simplement en tant que root :

# yum install httpd mod_ssl -y

Si httpd est déjà installé sur le serveur, il vous suffit d'installer mod_ssl , toute la configuration requise est effectuée
par le programme d'installation. Notez cependant que dans ce cas, vous devez redémarrer httpd, afin qu'il puisse charger le module ssl. En utilisant
les packages livrés avec la distribution, nous pouvons nous faciliter la vie, car Red Hat fournira des mises à jour correctement testées pour le système d'exploitation et le serveur Web, bien sûr, vous avez besoin d'un abonnement pour recevoir les mises à jour - mais des mises à jour sont de toute façon nécessaires pour que le système d'exploitation reste à jour.

Activer et démarrer le serveur httpd

En utilisant systemd, vous pouvez activer et démarrer le serveur Web avec la commande ci-dessous :

# systemctl enable httpd && systemctl start httpd

De cette façon, le service httpd sera automatiquement lancé par systemd à chaque démarrage.

Vérifier l'installation et l'état

Vous pouvez vérifier l'état du serveur Web en utilisant systemd :

# systemctl status httpd -l
● httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled)
   Active: active (running) since Sat 2018-07-07 21:35:33 CEST; 1 weeks 4 days ago
     Docs: man:httpd(8)
           man:apachectl(8)
 Main PID: 1292 (httpd)
   Status: "Total requests: 0; Current requests/sec: 0; Current traffic:   0 B/sec"
    Tasks: 9
   CGroup: /system.slice/httpd.service
           ├─ 1292 /usr/sbin/httpd -DFOREGROUND
           ├─13271 /usr/sbin/httpd -DFOREGROUND
           ├─13272 /usr/sbin/httpd -DFOREGROUND
           ├─13273 /usr/sbin/httpd -DFOREGROUND
           ├─27508 /usr/sbin/httpd -DFOREGROUND
           ├─27509 /usr/sbin/httpd -DFOREGROUND
           ├─27510 /usr/sbin/httpd -DFOREGROUND
           ├─27511 /usr/sbin/httpd -DFOREGROUND
           └─27512 /usr/sbin/httpd -DFOREGROUND

Jul 07 21:35:32 web.foobar.com systemd[1]: Starting The Apache HTTP Server...
Jul 07 21:35:33 web.foobar.com systemd[1]: Started The Apache HTTP Server.

Pour vérifier que mod_ssl est correctement installé :

# rpm -q mod_ssl
mod_ssl-2.4.6-80.el7.x86_64

Et est chargé en tant que module dans le serveur httpd :

# apachectl -M | grep ssl
 ssl_module (shared)

Utilisation du certificat

Lorsque nous installons le package mod_ssl, le module s'ajoute au serveur httpd, il le chargera donc au prochain démarrage.
Un certificat auto-signé est généré par défaut, qui est utilisé pour établir une connexion chiffrée avec le navigateur.
Ouvrez un navigateur et faites-le pointer vers le serveur via https :

Message d'erreur SSL dans le navigateur Firefox

Ignorons cela pour l'instant, ajoutons l'exception de sécurité (ne définissez pas "stocker en permanence cette exception") et continuez. La page par défaut s'affiche. Dans le cas de Red Hat, cela ressemble à ceci :

Page d'accueil par défaut d'une installation de serveur Web httpd sur Red Hat Linux

Notez le point d'exclamation à côté de l'URL (les autres navigateurs peuvent afficher des avertissements différents).

Notre serveur Web est maintenant opérationnel sur https avec un certificat auto-signé et prêt à diffuser du contenu publié
sous /var/www/html , la racine de contenu par défaut du serveur Web sur Red Hat.

La connexion entre le serveur Web et le navigateur est désormais cryptée, il est donc plus difficile d'usurper le trafic (qui peut être utilisé, par exemple, pour voler les identifiants de connexion). Avons-nous fini? D'une certaine manière, nous avons atteint notre objectif.

Le fait que notre navigateur ne puisse pas identifier le certificat du serveur comme valide ne l'empêche pas d'utiliser une communication cryptée avec le serveur, si nous décidons explicitement que nous faisons confiance à ce certificat. Cela peut convenir à un petit système (domestique), où vous n'avez que quelques utilisateurs, ainsi que quelques serveurs Web - vous devez accepter le certificat auto-signé dans les navigateurs qui devraient être clients des serveurs Web, et tout autre navigateur au monde ne devrait jamais voir le contenu fourni par ces serveurs.

Notez cependant que ce certificat auto-signé expirera dans le temps (comme tout autre certificat devrait le faire) et que vous devrez
le renouveler pour pouvoir l'utiliser. Les certificats expirés sont considérés comme invalides par les navigateurs, de la même manière que les certificats dont la validité ne peut pas être prouvée par une chaîne de certificats valide au-dessus d'eux.

Pour savoir quand expirera le certificat auto-signé (ou tout autre), il faut le trouver sur le système de fichiers en consultant le fichier de configuration du module ssl :

# grep SSLCertificateFile /etc/httpd/conf.d/ssl.conf | grep -v "#"
SSLCertificateFile /etc/pki/tls/certs/localhost.crt

Et puis utilisez openssl pour obtenir la date d'expiration :

# openssl x509 -enddate -noout -in  /etc/pki/tls/certs/localhost.crt
notAfter=Jul 10 07:06:17 2019 GMT

Après (ou plutôt avant) l'expiration du certificat, vous devez le renouveler ou le remplacer par un certificat auquel les clients font confiance. Une
approche plus élégante, contrairement aux certificats auto-signés, consiste à demander et à utiliser un certificat provenant d'une CA
(autorité de certification) à laquelle vos clients font déjà confiance, soit de votre CA interne (qui à son tour peut avoir une
autorité de certification racine de confiance au-dessus), ou directement à partir d'une autorité de certification de confiance mondiale.

Pour utiliser le certificat obtenu au lieu du certificat par défaut, les paramètres ci-dessous doivent pointer vers le fichier de certificat,
la clé de certificat et le certificat de l'autorité de certification qui a signé le certificat SSL, respectivement. Les fichiers doivent être copiés sur
le serveur Web et doivent être lisibles par l'utilisateur du système d'exploitation exécutant le serveur Web - dans le cas d'une installation par défaut de Red Hat, l'utilisateur apache. Ces paramètres peuvent être trouvés dans le ssl.conf mentionné ci-dessus .

SSLCertificateFile	/etc/httpd/custom-cert/server-ssl.crt
SSLCertificateKeyFile	/etc/httpd/custom-cert/server-ssl.key
SSLCACertificateFile	/etc/httpd/custom-cert/ca.crt

Redirection du trafic http vers https

Maintenant que nous servons sur https, nous pouvons imposer l'utilisation de https tout en servant tout ou partie de notre contenu. Dans notre
exemple, nous sommes très sécurisés et n'utilisons http que pour rediriger les clients entrants vers https.

Une question peut se poser, si nous voulons parler uniquement en https, pourquoi écoutons-nous du tout du http ? Supposons qu'un utilisateur final, qui vient d'entendre parler de notre site, et qui a reçu une URL d'un ami ne contenant pas le protocole. À ce jour, la plupart des navigateurs utilisent par défaut le protocole http, si aucun n'est spécifié explicitement. Si nous arrêtons de servir via http, l'utilisateur tapant l'URL sans https recevra un message d'erreur si son navigateur tente d'atteindre notre serveur via http.

Pour rediriger toutes les requêtes http entrantes vers https, nous créons un fichier sous /etc/httpd/conf.d avec un nom descriptif, par exemple, redirect_http.conf avec le contenu suivant (où web.foobar.com est le nom DNS du site) :

<VirtualHost _default_:80>
        Servername web.foobar.com
        Redirect permanent / https://web.foobar.com/
</VirtualHost>

Et redémarrez le serveur Web. On peut tester si la redirection fonctionne correctement depuis la ligne de commande avec wget (depuis un hébergeur qui fait confiance au certificat SSL du serveur web) :

$ wget http://web.foobar.com/
--2018-07-19 16:13:01--  http://web.foobar.com/
Resolving web.foobar.com (web.foobar.com)... 10.9.8.7
Connecting to web.foobar.com (web.foobar.com)|10.9.8.7|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://web.foobar.com/ [following]
--2018-07-19 16:13:01--  https://web.foobar.com/
Connecting to web.foobar.com (web.foobar.com)|10.9.8.7|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 240 [text/html]
Saving to: ‘index.html’

100%[====================================================================================>] 240         --.-K/s   in 0s      

2018-07-19 16:13:01 (7.04 MB/s) - ‘index.html’ saved [240/240]

La sortie montre la réponse http 301, et nous pouvons voir comment notre client wget suit la redirection pour se connecter en utilisant le protocole https. Par défaut, le trafic ssl est enregistré dans des fichiers journaux différents du trafic http. Nous pouvons trouver la requête ci-dessus
enregistrée dans /var/log/httpd/ssl_access_log :

10.9.8.8 - - [19/Jul/2018:16:13:01 +0200] "GET / HTTP/1.1" 200 240

Conclusion

Avec cela, nous avons atteint notre objectif, nous avons mis en place un serveur Web qui utilise https pour parler avec les clients et redirige également les requêtes http entrantes vers https.