Redhat / centos / almalinux

Comment configurer SSL / TLS avec Apache Httpd sur Red Hat

Comment configurer SSL / TLS avec Apache Httpd sur Red Hat

Objectif

L'objectif est de configurer Apache Webserver avec le support SSL / TLS sur Red Hat Linux, en utilisant les packages expédiés avec la distribution.

Système d'exploitation et versions logicielles

  • Système opérateur: Red Hat Enterprise Linux 7.5
  • Logiciel: Apache httpd, mod_ssl

Exigences

Accès privilégié au serveur Web.

Difficulté

FACILE

Conventions

  • # - Exige que les commandes Linux soient exécutées avec des privilèges racine soit directement en tant qu'utilisateur racine, soit par l'utilisation de Sudo commande
  • $ - Étant donné les commandes Linux à exécuter en tant qu'utilisateur non privilégié régulier

Introduction

L'installation d'un serveur Web est assez facile pour les distributions modernes, car les cas d'utilisation d'un serveur Web sont si courants que la plupart, sinon toutes, les distributions 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 sa fonctionnalité.

Les nouvelles technologiques de nos jours sont remplies de violations de sécurité, de vol / fuite de données et d'une envie croissante d'utiliser le cryptage
où c'est possible. Bien que l'utilisation de HTTPS ait une certaine surcharge informatique du côté serveur et du client, ne pas l'utiliser signifie que toutes les données envoyées dans les deux sens sont un texte clair, lisible par quiconque est en mesure de lire le trafic pendant qu'il dépasse le réseau.

Supposons que vous ayez un service Web où les clients peuvent vous connecter en utilisant leur nom d'utilisateur et leur mot de passe - une méthode d'authentification courante - pour atteindre 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 toutes les informations d'identification de connexion, se connecter en tant qu'administrateur du site et verrouiller les vrais administrateurs ou publier du contenu nocif pour les visiteurs.

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

Installez Apache Webserver avec la prise en charge SSL / TLS

Pour installer les packages requis, exécutez simplement comme racine:

# yum install httpd mod_ssl -y

Si le serveur a déjà installé HTTPD, il vous suffit d'installer uniquement 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 forfaits expédié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 nécessaires pour le Système d'exploitation de toute façon pour rester à 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 Activer httpd && systemctl start httpd

De cette façon, le service HTTPD sera automatiquement démarré par Systemd sur chaque démarrage.

Vérifiez l'installation et l'état

Vous pouvez vérifier l'état du serveur Web à l'aide de SystemD:

# Statut SystemCTL Httpd -l ● Httpd.Service - Le serveur HTTP Apache chargé: chargé (/ usr / lib / systemd / system / httpd.service; activé; Vendor Preset: Disabled) Active: Active (Running) depuis SAT 2018-07-07 21:35:33 CEST; 1 semaines il y a 4 jours Docs: Homme: Httpd (8) Homme: Apachectl (8) PID principal: 1292 (HTTPD) Statut: "Tâches totales: 0; Demandes actuelles / Sec: 0; Trafic actuel: 0 b / sec" Tâches : 9 cgroup: / système.tranche / httpd.Service ├fique 1292 / usr / sbin / httpd -dforeground ├─13271 / usr / sbin / httpd -dforeground ├─13272 / usr / sbin / httpd -dforeground ├─13273 / usr / sbin / httpd -dforeground ├ui / sbin / httpd -dforeground ├─27509 / usr / sbin / httpd -dforeground ├─27510 / usr / sbin / httpd -dforeground ├fique Jul 07 21:35:32 Web.foobar.com systemd [1]: Démarrage du serveur HTTP Apache… . Jul 07 21:35:33 Web.foobar.com systemd [1]: a commencé le serveur http Apache.
Copie

Pour vérifier que MOD_SSL est correctement installé:

# rpm -q mod_ssl mod_ssl-2.4.6-80.EL7.x86_64
Copie

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

# apachectl -m | grep ssl ssl_module (partagé)
Copie

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 indiquez-le vers le serveur sur HTTPS:

Message d'erreur SSL dans le navigateur Firefox

Ignorons cela pour l'instant, ajoutez l'exception de sécurité (ne définissez pas «stocker en permanence cette exception») et continuez. La page par défaut apparaît. En cas de chapeau rouge, cela ressemble à ce qui suit:

Page d'accueil par défaut d'un serveur Web HTTPD Installation sur Red Hat Linux

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

