Schlagwort-Archive: HTTPS

HTTPS mit signierten Zertifikaten auf HP/HPE/Procurve/Aruba/Procurve-Switchen

2016-11-17 adlerweb 5 Kommentare

HTTPS, vorzugsweise mit gültigen Zertifikaten, sollte heute eigentlich Standard sein – erst recht wenn man mehr oder weniger kritische Infrastrukturen darüber verwalten möchte. Auch wenn ich eher ein Verfechter von SSH bei der Konfiguration von Switchen bin, so wird doch oft auch ein Webinterface gefordert. Bei HP/HPE/Aruba/Procurve ist dies in der Standardkonfiguration unverschlüsselt per HTTP erreichbar. HTTPS lässt sich aktivieren, die Einrichtung von etwas anderem als self-signed ist jedoch leider nicht so intuitiv wie ich das gerne hätte. Also gehen wir die Schritte mal durch. Im CLI natürlich.

Erst muss ein „Trust Anchor“ erstellt werden. Dies ist sozusagen die Zertifikatsdatenbank des Switches. Da mehrere vorhanden sein können wird er mit einem aussagekräftigem Namen (her „MEINNETZ„) versehen.

# crypto pki ta-profile MEINNETZ

Anschließend wird das Zertifikat der Zertifizierungsstelle (CA) importiert. Leider ist dies bei vielen Geräten nur per TFTP und nicht über USB-Stick, Terminal o.Ä. möglich. Auch dieses bekommt zur besseren Auffindbarkeit einen Namen (hier „MYCA„). Die angegebene IP entspricht der des TFTP-Servers, unter Windows lässt sich hierzu z.B. TFTPD32 nutzen. Der Switch selbst muss hierfür natürlich bereits eine passende Netzwerkkonfiguration besitzen und den PC erreichen können, ohne passende Konfiguration sucht er sich eine Adresse per DHCP auf dem Standard-VLAN.

# copy tftp ta-certificate MYCA 192.168.0.123 meineca.crt

Im Anschluss kann die Zertifikatsunterschriftanfrage (CSR) generiert werden. Wichtig für ein gültiges Zertifikat ist hierbei im Feld „common-name“ den späteren Hostname oder die IP-Adresse des Switches anzugeben, welche letztendlich für das Management verwendet werden soll..

# crypto pki create-csr certificate-name HTTPS ta-profile MEINNETZ usage web key-type rsa key-size 2048 subject common-name switch123.adlerweb.local org "BitBastelei" org-unit "IT" locality "Koblenz" state RLP country DE

Zu beachten ist, dass je nach Modellgeneration die Verfügbaren Cryptomethoden limitiert sein können. Das hier genutzte Modell unterstützt so leiglich RSA-Schlüssel mit bis zu 2048 Bit. Die verfügbaren Optionen lassen sich wie immer durch „?“ abrufen. Das Erstellen kann je nach verbautem Managementprozessor einige Zeit in Anspruch nehmen, im Anschluss erscheint die Anfrage als Text.

Diese Anfrage kopiert man aus dem Terminal und reicht sie als .csr-Datei an die gewünschte Zertifizierungsstelle weiter bzw. signiert diesen selbst mit seiner lokalen CA. Als Ergebnis erhält man ein Zertifikat, üblicherweise im PEM-Format (meist .pem oder .crt), welches im Switch importiert werden muss. Erhält man stattdessen eine DER oder P7B-Datei kann diese an einem PC z.B. mit openssl konvertiert werden. Nach Eingabe des Importbefehls erwartet der Switch den Inhalt der PEM-Datei als Texteingabe. Unter Windows mit PuTTy kann mit einem Rechtsklick eingefügt werden.

# crypto pki install-signed-certificate
Paste the certificate here and enter:
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----

Mit Erkennen der „END CERTIFICATE„-Zeile kehrt der Switch automatisch zur Konfigurationsoberfläche zurück. Das Zertifikat sollte nun in der Liste der installierten Zertifikate zu sehen sein.

# show crypto pki local-certificate
Name Usage Expiration Parent / Profile
-------------------- ------------- -------------- --------------------
HTTPS Web 2345/06/07 MEINNETZ

Zuletzt wird HTTPS ein- und HTTP ausgeschaltet. Das zuvor installierte und somit einzige Zertifikat sollte automatisch verwendet werden.

# web-management ssl
# no web-management plaintext

