SSL / TLS instellen met Apache httpd op Red Hat

  • Ronald Ferguson
  • 0
  • 2771
  • 147
>

Doelstelling

Het doel is om een ​​Apache-webserver in te stellen met SSL / TLS-ondersteuning op Red Hat Linux, met behulp van de pakketten die bij de distributie worden geleverd.

Besturingssysteem en softwareversies

  • Besturingssysteem: Red Hat Enterprise Linux 7.5
  • Software: Apache httpd, mod_ssl

Voorwaarden

Bevoorrechte toegang tot de webserver.

Moeilijkheidsgraad

GEMAKKELIJK

Conventies

  • # - vereist dat gegeven linux-commando's worden uitgevoerd met root-privileges, hetzij direct als rootgebruiker, hetzij door gebruik van sudo opdracht
  • $ - gegeven linux-commando's die moeten worden uitgevoerd als een gewone niet-geprivilegieerde gebruiker

Invoering

Het installeren van een webserver is vrij eenvoudig op moderne distributies, aangezien gebruiksscenario's van een webserver zo vaak voorkomen dat de meeste, zo niet alle distributies, pakketten in hun repositories aanbieden. Apache httpd is een betrouwbare webserver die door een groot deel van het internet wordt gebruikt en er zijn veel modules beschikbaar om de functionaliteit uit te breiden.
Het technische nieuws is tegenwoordig gevuld met beveiligingsinbreuken, gegevensdiefstal / -lekkage en een groeiende behoefte om encryptie te gebruiken waar mogelijk. Hoewel het gebruik van HTTPS een bepaalde computeroverhead aan zowel server- als clientzijde heeft, betekent dit niet dat alle gegevens die in beide richtingen worden verzonden, duidelijke tekst zijn, leesbaar voor iedereen die het verkeer kan lezen terwijl het door het netwerk gaat..
Stel dat u een webservice heeft waar klanten kunnen inloggen met hun gebruikersnaam en wachtwoord - een veelgebruikte authenticatiemethode - om bij hun eigen gegevens te komen, inclusief de beheerders van de site. Als u deze service via http aanbiedt, kan al deze informatie worden vastgelegd, zodat iemand alle inloggegevens kan krijgen, kan inloggen als de beheerder van de site en de echte beheerders kan blokkeren of inhoud kan publiceren die schadelijk is voor bezoekers.
De mogelijkheid om versleuteling te gebruiken tijdens het browsen is al lange tijd ingebouwd in alle grote moderne browsers, en op dezelfde manier is versleuteling al vele jaren beschikbaar voor webservers.

Installeer Apache-webserver met SSL / TLS-ondersteuning

Om de benodigde pakketten te installeren, voer je gewoon uit als root:
# yum installeer httpd mod_ssl -y
Als de server al httpd heeft geïnstalleerd, hoeft u alleen maar te installeren mod_ssl, alle vereiste configuratie wordt gedaan door de installateur. Merk echter op dat u in dit geval httpd opnieuw moet opstarten, zodat het de ssl-module kan laden. Door de pakketten te gebruiken die bij de distributie worden geleverd, kunnen we ons leven veel gemakkelijker maken, aangezien Red Hat goed geteste updates zal bieden voor zowel het besturingssysteem als de webserver, je hebt natuurlijk een abonnement nodig om de updates te ontvangen - maar updates zijn nodig om het besturingssysteem toch up-to-date te houden.

Activeer en start httpd-server

Met behulp van systemd kun je de webserver inschakelen en starten met het onderstaande commando:
# systemctl inschakelen httpd && systemctl start httpd
Op deze manier wordt de httpd-service automatisch gestart door systemd bij elke keer opstarten.

Controleer de installatie en status

