GlobalSign Blog

01 Sep 2014

SSL-Zertifikate nutzen und IPv4-Adressen einsparen, Teil 2

SSL-Zertifikate nutzen und IPv4-Adressen einsparen, Teil 2

Im ersten Teil dieses Blogs haben wir uns mit der wahlweise erwarteten, kommenden oder bereits eingetretenen Knappheit im IPv4-Adressenraum beschäftigt und verschiedene Positionen dazu näher beleuchtet. Ein Aspekt davon die sichere Verschlüsselung mit SSL, die für einige Bereiche bereits zwingend vorgeschrieben ist, ein anderer die damit verbundenen Herausforderungen. Zum Beispiel warum SSL mit namensbasierten virtuellen Hosts nicht funktioniert.

Lesen Sie im zweiten Teil mehr dazu, ob Server Name Indication die Lösung ist und welche Vorteile sie hat, wenn man sie mit Cloud-basierten Multi-Domain-Zertifikaten kombiniert.

Server Name Indication (SNI) – die Lösung?

Um dieses Problem zu lösen wurde 2003 eine Erweiterung des TLS (vormals SSL) – Protokolls veröffentlicht. Diese einfache Erweiterung addiert den Hostnamen der Website zum initialen Handshake zwischen Browser und Server dazu. So weiß der Server welches Zertifikat er benutzen muss, um die Informationen zu entschlüsseln. Für die Mehrheit der Anwender funktioniert diese Lösung, allerdings nicht für alle.

SNI_handshake

Abb. 1 Wie ein TLS-Handshake mit SNI abäuft

Microsoft verzichtete in Windows XP (und sämtlichen Versionen des Internet Explorer unter XP) beispielsweise gänzlich auf SNI; auch eine ganze Reihe von mobilen Applikationen wie Blackberry und Android 2.x haben darauf verzichtet SNI zu unterstützen. Stand letztes Jahr: 7% aller Internetnutzer können SNI-gesicherte Seiten nicht erreichen.

SNI und Cloud-basierte Multi-Domain-Zertifikate kombinieren

Kombiniert man die SNI-Technologie mit einem Multi-Domain-Zertifikat adressiert man gleich mehrere Probleme.

Und so funktioniert es: Die Applikation sitzt wahlweise auf einem Server oder Load Balancer. Dort fordert die Applikation automatisch ein zweites, validiertes Zertifikat an, wenn das SSL-Zertifikat für eine bestimmte Seite bereits für dieselbe IP-Adresse installiert, ersetzt oder entfernt wurde.

Die Methode nutzt also zwei SSL-Zertifikate. Zuerst wird ein SSL-Zertifikat (Domain Validated, Organization Validated oder bis zum höchsten Level des Extended Validated) für jede Seite installiert.

SNI-cloud_graphic_1

Abb. 2 Zunächst wird ein SSL-Zertifikate auf den verschiedenen, namenbasierten virtuellen Hosts installiert, so wie man es normalerweise für jede SNI-basierte HTTPS-Seite auch machen würde.

SNI-cloud_graphic_2

Abb. 3 Danach wird ein zweites SSL-Zertifikat, ein sogenanntes Multi-Domain-Zertifikat, installiert. Dieses ist für sämtliche SSL-gesicherten Domains validiert, die auf einer IP-Adresse gehostet werden

Das hat einige Vorteile vor allem im Hinblick auf die im IPv4-Raum knapp werdenden Adressen. Ein Provider kann SSL sehr viel schneller einsetzen, da er mehrere derartige Zertifikate an einer einzigen IP-Adresse ausführen kann und keine zusätzlichen DNS-Updates notwendig sind. Jede Website wird über ihr eigenes SSL-Zertifikat gesichert, wenn gewünscht bis zum höchsten Level, der sogenannten ‚Extended Level Validation’. Jede Domain erhält dann zusätzlich ein CloudSSL-Zertifikat. Dieses Multi-Domain-Zertifikat wird automatisch für alle Benutzer ausgestellt, deren Anwendungen nicht SNI-kompatibel sind.

Die Vorteile auf einen Blick:

  • IPv4-Adressenknappheit managen
  • Automatisierter Konfigurationsprozess
  • Unterstützt SNI/vollständig SNI-kompatibel
  • Keine DNS-Updates nötig
  • Erleichtert das Ausbringen von SSL für Provider

Wie das Ganze im Detail funktioniert haben wir in einem technischen Blogbeitrag hier näher ausgeführt.

Aktuell: Google wertet verschlüsselte Seiten künftig höher

Wie soeben angekündigt wird Google zukünftig verschlüsselte Webseiten höher ranken.

Seiten, die ausschließlich HTTPS oder TLS über HTTP nutzen, sollen in Zukunft folglich höher bewertet werden. Wir haben dazu hier ebenfalls einen kurzen Blog-Beitrag veröffentlicht.

Der Schritt war schon im April diskutiert, jetzt aber auch über den offiziellen Google-Blog angekündigt worden wie hier auf golem.de kurz erläutert. Die Zertifikate müssen demnach eine Schlüssellänge von 2.048-Bit aufweisen, alle Ressourcen einer Website müssen über relative URLs angesprochen werden und für die Indizierung dürfen keine Robots.txt-Dateien oder Metatags gesetzt werden. Wie wir meinen, ein deutliches Signal in Richtung mehr Sicherheit.

Artikel teilen

Jetzt Blog abonnieren