Somit ist der Switch nicht mehr unverschlüsselt verwaltbar und die zuständigen „Administratoren“ teilen ihr Passwort nicht mehr zwangsläufig allen Lauschern im Netz servierfertig mit. Mit etwas Glück spart das Ganze am Ende mehr Arbeit als das turnusmäßige Auffrischen der Zertifikate verursacht. Wenn nicht schont der nicht mehr vorhandene HTTP-Login immerhin meine Nerven.

BitBastelei

BitBastelei #166: HTTPS, TLS, RSA, PFS, DHE, ECDHE, WTF. – Ein kurzer Überblick (Part 2)

2015-09-20 adlerweb Schreibe einen Kommentar

BitBastelei #166: HTTPS, TLS, RSA, PFS, DHE, ECDHE, WTF. - Ein kurzer Überblick (Part 2)

(67 MB) 00:17:28

2015-09-20 11:00 🛈

Part 1: Warum verschlüsseln, Symmetrisch vs. Asymmetrisch
Part 2: RSA, PFS, DHE, ECDHE und sonstige Innereien

HTTPS dürften die meisten kennen, TLS (früher SSL genannt) vielleicht auch, wie sieht es mit RSA, DHE oder ECDHE aus? Alle Begriffe sind Techniken um Zugriffe auf Webseiten zu gegen unberechtigtes Mitlesen abzusichern.

Warnung wie immer: Alles nur als Überblick – die Erklärungen sind stark vereinfacht, teilweise unvollständig und können Fehler enthalten.

Die Grundlagen wurden bereits in Teil 1 gezeigt, nun schauen wir mal auf die Zahnräder.

RSA

Schauen wir uns den Verbindungsaufbau am Beispiel von RSA nochmal genauer an. Entwickelt wurde dieses Verfahren 1977 von Ron Rivest, Adi Shamir und Leonard Adleman am MIT. An der Stelle einen großen Dank an Vincent Bernat, welcher hier eine sehr anschauliche Erklärung (en) geliefert hat.

Der Client baut eine Verbindung auf und sendet die höchste unterstützte TLS-Version, eine Zufallszahl, eine Sitzungsnummer, eine Liste der unterstützten Crypto-Algorithmen und ggf. der Name des Zielservers (Stichwort VHosts, SNI).
Der Server antwortet ähnlich – auch er sendet die höchste von ihm unterstützte TLS-Version, eine Zufallszahl, die Sitzungsnummer und eine Liste der von ihm unterstützten Crypto-Algorithmen.
Als Nächstes sendet der Server sein Zertifikat, welches den öffenlichen Schlüssel enthält. Etwas mehr zu dem Thema ist im Post „“Vernünftiges” TLS (SSL/HTTPS/…) mit Apache“ zu finden.
Nun folgt die Info, dass der Server mit seinem Hello fertig ist. Dies ist nötig, da nach dem Zertifikat noch weitere Informationen folgen können, welche eine Erweiterung des TLS-Protokolls ermöglichen.
Der Client erzeugt eine weitere Zufallszahl, das pre-master-secret, und verschlüsselt diese mit dem öffentlichen Schlüssel des Servers. Die erste Nachricht, die theoretisch nicht von dritten mitgelesen werden kann.
Nun werden beide Seiten aktiv und berechnen aus dem pre-master-secret sowie den beiden Zufallszahlen aus den Hello-Nachrichten das master_secret, also das „Passwort“, welches für die Verschlüsselung der Verbindung letztendlich verwendet wird
Zuletzt senden beide Seiten eine Nachricht mit dem neuen Schlüssel und prüfen, ob die Nachricht der Gegenseite fehlerfrei entschlüsselt werden kann. Ist dies der Fall wird auf den ausgehandelten Algorithmus (z.B. AES) gewechselt, welcher deutlich weniger Ressourcen benötigt.

Der Mann in der Mitte

Was erst mal gut klingt hat einen Nachteil: Der eigentliche Schlüssel bleibt gleich. Die Kommunikation ist nur so lange sicher, wie der private Schlüssel des Servers nicht bekannt wird. Liest ein Angreifer die verschlüsselten Daten mit, so kann er mit diesen erst einmal nicht viel anfangen. Bekommt er in der Zukunft jedoch Zugang zum Server bzw. dessen Key – z.B. weil dieser Entsorgt wird und der Angreifer sich die Festplatte schnappt – so kann er mit dem privaten Schlüssel das pre_master_secret wiederherstellen. Hiermit hat er nun alle Daten um den zur Kommunikation gehörenden master_key zu berechnen und so alle verschlüsselten Nachrichten entschlüsseln und die Kommunikation im Nachhinein nachvollziehen zu können.

