GlobalSign Blog

27 Jul 2017

SSL/TLS Zertifikate für interne Server

Unternehmen nutzen schon seit langem Zertifikate für interne Server. Entweder weil Namenseinschränkungen für die registrierten Toplevel Domains bestehen oder weil sie nur auf einem lokalen Netzwerk gültig sind. Jedoch hat das CA/Browser Forum, das die Baseline Requirements (BRs) und Branchenstandards für die Nutzung von SSL Zertifikaten festlegt, verkündet, dass ab 1.November 2015 öffentlich vertraute SSL Zertifikate keine lokalen Namen, wie interne Servernamen oder reservierte IP-Adressen mehr beinhalten dürfen.

Anmerkung: Die BRs gelten seit 1. Juli 2012 und besagen, dass “die CA kein Zertifikat mit Ablaufdatum nach dem 1.November 2015 ausstellen darf, wenn das SAN oder Subject Common Name Feld eine reservierte IP-Adresse oder internen Servernamen enthält. Ab 1. Oktober 2016 müssen CAs alle Zertifikate, die bis dahin nicht abgelaufen sind widerrufen.“ Wir stellen daher keine öffentlich vertrauten Zertifikate mehr aus und haben bis 1. Oktober 2016 alle noch gültigen Zertifikate widerrufen.

Was ist ein interner Servername?

Ein interner Servername (der einen nicht registrierten Domainnamen beinhalten kann oder nicht) ist einer, der nicht per öffentlicher DNS gelöst werden kann, zum Beispiel:

  • Jeder Servername mit einem nichtöffentlichen Domain-Suffix. (z.B. mydomain.local, mydomain.internal)
  • NetBIOS-Namen oder kurze Hostnamen, ohne öffentliche Domain

Was ist eine reservierte IP-Adresse?

Eine reservierte IP ist eine IPv4- oder IPv6-Adresse, die die IANA als reserviert vorgemerkt hat, zum Beispiel:

  • Jede IPv4-Adresse im RFC 1918 Bereich (z.B. 10.0.0.0, 172.16.0.0, 192.168.0.0)
  • Jede IPv6-Adresse im RFC 4193 Bereich

Warum dürfen interne Servernamen und reservierte IPs kein öffentlich vertrautes SSL haben?

