Schlagwort-Archive: HTTPS

Domain-Zertifikat von Let’s Encrypt unter Plesk einrichten

Kostenloses Domain SSL-Zertifikat einrichten

Let’s Encrypt und Plesk

Die Zertifizierungsstelle Let’s Encrypt hat das Ziel auf sehr einfache Weise kostenlose Zertifikate für die Verschlüsselung von Verbindungen im Web zur Verfügung zu stellen.

Systeme mit Plesk 12.5 können diese Umgebung effizient nutzen. Der bisherige Aufwand bei der Erstellung, Validierung, Signierung, Einrichtung und Erneuerung von Zertifikaten für verschlüsselte Websites wird mit der hier gezeigten Methode drastisch vereinfacht.

Voraussetzung und Einrichtung

1. Extension Let’s Encrypt in Plesk hinzufügen

1.1 In Plesk zu Erweiterungen (Extensions) navigieren
1.2 Extension-Catalog auflisten
1.3 Let’s Encrypt installieren

2. Kostenloses Let’s Encript Domain SSL-Zertifikat hinzufügen

2.1 zur Domain wechseln und Let’s Encrypt aufrufen
2.2 Let’s Encrypt SSL-Zertifikat installieren
2.3 Erfreulich: Das Zertifikat wird jeden Monat automatisch verlängert!
2.4 Das Let’s Encrypt SSL-Zertifikat wurde erfolgreich für die Domain xyz.de installiert

3. Zertifikat ansehen (optional)

Diese Punkte 3.1 – 3.4 können Sie / kannst Du auch überspringen:
3.1 In der Domainverwaltung auf das Icon SSL-Certificates doppelklicken
3.2 Hier wird das installierte SSL-Zertifikat mit seinen Komponenten aufgelistet
3.3 Ein Doppelklick auf den Zertifikats-Namen …
3.4 … zeigt die Details des SSL-Zertifikats

4. Zertifikat in der Domain aktivieren

4.1 Unter Websites & Domains die Hosting Settings aufrufen
4.2 In den Hosting Settings im Abschnitt Security SSL Support anhaken und das eben installierte Zertifikat auswählen

5. Aufbau verschlüsselter Verbindungen prüfen

5.1 Die Anzeige im IE zeigt eine verschlüsselte Verbindung zur Domain
5.2 Die Anzeige im Firefox zeigt eine verschlüsselte Verbindung zur Domain
5.3 Aufbau SSL-verschlüsselter Verbindung nun im grünen Bereich
5.4 Zertifikat zum Beispiel im IE ansehen
5.5 Zertifizierungspfad zum Beispiel im IE ansehen

(siehe auch Screenshots in vorstehende Fotostrecke „Plesk Extension einrichten“ mit 21 Fotos)

6. Duplicate Content via Redirect vermeiden

6.1 Im Hauptverzeichnis der Website eine Weiterleitung von HTTP auf HTTPs einrichten. Das geht schnell und einfach mit der Datei .htaccess.

Füge folgende Codezeilen für das Reddirect in der .htaccess hinzu:

Damit werden alle Aufrufe von http auf https weitergeleitet und das Problem mit Duplicate Content besteht nicht mehr.

In gängigen WordPress-Installationen müssen meistens nur die Zeilen 9 und 10 ergänzt werden:

7. CMS für https:// optimieren

Wenn das SSL-Zertifikat, wie vorstehend beschrieben erfolgreich installiert wurde, ist unbedingt das CMS System für SSL zu optimieren.

7.1 im Dashboard von WordPress die Adressen von https:// auf https:// umstellen
7.2 Der Browser Google-Chrome leistet mit seinem Security Overview beim Aufspüren von Mixed-Content sehr gute Dienste.
(Menü: Weitere Tools\Entwicklertools oder [<strg><shift>+] und dann den Tab Security auswählen)
7.3 Weiteres:
Für das CMS WordPress gibt es hier und da um Thema „https://“ gute Tipps.
7.4 Ein SSL-Servertest kann die Umstellung von http auf https:// abrunden. Mein Tipp die freie Plattform von Qualys SSL LABS: ssllabs.com – liefert einen ausführlichen SSL Report für Ihre  / Deine Domain.