Perfekte Sicherheit? DHE!

Der Konter der Kryptologen lautet „Perfect Forward Secrecy„. Hierbei wird der private Schlüssel nur noch verwendet um sich zu authentifizieren, also nachzuweisen, dass man mit dem richtigen Server kommuniziert. Der Schlüsseltausch wird auf andere Weise erledigt, klassischerweise mit der „Diffie-Hellman-Methode“ unter Verwendung diskreter Logarithmen – in diesem Fall auch Diffie-Hellman ephemeral (DHE) genannt.

Vorsicht, es folgt Formelwirrwarr – wer es einfacher haben möchte überspringt besser den nächsten Absatz.

Zur Durchführung besitzt der Server neben dem bisherigen Schlüsseln einen weiteren Parametersatz: Die DH-Parameter, welche nicht geheim gehalten werden. Diese bestehen aus einer großen Primzahl (p) sowie einer passenden Primitivwurzel (g). Der Server sucht sich nun eine geheime Zahl (a) und berechnet g^a mod p (Ergebnis A). Zwischen Schritt 3 und 4 sendet der Server nun eine weitere Nachricht welche die Zufallszahlen der Hello-Nachrichten, die DH-Parameter und das Ergebnis der letzten Rechnung enthält. Die Nachricht ist mit dem privaten Schlüssel signiert, sodass der Client nachprüfen kann, dass die Nachricht tatsächlich vom gewünschten Server stammt und nicht manipuliert wurde. Der Client selbst erzeugt ebenfalls eine Zufallszahl (b) und führt die selbe Rechnung aus, welches B ergibt. Das Ergebnis wird in Nachricht 5 an den Server gesendet. Zusätzlich berechnet der Client A^b mod p = g^ab mod p, welches das pre-master-secret darstellt. Der Server selbst rechnet B^a mod p, welches ebenfalls g^ab mod p – also dem pre-master-secret – ergibt. Wer mitliest kennt nun war p, g, g^a mod p und g^b> mod p – hieraus das pre-master-secret g^ab mod p zu berechnen ist wegen des „deskreten Logarithmusproblems“ auf absehbare Zeit hoffentlich nicht möglich.

Bild: https://www.adlerweb.info/blog/wp-content/uploads/2015/09/dhe05-300×169.png

Farbpanschen

Zu schwer? Wikipedia hat eine schöne Analogie im Angebot:

Bild: https://www.adlerweb.info/blog/wp-content/uploads/2015/09/Diffie-Hellman_Key_Exchange_de.svg-200×300.png Original schema: A.J. Han Vinck, University of Duisburg-Essen
SVG version: Flugaal
German translation: Chillvie
https://de.wikipedia.org/wiki/Datei:Diffie-Hellman_Key_Exchange_%28de%29.svg

Beide Parteien – der Client (Alice) sowie der Server (Bob) starten mit einer gemeinsamen Farbe. Beide denken sich nun zusätzlich eine geheime Farbe aus. Beide Farben werden nun gemischt und an die jeweilige Gegenstelle gesendet. Diese mischt nun erneut die eigene, geheime Farbe hinzu. Es entsteht auf beiden Seiten wieder eine identische Farbe, welche nie übertragen wurde. Die Sicherheit basiert auf der Annahme, dass das mischen der Farben sehr einfach ist, aus dem gemischten aber wieder die beiden Ursprungsfarben zu erhalten sehr aufwändig ist.

Wo ist der Vorteil gegenüber der vorherigen Lösung? Nunja, das Ergebnis basiert ausschließlich auf den generierten Zufallszahlen, nicht dem privaten Schlüssel des Servers. Da diese Zufallszahlen nicht gespeichert werden ist es nach Abschluss der Verbindung nicht mehr möglich das Verschlüsselungspasswort (master_secret) erneut zu berechnen. Die mitgeschnittenen, verschlüsselten Nachrichten sind also nicht wiederherstellbar und somit wertlos. Ganz umsonst kommt dieser Vorteil jedoch nicht: Die nötigen Rechnungen sind sehr aufwändig – Vincent hat hier beobachtet, dass die Last des Clients um das 20-fache, das des Servers um das 3-fache steigt – für große Serverfarmen ein nicht zu vernachlässigender Kostenfaktor.