Zuerst einmal, weil die Namen nicht einzigartig sind und nur intern genutzt werden. Eine CA kann also nicht verifizieren, dass das Unternehmen sie wirklich besitzt (viele Unternehmen haben z.B. ein internes Mail-System unter der Adresse “https://mail/”).

Außerdem besteht die Gefahr von Missbrauch, wenn öffentlich vertraute Zertifikate diese mehrfach genutzten Namen in Zertifikaten nutzen könnten. Stellen Sie sich folgendes Szenario vor: Ein Unternehmen nutzt https://mail/ für das Mail-System. Da der Name nicht einmalig ist, kann jeder ein Zertifikat für „https://mail/“ beantragen. Wenn dies dann ins Unternehmensnetzwerk eingeschleust wird, kann zusammen mit der Manipulation von lokalen Namen, der wirkliche Mail-Server des Unternehmens nachgeahmt werden, um Zugang zum gesamten E-Mail-Verkehr zu erhalten.

Eine ausführliche Erklärung zu den Gefahren von internen Namen und reservierten IPs in öffentlichen SSL Zertifikaten und der Hintergrund zu deren Abschaffung finden Sie in diesem Whitepaper vom CA/Browser Forum.

Optionen für interne oder lokale SSL Zertifikate

Was können Sie also tun, wenn Ihre Server interne Namen und/oder reservierte IPs nutzen, Sie diese aber trotzdem mit SSL sichern wollen? Sie haben ein paar Möglichkeiten:

  • Auf einen registrierten Domainnamen umstellen – eine gute Option auf lange Zeit gesehen und Sie können weiterhin Zertifikate von Ihrer bevorzugten CA beziehen.
  • Ihre eigene interne CA erstellen und verwalten – jedoch sind damit hohe Kosten verbunden: Beschaffung, Konfiguration und Verwaltung einer eigenen CA und OCSP-Diensten.
  • Selbst-signierte SSL Zertifikate nutzen – dies ist jedoch nur für eingeschränkte Umgebungen (z.B. Testserver) eine gute Option. Benutzer lernen so wichtige Browserwarnungen zu ignorieren, was zu Problemen mit der Sicherheit führen kann, wenn selbst-signierte Zertifikate außerhalb des Unternehmens akzeptiert werden.
  • SSL Zertifikate unter einer nichtöffentlichen Root von Ihrem vertrauten CA-Anbieter beziehen – eine gute Option, wenn Sie weiterhin unqualifizierte Namen nutzen, aber keine eigene CA verwalten oder sich auf selbst-signierte Zertifikate verlassen wollen.

Die letzte Variante ist wohl die beste, wenn Sie nicht auf FQDNs umsteigen wollen oder können, weil Sie dabei Ihr derzeitiges CA-Portal weiternutzen können, um alle SSL Zertifikate über ein Portal zu verwalten. Extended Validation (EV), Organization Validation (OV), sowie solche die für interne Zwecke unter nichtöffentlichen Roots ausgestellt wurden. So haben Sie alle Vorteile einer gehosteten CA-Lösung (z.B. Erinnerungen an Ablauf von Zertifikaten, zentrales Reporting und Inventar-Management, APIs um Zertifikate komplett automatisch auszustellen und delegierte Benutzeradministration) und können weiterhin interne Server oder Anwendungen unterstützen.

GlobalSign IntranetSSL

Wir wollen Unternehmen die Möglichkeit geben weiterhin SSL für interne Servernamen und reservierte IPs auszustellen, ohne eine interne CA betreiben, sich auf selbst-signierte Zertifikate verlassen oder eine unternehmensspezifische private CA betreiben zu müssen. Deshalb haben wir IntranetSSL entwickelt. IntranetSSL ist ein Zusatz in unserem cloudbasierten Managementportal, in dem geprüfte Zertifikate sofort ausgestellt werden können, basierend auf vorüberprüften Unternehmensprofilen und Domains, sowie internen Servernamen. Da die Zertifikate von nichtöffentlichen vertrauten Root-Zertifikaten (Roots, die nicht an die Browser und Anbieter von Betriebssystemen weitergegeben werden) ausgestellt werden, unterliegen sie nicht den Baseline Requirements.

Unternehmen können einfach die notwendige nichtöffentlichen IntranetSSL-Roots an Ihre Benutzer über Group Policy Object (GPO) weitergeben, oder andere zentrale Managementsysteme nutzen, die dazu führen, dass IntranetSSL Zertifikate von den Benutzern vertraut werden.

Drei Hauptvorteile von IntranetSSL

1

Interne Servernamen und reservierte IP-Adressen:
IntranetSSL hilft beim Ausstellen von SSL Zertifikaten mit internen Servernamen und reservierten IP-Adressen als CN oder SAN. Mit IntranetSSL können Sie außerdem flexibel kombinieren: interne, FQDNs, Sub-Domains, Wildcard und globale IP-Adressen können alle in einem Zertifikat unter Ihrem Unternehmensnamen bestehen.

2

Flexible Schlüsseltypen/ Hash-Algorithmen:
Mit IntranetSSL können Altsysteme, gegenwärtige und zukünftige Anwendungen mit einer Anzahl an Schlüsseltypen und Hashing-Algorithmen genutzt werden. IntranetSSL fällt unter drei klare Hierarchien. Die RSA 2048/SHA-1 Hierarchie unterstützt alte SHA-1 Anwendungen, die nicht so einfach auf SHA-256 umgestellt werden können, wie von der BR zum SHA-1 Ablauf verlangt. Die RSA 2048/SHA-256 Hierarchie wird heute für die meisten üblichen Server und Browser genutzt und die SHA256ECDSA Hierarchie mit ECC P-256 Schlüsseln kann für zukünftige Unternehmensanwendungen genutzt werden, die höchste Sicherheit verlangen. Alle der drei Optionen stehen unseren IntranetSSL Kunden offen.

3

Längere Gültigkeitszeiträume:
IntranetSSL unterstützt längere Gültigkeitszeiträume als in den BRs bestimmt. Kunden können so Zertifikate mit einer Laufzeit von bis zu 5 Jahren erhalten.

Haben Sie Fragen dazu, wir SSL mit internen Servernamen genutzt werden kann? Sprechen Sie uns gerne an. Falls Sie mehr Informationen zu den Baseline Requirements und der Abschaffung von internen Servernamen und reservierten IP-Adressen in öffentlich vertrauten SSL Zertifikaten haben, empfehlen wir Ihnen dieses Whitepaper.

Artikel teilen