Notre serveur Web est maintenant opérationnel sur HTTPS avec un certificat auto-signé, et prêt à servir le 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 de parcourir le trafic (qui
peut être utilisé, par exemple voler des informations d'identification de connexion). Allons-nous fini? D'une certaine manière, nous avons atteint notre objectif.

Le fait que notre navigateur ne puisse pas identifier le certificat de 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 (à domicile), où vous n'avez que quelques utilisateurs, ainsi que pour seulement quelques serveurs - vous devez accepter le certificat auto-signé dans les navigateurs qui devraient être des clients des serveurs et tout autre Le navigateur dans le 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) et vous aurez
pour le renouveler pour l'utiliser. Les certificats expirés sont considérés comme invalides par les navigateurs, de la même manière que les certificats qui ne peuvent pas être prouvés comme une chaîne de certificat valide au-dessus d'eux.

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

# grep sslcertificatefile / etc / httpd / confr.d / ssl.conf | grep -v "#" sslcertificatefile / etc / pki / tls / certs / localhost.CRT
Copie

Puis utilisez OpenSSL pour obtenir la date d'expiration:

# OpenSSL X509 -enddate -Noout -in / etc / pki / tls / certs / localhost.CRT notafter = 10 juil 07:06:17 2019 GMT
Copie

Après (ou plutôt, avant) le certificat expiré, vous devez le renouveler ou le remplacer par un certificat auquel les clients font confiance. UN
Une approche plus élégante contrairement aux certificats auto-signés est de demander et d'utiliser un certificat dans un CA
(Autorité de certificat) Vos clients font déjà confiance, soit à partir de votre CA interne (qui à son tour peut avoir un monde
Root Ca de confiance au-dessus), ou directement à partir d'un ca.

Pour utiliser le certificat obtenu au lieu de la valeur par défaut, les paramètres ci-dessous doivent pointer vers le fichier de certificat, le
Clé de certificat, et le certificat de l'AC qui a signé le certificat SSL, respectivement. Les fichiers doivent être copiés sur
le serveur Web, et doit être lisible par l'utilisateur du système d'exploitation exécutant le serveur Web - en cas d'installation par défaut du chapeau rouge, l'utilisateur Apache. Ces paramètres peuvent être trouvés dans les ci-dessus SSL.confli.

Sslcertificatefile / etc / httpd / personnalisé-cerser / server-ssl.CRT SSLCertificateKeyFile / etc / httpd / personnalisé / server-ssl.clé sslcacertificatefile / etc / httpd / personnalisé / ca CA.CRT

Redirection du trafic HTTP vers HTTPS

Maintenant que nous servons sur HTTPS, nous pouvons appliquer 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 HTTPS uniquement, pourquoi écoutons-nous HTTP du tout? Supposons un utilisateur final, qui vient d'entendre parler de notre site, et obtient une URL d'un ami ne contenant pas le protocole. À ce jour, la plupart des navigateurs sont par défaut au protocole HTTP, si l'on n'est pas spécifié explicitement. Si nous cessons de servir sur HTTP, l'utilisateur tapant l'URL sans HTTPS recevra un message d'erreur si son navigateur essaie d'atteindre notre serveur sur HTTP.

Pour rediriger toutes les demandes HTTP entrantes vers HTTPS, nous créons un fichier sous / etc / httpd / confre.d avec un nom descriptif, disons, redirect_http.confli avec le contenu suivant (où le Web.foobar.com est le nom DNS du site):

 Servername web.foobar.com rediriger permanent / https: // web.foobar.com /

Et redémarrer le serveur Web. Nous pouvons tester si la redirection fonctionne correctement à partir de la ligne de commande avec WGET (à partir d'un hôte qui fait confiance au certificat SSL du serveur Web):

$ wget http: // web.foobar.com / --2018-07-19 16: 13: 01-- http: // web.foobar.com / résolvant le Web.foobar.com (web.foobar.com)… . dix.9.8.7 Se connecter au Web.foobar.com (web.foobar.com) | 10.9.8.7 |: 80… . connecté. Demande HTTP envoyée, en attente de réponse… . 301 Emplacement en permanence déplacé: https: // web.foobar.com / [suivant] --2018-07-19 16: 13: 01-- https: // web.foobar.com / se connecter au web.foobar.com (web.foobar.com) | 10.9.8.7 |: 443… . connecté. Demande HTTP envoyée, en attente de réponse… . 200 OK Longueur: 240 [texte / html] Enregistrement vers: 'Index.html '100% [========================================================== =====================================>] 240 --.-K / s dans 0S 2018-07-19 16:13:01 (7.04 Mb / s) - 'Index.HTML 'enregistré [240/240]
Copie

La sortie montre la réponse HTTP 301, et nous pouvons voir comment notre client WGET suit la redirection pour se connecter à l'aide du protocole HTTPS. Par défaut, le trafic SSL est connecté à différents fichiers de journaux, puis le trafic HTTP. Nous pouvons trouver ce qui précède
demander connecté / var / log / httpd / ssl_access_log:

dix.9.8.8 - - [19 / juil / 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 demandes HTTP à HTTPS également.

Tutoriels Linux connexes:

  • Choses à installer sur Ubuntu 20.04
  • Choses à faire après l'installation d'Ubuntu 20.04 Focal Fossa Linux
  • Téléchargement Linux
  • Fichiers de configuration Linux: 30 premiers
  • Linux peut-il obtenir des virus? Exploration de la vulnérabilité de Linux…
  • Choses à faire après l'installation d'Ubuntu 22.04 Jammy Jellyfish…
  • Meilleure distribution Linux pour les développeurs
  • Commandes Linux: les 20 meilleures commandes les plus importantes que vous devez…
  • Guide de dépannage général GNU / Linux pour les débutants
  • MX Linux vs Ubuntu