U kunt de status van de webserver controleren met systemd:
# systemctl status httpd -l ● httpd.service - De Apache HTTP-server geladen: geladen (/usr/lib/systemd/system/httpd.service; ingeschakeld; vooraf ingestelde leverancier: uitgeschakeld) Actief: actief (actief) sinds za 2018-07 -07 21:35:33 CEST; 1 weken 4 dagen geleden Documenten: man: httpd (8) man: apachectl (8) Hoofd-PID: 1292 (httpd) Status: "Totaal aantal verzoeken: 0; Huidige verzoeken / sec: 0; Huidig ​​verkeer: 0 B / sec" Taken : 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 07 juli 21:35:32 web.foobar.com systemd [1]: De Apache HTTP-server starten… 07 juli 21:35:33 web.foobar.com systemd [1] : Startte de Apache HTTP-server. 


Om te controleren of mod_ssl correct is geïnstalleerd:
# rpm -q mod_ssl mod_ssl-2.4.6-80.el7.x86_64 
En wordt als module in httpd server geladen:
# apachectl -M | grep ssl ssl_module (gedeeld) 

Certificaatgebruik

Wanneer we het mod_ssl-pakket installeren, voegt de module zichzelf toe aan de httpd-server, zodat het bij de volgende keer opstarten wordt geladen. Er wordt standaard een zelfondertekend certificaat gegenereerd dat wordt gebruikt om een ​​gecodeerde verbinding met de browser tot stand te brengen. Open een browser en wijs deze naar de server via https:
SSL-foutbericht in Firefox-browser
Laten we dit voorlopig negeren, de beveiligingsuitzondering toevoegen (stel "deze uitzondering permanent opslaan" niet in) en doorgaan. De standaardpagina wordt weergegeven. In het geval van Red Hat ziet dit er als volgt uit:
Standaard startpagina van een httpd-webserverinstallatie op Red Hat Linux

Let op het uitroepteken naast de URL (andere browsers kunnen andere waarschuwingen weergeven).
Onze webserver werkt nu via https met een zelfondertekend certificaat en is klaar om inhoud te presenteren die is gepubliceerd onder / var / www / html, de standaard inhoudsroot van de webserver op Red Hat.
De verbinding tussen de webserver en de browser is nu versleuteld, waardoor het moeilijker is om het verkeer te vervalsen (dat kan worden gebruikt om bijvoorbeeld inloggegevens te stelen). Zijn we klaar? In zekere zin hebben we ons doel bereikt.
Het feit dat onze browser het servercertificaat niet als geldig kan identificeren, belet hem niet om gecodeerde communicatie met de server te gebruiken, als we expliciet besluiten dat we dit certificaat vertrouwen. Dit kan geschikt zijn voor een klein (thuis) systeem, waar je maar een paar gebruikers hebt, en ook maar een paar webservers - je moet het zelfondertekende certificaat accepteren in browsers die clients van de webservers zouden moeten zijn, en alle andere browser in de wereld mag de inhoud van deze servers nooit zien.
Houd er echter rekening mee dat dit zelfondertekende certificaat na verloop van tijd verloopt (zoals elk ander certificaat zou moeten doen) en dat u het moet vernieuwen om het te kunnen gebruiken. Verlopen certificaten worden door de browsers als ongeldig beschouwd, op dezelfde manier als certificaten waarvan niet kan worden aangetoond dat ze geldig zijn door een geldige certificaatketen erboven.
Om erachter te komen wanneer het zelfondertekende (of enig ander) certificaat verloopt, moeten we het op het bestandssysteem vinden door het configuratiebestand van de ssl-module te raadplegen:
# grep SSLCertificateFile /etc/httpd/conf.d/ssl.conf | grep -v "#" SSLCertificateFile /etc/pki/tls/certs/localhost.crt 
En gebruik vervolgens openssl om de vervaldatum te krijgen:
# openssl x509 -enddate -noout -in /etc/pki/tls/certs/localhost.crt notAfter = 10 juli 07:06:17 2019 GMT 
Nadat (of liever gezegd, voordat) het certificaat verloopt, moet u het vernieuwen of vervangen door een certificaat dat de klant vertrouwt. Een elegantere benadering in tegenstelling tot zelfondertekende certificaten is het aanvragen en gebruiken van een certificaat van een CA (Certificate Authority) die uw klanten al vertrouwen, hetzij van uw interne CA (die op zijn beurt een wereldwijd vertrouwde root-CA erboven kan hebben), of rechtstreeks van een wereldwijd vertrouwde CA.
Om het verkregen certificaat te gebruiken in plaats van het standaardcertificaat, moeten de onderstaande parameters respectievelijk verwijzen naar het certificaatbestand, de certificaatsleutel en het certificaat van de CA die het SSL-certificaat heeft ondertekend. De bestanden moeten op de webserver worden gekopieerd en moeten leesbaar zijn door de gebruiker van het besturingssysteem die de webserver draait - in het geval van een standaardinstallatie van Red Hat, de apache-gebruiker. Deze parameters zijn te vinden in het bovenstaande ssl.conf.
SSLCertificateFile /etc/httpd/custom-cert/server-ssl.crt SSLCertificateKeyFile /etc/httpd/custom-cert/server-ssl.key SSLCACertificateFile /etc/httpd/custom-cert/ca.crt 