…die Sache mit dem „weak DH key“

Bild: https://www.adlerweb.info/blog/wp-content/uploads/2015/09/dhe-weak2-300×169.png

Der ein oder andere wird sie schon gesehen haben: Seit einiger Zeit werfen viele Browser beim Besuch einiger Webseiten seltsame SSL-Fehlermeldungen. „ssl_error_weak_server_ephemeral_dh_key“ heißt es so im Firefox, „Server hat eine schwache kurzlebige Diffie-Hellman öffentlichen Schlüssel“ bzw. „Server has a weak ephemeral Dillie-Heffman public key“ oder ERR_SSL_WEAK_EPHEMERAL_DH_KEY in Chrome und auch Safari hat wohl ähnliche Meldungen. Der Hintergrund: Die oben genannten Parameter bestimmen die Sicherheit – weniger als 1024 Bit sollten die DH-Parameter nicht haben, da hier ein Knacken durchaus möglich ist. Empfohlen wird eine Mindestlänge von 2048 Bit. Durch ein historisches Überbleibsel aus einer Zeit, in der starke Verschlüsselung nicht aus den USA in das Ausland gesendet werden durfte, war es möglich solche Verbindungen zwangsweise auf unter 512 Bit herunterzustufen. Die auch als Logjam bekannte Lücke stellte so eine große Gefahr für verschlüsselte Kommunikation dar. Als Gegenmaßnahme begannen Browser Verbindungen mit weniger als 1024 Bit abzulehnen und die oben genannten Fehler zu zeigen.

Was kann man tun? Nun die sinnvollste Methode wäre den Betreiber zu informieren, dass er unsichere Verschlüsselungsparameter nutzt und bitte seinen Dienst auf ein aktuelles Level umstellen sollte. Ist dies nicht erfolgreich verschafft der Verzicht auf HTTPS meist Abhilfe – wirklich sicher wäre die Verschlüsselung ohnehin nicht. Wer nicht um TLS herum kommt kann auch die DH-basierten Verschlüsselungen im Browser abschalten und ihn so zu älteren Algorithmen zwingen. Im Firefox gelingt dies in about:config – dort nach DHE suchen und die mit dhe_rsa_… beginnenden Zeilen per Doppelklick auf abgeschaltet (false) ändern.

…und das mit den Kurven?

In letzter Zeit hat sich ein weiteres Verfahren zum Schlüsseltausch breit gemacht: Elliptische Kurven. Deutlich komplexer als DHE, aber nach aktuellem glauben auch weniger anfällig. Die Masse der öffentlichen Parameter ist deutlich größer: Statt Primzahl und Primitivwurzel wird nun eine Kurve (y²=x³+ax+b), eine Primzahl (p) und ein Startpunkt (G) benötigt. Da das Erstellen der Kurven extrem aufwändig ist werden diese üblicherweise nicht selbst berechnet, sondern man greift auf eine öffentliche, vorberechnete Kurve wie z.B. P-256, P-384 oder P-521 des amerikanischen National Institute of Standards and Technology (NIST) zurück. Der Schlüsseltausch ist ähnlich zu DHE:

Der Server denkt sich eine Zufallszahl (a) aus und berechnet aG, welches in der signiert an den Client gesendet wird.
Der Client prüft die Signatur, generiert ebenfalls eine Zufallszahl (b) und sendet bG
Beide Seiten berechnen per b·aG bzw. a·bG abG, welches als pre-master-secret genutzt wird

Bild: https://www.adlerweb.info/blog/wp-content/uploads/2015/09/ecdhe11-300×169.png

Wichtig hierbei: Die gezeigten Additionen/Multiplikationen finden auf der Kurve statt und sind nicht mit den Schulrechnungen zu vergleichen. Eine weitere, gute Erklärung in Videoform liefert CSBreakdown. Zur Addition werden die Summanden auf der Kurve markiert, hiervon leitet man eine Linie ab, welche neben den Ursprüngen einen dritten Schnittpunkt ergibt. Dieser wird über die Y-Ache verlängert, der Schnittpunkt am anderen Ende der Kurve stellt das Ergebnis dar.

Rechnen in der Kurve