(siehe auch Screenshots in vorstehende Fotostrecke „Plesk Extension einrichten“ mit 21 Fotos)

Web-Zertifikat erstellen und installieren

Ziel dieses Beitrags: Mit Boardmitteln unter Debian eine eigene CA (Certificate Authority), also eine Zertifizierungsstelle erstellen sowie ein selbstzertifiziertes Serverzertifikat erstellen und einbinden.

Nachteil: Der einzige Unterschied zu einem von einer anerkannten Stelle signierten Zertifikat ist, dass der Client (Emailprogramm, Browser, etc.) eine Warnung ausgeben wird, dass er die CA nicht kennt. Der Benutzer muss dann einmal bestätigen und kann das Zertifikat trotzdem akzeptieren.

Alternative: Zertifikat von einer anerkannten Zertifizierungsstelle einsetzen. Ein Beitrag hierzu ist in Vorbereitung.

1. OpenSSL

Für die Verwaltung der Zertifikate und für die Verschlüsselung der Verbindungen mit SSL und TLS kommt unter Linux fast immer OpenSSL zum Einsatz. In der Regel ist openssl bereits installiert. Wenn nicht, muss das Paket openssl nachinstalliert werden. Aus diesem Paket wird der Kommandozeilenbefehl openssl benötigt.

2. Erstellen der CA

Verzeichnis für das Zertifikat anlegen. z.  B.  /root/ca:

2.1 Die CA enthält einen geheimen Schlüssel, welcher automatisch erzeugt und in der Datei cakey.pem abgelegt wird.

Die Laufzeit wird hier mit 10 Jahren (3650 Tagen) bewusst hoch gewählt.

Das CA-Zertifikat wird nach cacert.pem geschrieben. Der vorstehende Befehl erzeugt einen Schlüssel für das Zertifikat mit einer Länge von 2048 Bit. Wer den geheimen Schlüssel der CA kennt, kann damit beliebige Serverzertifikate signieren. Deshalb wird diese Schlüsseldatei nicht im Klartext auf der Festplatte abgelegt, sondern mit einer Passphrase verschlüsselt. Die Passphrase, welche beim Erstellen abgefragt wird sollte daher sehr sicher gewählt werden. Bei jedem Signieren eines anderen Zertifikats wird diese Passphrase benötigt. Es sollte sichergestellt werden, dass der Private-Key (ENCRYPTED PRIVATE KEY) cakey.pem ausschließlich zum Signieren anderer Zertifikate verwendet wird. Dieser Key ist der sensibelste Teil einer CA-Infrastruktur.
Das Root-CA Zertifikat wird ausschlieslich zum Signieren von anderen Zertifikaten benötigt! Als nächstes Daten eingeben, welche die CA identifizieren. Diese werden dem Client angezeigt, wenn er aufgefordert wird, das Zertifikat zu akzeptieren oder abzulehnen. Der Code für Deutschland ist DE. Wenn ein Feld leer bleiben soll, bitte einen Punkt eingeben. Ansonsten wird der in eckigen Klammern stehende Defaultwert eingetragen. Das Feld Common Name (CN) ist hier der offizielle Name der Zertifizierungsstelle. Für die eigene CA einfach eigenen Namen eintragen. Prüfen, ob die die beiden Dateien cacert.pem und cakey.pem im gewählten Verzeichnis /root/ca entstanden sind.

2.2 Die Rechte aus Sicherheitsgründen so setzen, dass die Schlüsseldatei nur für root lesbar ist:

2.3 Testen, ob der Schlüssel mit der Passphrase wieder geöffnet werden kann.

3. Schlüssel für das Serverzertifikat erzeugen

Nachdem die eigene CA steht, kann diese für den Server ein Zertifikat herausgeben. Dazu erzeugt man/frau zunächst einen 2048 Bit langen RSA Schlüssel serverkey.pem (RSA PRIVATE KEY), der mit AES 128 verschlüsselt auf der Platte abgelegt wird (auch hier wieder ein verschlüsselter Schlüssel). Die Passphrase muss diesmal nicht sonderlich geheim sein, da wir sie ohnehin im Anschluss wieder entfernen werden. OpenSSL lässt allerdings keine leere Phrase zu:

Diese Passphrase wird wieder entfernt, damit der Serverdienst (z. B. Apache) den Schlüssel bei jedem Booten des Servers ohne Passworteingabe verarbeiten kann.

 4. Certificate Signing Request erzeugen

Der nächste Schritt zum eigenen Zertifikat ist ein CSR. Dies muss dann nur noch von der CA signiert werden. Hier sind wieder Eingaben nötig, die genau wie zum Erstellen der CA benötigt werden.

Beim Serverzertifikat ist der Common Name von entscheidender Bedeutung. Hier muss der DNS-Name stehen, unter dem der Client den Server anspricht! Wird das Zertifikat für eine HTTPS-Verbindung zu z. B. sommer-wg.de verwendet, so muss der Common Name eben genau sommer-wg.de heißen. Andernfalls wird der Browser das Zertifikat nicht akzeptieren.

Die Option A challenge password kann man/frau leer lassen. Es sind nuch in /root/ca/ inzwischn 4 Dateien vorhanden. Der CSR (Zertifikats-Request) liegt jetzt in der Datei req.pem und kann von der CA anschliessend signiert werden.

5. OpenSSL-Konfiguration anpassen

Weitere Einstellungen muss man in der Datei /etc/ssl/openssl.cnf ändern, bevor man signieren kann. Datei openssl.cnf öffnen und folgende Zeilen in der Sektion [CA_default ] anpassen:

Das Feld default_days ist auf 365 Tage voreingestellt und gibt die Gültigkeit des Zertifikates an.

Nun muss man/frau noch einige Dateien anlegen:

Zertifikat7-serial-index.jpg

6. Serverzertifikat signieren

Endspurt: Eigene CA signiert das gewünschte Server-Zertifikat:

7. Zertifikatsdaten anzeigen

7.1 Die Details eines Zertifikates können mit Hilfe des folgenden Befehls angezeigt werden:


7.2 Zertifikat in PKCS#12 (pfx) konvertieren:

8. Zertifikate installieren
Web-Server, Vorbemerkung: Einen VirtualHost für den Port 443 darf es aus technischen Gründen nur einmal geben, da z. B. Apache für diesen Port nur ein einziges SSL-Zertifikat ausliefern kann. Es ist also nicht möglich, die Adressen https://www.meinepage1.de und https://www.meinepage2.de über den selben Apache ausliefern zu lassen. Nur unter Verwendung einer zusätzlichen IP-Nummer (und anschließender Anpassung der Listen-Direktiven) ist sowas u. U, möglich.

8.1 Publikation des Root-CA Zertifikats

Vorstehend wurde ein Zertifikat mit einem zugehörigen Private-Key erzeugt. Das Zertifikat ist für den Zeitraum von 10 Jahren gültig. Nochmal: Es sollte sichergestellt werden, dass der Private-Key ausschließlich zum Signieren anderer Zertifikate verwendet wird. Dieser Key ist der sensibelste Teil einer CA-Infrastruktur. Der Zertifikatteil (public Key) dieses Paares wird den Clients (Browsern) zur Verfügung gestellt. Die Clients können die Gültigkeit von Zertifikaten, die mit diesem Private-Key signiert wurden, mit Hilfe des Root-CA Zertifikats (cacert.pem) verifizieren.
Zuerst müssen alle für die Verifizierung durch Browser unnötigen Informationen aus dem Zertifikat entfernt werden:

Dieses Zertifikat kann auf der Website publiziert werden. Der Webserver sollte einen MIME Eintrag für .crt Files konfiguriert haben. Das Modul mod_ssl in Apache, erwartet, dass das conf-Verzeichnis eine zusätzliche Konfigurationsdatei namens ssl.conf enthält …

… in Bearbeitung
Jetzt können sich die Clients das Zertifikat herunterladen und im Browser installieren. Wenn dieses erfolgt ist, akzeptiert der Browser alle Zertifikate, die mit dem zugehörigen Root-CA Key signiert wurden.

Quellen:  openssl.orgWikipedia, Sascha Kersten, Christian Piazzi,
Debian GNU/Linux Anwenderhandbuch von Frank Ronneburg 
(CC BY-NC-ND 3.0 DE)