HTTP-verkeer omleiden naar https

Nu we serveren via https, kunnen we het gebruik van https afdwingen terwijl we alle of een deel van onze inhoud weergeven. In ons voorbeeld zijn we erg veilig en gebruiken we alleen http om inkomende clients om te leiden naar https.
Een vraag kan rijzen: als we alleen https willen spreken, waarom luisteren we dan überhaupt naar http? Stel dat een eindgebruiker net van onze site heeft gehoord en een URL heeft gekregen van een vriend die het protocol niet bevat. Tot op de dag van vandaag gebruiken de meeste browsers standaard het http-protocol, als dit niet expliciet is gespecificeerd. Als we stoppen met serveren via http, zal de gebruiker die de URL typt zonder https een foutmelding krijgen als zijn / haar browser onze server probeert te bereiken via http.
Om alle inkomende http-verzoeken om te leiden naar https, maken we een bestand aan onder /etc/httpd/conf.d bijvoorbeeld met een beschrijvende naam, redirect_http.conf met de volgende inhoud (waarbij web.foobar.com de DNS-naam van de site is):
 Servernaam web.foobar.com Doorverwijzing permanent / https://web.foobar.com/  
En herstart de webserver. We kunnen testen of de omleiding correct werkt vanaf de opdrachtregel met wget (van een host die het SSL-certificaat van de webserver vertrouwt):
$ wget http://web.foobar.com/ --2018-07-19 16: 13: 01-- http://web.foobar.com/ Oplossen van web.foobar.com (web.foobar.com) ... 10.9.8.7 Verbinding maken met web.foobar.com (web.foobar.com) | 10.9.8.7 |: 80… verbonden. HTTP-verzoek verzonden, in afwachting van reactie ... 301 Permanent verplaatst Locatie: https://web.foobar.com/ [volgend] --2018-07-19 16: 13: 01-- https://web.foobar.com/ Verbinden naar web.foobar.com (web.foobar.com) | 10.9.8.7 |: 443 ... verbonden. HTTP-verzoek verzonden, wacht op antwoord ... 200 OK Lengte: 240 [text / html] Opslaan in: 'index.html' 100% [====================== ================================================== ============>] 240 --.- K / s in 0s 2018-07-19 16:13:01 (7,04 MB / s) - 'index.html' opgeslagen [240 / 240] 
De uitvoer toont het http 301-antwoord en we kunnen zien hoe onze wget-client de omleiding volgt om verbinding te maken met behulp van het https-protocol. Standaard wordt het ssl-verkeer gelogd in andere logfiles dan het http-verkeer. We kunnen het bovenstaande verzoek ingelogd vinden / var / log / httpd / ssl_access_log:
10.9.8.8 - - [19 / Jul / 2018: 16: 13: 01 +0200] "GET / HTTP / 1.1" 200240

Gevolgtrekking

Hiermee hebben we ons doel bereikt, we hebben een webserver opgezet die https gebruikt om met klanten te spreken en inkomende http-verzoeken ook naar https omleidt.
  • Vorige
  • De volgende



Niemand heeft nog op dit artikel gereageerd.

Een verzameling nuttige informatie over het Linux-besturingssysteem en nieuwe technologieën
Nieuwe artikelen, praktische tips, gedetailleerde recensies en handleidingen. Voel je thuis in de wereld van het Linux-besturingssysteem