Zur Addition wird erst eine Punktverdopplung vorgenommen. Hierbei wendet man o.G. Methode an, statt der Summanden ist jedoch der Winkel der Kurve am Punkt (A) der Ursprung. Im Anschluss kann das Ergebnis 2A wieder mit A addiert werden um auf 3A zu kommen, etc.

Bild: https://www.adlerweb.info/blog/wp-content/uploads/2015/09/curve06-300×169.png

Da – wie schon Erwähnt – viele der hier verwendeten Daten vorberechnet sind ist der Vorgang weniger rechenintensiv, stellt aber trotzdem die zuvor beschriebene „forward secrecy“ bereit. Im Gegensatz zur „normalen“ Verschlüsselung ist hier bei effizienter Nutzung nur die doppelte Zeit am Client und etwa 15% Mehrleistung am Server zu erwarten.

Alle aktuell im Desktop- und Mobil-Bereich genutzten Browser und Systeme unterstützen diese Methode, wer jedoch exotische Geräte oder veraltete Software (Anderoid <4, Windows XP, etc) nutzt muss auf diesen Weg verzichten.

BitBastelei

BitBastelei #166: HTTPS, TLS, RSA, PFS, DHE, ECDHE, WTF. – Ein kurzer Überblick (Part 1)

2015-09-20 adlerweb Schreibe einen Kommentar

BitBastelei #166: HTTPS, TLS, RSA, PFS, DHE, ECDHE, WTF. - Ein kurzer Überblick (Part 1)

(26 MB) 00:07:18

2015-09-20 10:00 🛈

Part 1: Warum verschlüsseln, Symmetrisch vs. Asymmetrisch
Part 2: RSA, PFS, DHE, ECDHE und sonstige Innereien

Warnung wie immer: Alles nur als Überblick – die Erklärungen sind stark vereinfacht, teilweise unvollständig und können Fehler enthalten.

Warum überhaupt?

Ich hab doch nichts zu verbergen!

So heißt es vielfach, wenn man über Verschlüsselung diskutiert. Aber ist das wirklich so? Selbst wenn man selbst sein ganzes Leben zugänglich macht, so gibt es dennoch Gründe nicht alle Daten unverschlüsselt zu übermitteln. Klassisches Beispiel: Zugangsdaten. Werden diese ungeschützt übertragen können sie von Dritten abgefangen werden. Unerwünschte Posts können schnell mit Stress im Freundeskreis oder gar vor Gericht enden. Und das Konto wäre vermutlich ebenso schnell leer. Hätte man die Daten besser mal verborgen.

Bild: https://www.adlerweb.info/blog/wp-content/uploads/2015/09/3-mettbook-userpass-300×227.png

Symmetrische Kryptografie

Fangen wir mit dem einfachsten an: Symmetrische Kryptografie. Hierunter versteht man Verfahren, bei denen z.T. ein Text mit einem Passwort verschlüsselt wird. Das Ergebnis ist für Außenstehende nicht zu entziffern und somit wertlos. Wer jedoch den Schlüssel kennt kann aus dem Kauderwelsch wieder den ursprünglichen Text reproduzieren.

Bild: https://www.adlerweb.info/blog/wp-content/uploads/2015/09/sym7-300×169.png

Solche Verfahren sind natürlich schön für Dokumente, jedoch Problematisch für Webseiten: Entweder müssten alle Besucher das selbe Kennwort kennen – könnten also auch die Daten der anderen entschlüsseln – oder man müsste für jeden Besucher ein eigenes Passwort aushandeln. Nur wie, wenn der Besucher zum ersten mal die Seite aufruft? Etwas anderes muss her.

Asymmetrische Kryptografie

Klassischerweise wird zum Schlüsseltausch im Internet ein asymmetrisches Verfahren verwendet. Hierbei hat der Betreiber der Webseite einen „Schlüssel“ erstellt, welcher aus zwei Teilen besteht: Einem privaten Teil, welcher geheim gehalten wird, und einem öffentlichen Teil, welcher allen Besuchern weitergegeben wird. Dahinter steckt eine Einwegfunktion – sozusagen eine mathematische Einbahnstraße. Mit dem öffentlichen Teil lässt sich ein Text einfach verschlüsseln, jedoch das Ergebnis nach aktuellem Stand nicht mehr Zurückrechnen. Hat man jedoch den privaten Teil, so hat man auch die fehlenden Informationen um aus dem zuvor berechneten Wirrwarr wieder den ursprünglichen Text zu erhalten. Der Client kann also dem Server verschlüsselte Nachrichten zukommen lassen, ohne die Gefahr des Mitlesens.

Ebenfalls möglich ist eine andere Richtung: Mit dem privaten Schlüssel kann der Server eine Nachricht unterschreiben, also bestätigen, dass diese von ihm so gewollt ist. Der Client kann mit dem öffentlichen Teil am Ende prüfen, ob die Unterschrift tatsächlich vom Absender stammt und der Text unterwegs nicht verändert wurde.

Bild: https://www.adlerweb.info/blog/wp-content/uploads/2015/09/asym12-300×169.png

Zertifikatswahn

Wem ist etwas aufgefallen? Wir benötigen öffentliche Schlüssel für alle verschlüsselten Webseiten. Doch wo kommen sie her? Nun – das ist schnell gelöst: Der Server schickt uns diese beim Verbinden. Klingt praktisch, hat aber einen Nachteil: Wir können nicht sicher sein, dass das Ziel tatsächlich unser Server und nicht ein Angreifer zwischendrin ist. Der Lösungsansatz lautet X.509, oder kurz: Zertifikate. Diese Zertifikate enthalten nicht nur den Schlüssel, sondern auch weitere Informationen wie den Servernamen, die zugehörige Organisation, ein Haltbarkeitsdatum und einen Fingerabdruck. Zusätzlich sind diese Zertifikate zum Nachweis der Identität des Betreibers von einer weiteren Firma, der so genannten Certificate Authority (CA) unterschrieben. Alle aktuellen Browser und Betriebssysteme haben eine Liste mit Firmen, welche solche Unterschriften leisten dürfen, im Lieferumfang. Ist das Zertifikat von einer dieser Firmen unterschrieben, so vertraut der Browser diesem ohne weitere Nachfrage. Ist die Unterschrift unbekannt erhält man eine passende Warnung. In diesem Fall kann man natürlich trotzdem z.B. den erhaltenen Fingerabdruck telefonisch mit dem Betreiber abgleichen und so die Identität selbst feststellen.

Software

WordPress, HTTPs optional und die SEO-Leute

2014-04-16 adlerweb Schreibe einen Kommentar

OK, Zertifikate erneuert, dann auch noch „schnell mal“ HTTPs im Blog einschalten. Oder auch nicht…

Ich habe bereits seit langem den Adminbereich meines Blogs über HTTPS eingebunden, hierzu ist lediglich ein einfaches


define('FORCE_SSL_ADMIN', true);

in der wp-config.php notwendig. Den Blog selbst hatte ich seinerzeit auf HTTP gelassen, denn nicht jeder hat die von mir verwendete Zertifizierungsstelle CACert installiert was zu unschönen Warnungen führen würde. Optional wäre toll, aber damals zeigte sich schnell, dass die SEO-Funktionen von WordPress aus dieser einfachen Sache mal wieder eine lange Geschichte machen. Anstatt Anfragen einfach zu verarbeiten wird zur Optimierung der Suchmaschinenplatzierung alles unbekannte auf die konfigurierte Hauptadresse umgeleitet – incl. dem für WordPress unbekannten https://….

Im Netz findet man häufig kleine Codefragmente, welche in der wp-config.php die interenen Adressen bei HTTPS-Zugriffen umbiegen sollen. In meinem Fall biss sich diese Methode leider mit dem verwendeten Cache-Plugins. Fündig geworden bin ich im Plugin „WP-SSL„. Über wenige Filter werden die Adressen direkt über die API ersetzt. Da so auch die Cacher entsprechende Ausgaben erhalten ist auch der parallele Einsatz kein Problem. Das Plugin ist für mich eher Vorlage als Fertiglösung gewesen – einige Zeilen für alternative URLs und Plugins musste ich ergänzen, aber generell ist die Methode praktisch und schnell zu verstehen.

Rekonfiguration erfolgreich – somit ist diese Seite jetzt auch offiziell (auf Wunsch) per HTTPS erreichbar – selbstverständlich auch mit PFS und paranoiden Schlüssellängen, auch wenn es wohl für einen einfachen Blog nicht wirklich etwas zur Sache tut ;).

Anm: Offenbar gibt es doch noch den ein oder anderen Client (IE auf WinXP, Android 2.3), welche noch kein SNI unterstützen – für die heißt es: „Sorry, aber ohne Update geht’s nur ohne“…

Adlerweb