Der 1. November kommt - Ist Ihr Exchange Server bereit?

1. November 2015: Neue Regeln treten in Kraft

Ihre Freunde bei SSL.com möchten Sie über diesen Anfang informieren 1. November 2015, etwas sehr wichtige Änderungen in Bezug auf das, was abgedeckt werden kann SSL-Zertifikate wirken:

• Neue Zertifikate mit internen Namen werden von keiner Zertifizierungsstelle mehr gemäß den Richtlinien des CA / Browser-Forums ausgestellt (dh alle seriösen)
  
  Beachten Sie, dass SSL.com seit einiger Zeit keine Intranet-Zertifikate für interne Namen mit Ablaufdaten nach dem 1. November 2015 ausstellt. Daher sollten SSL.com-Kunden keine unmittelbaren Probleme haben. Wir empfehlen Ihnen jedoch dringend, Ihre Zertifikate zu überprüfen Auf mögliche Weise können sich diese Entscheidungen auf Sie auswirken.
• Bestehende Zertifikate mit internen Namen werden nach dem 1. November 2015 nicht erneut ausgestellt.
  
  Auch hier hat SSL.com dafür gesorgt, dass Sie aufgrund dessen keine Probleme haben. Im Folgenden haben wir jedoch ein Worst-Case-Szenario für Ihre Bearbeitung vorgestellt.
• Bestehende Zertifikate mit internen Namen werden am 1. November 2016 AUTOMATISCH widerrufen.
  
  Dies ist eine Sammelrichtlinie, da einige Sicherheitsarchitekturen möglicherweise über bereits vorhandene Legacy-Zertifikate verfügen, die diese Regeln nicht einhalten.

Diese Änderungen führen dazu, dass E-Mails - das erste und immer noch nützlichste Tool im Internet - durch Änderungen negativ beeinflusst werden können, insbesondere wenn Sie den Exchange Server von Microsoft verwenden (laut Marktforschung sind es 63 Prozent von Ihnen). Daher könnte Ihre Sicherheitsarchitektur ab dem kommenden Allerheiligen beeinträchtigt werden.

Sind Sie bereit?

Was meinst du mit "internen Namen"?

Die einfachste Definition eines internen Namens ist eine Netzwerkkennung Teil eines privaten Netzwerks und Nicht erreichbar mit einem Namen, der eine Top Level Domain (TLD) oder eine eindeutige IP-Adresse verwendet. Folglich kann jede Netzwerk-ID, die öffentlich bei einer zentralen Behörde wie ICAAN registriert ist, in Zertifikaten verwendet werden

In den früheren, einfacheren Tagen des Internets musste sich eine interne DNS-Architektur nur darum kümmern, einen begrenzten Satz von TLDs zu vermeiden - daher konnte das Intranet von AwfulBigCo.com nicht nur unterstützen ABC.nyc und ABC.london aber 1600.pennsylvania.ave, E-mail und Gandalf. Außerdem, Einige Bereiche von IPv4- und IPv6-Adressen sind reserviert für den rein lokalen Gebrauch - diese reservierten Bereiche umfassen "192.168. *. *" für das Routing und 10. *. *. * für lokale Netzwerke. Das Sichern von Intranets mit SSL-Zertifikaten ist natürlich eine gute Idee, und bis zur neuen Entscheidung kann jeder Netzwerkadministrator ein Zertifikat anfordern und erhalten, das eines dieser Zertifikate enthält.

Ab dem 1. November 2015 ist dies nicht mehr der Fall - Zertifikate werden nicht mehr ausgestellt - oder entscheidend neu ausgestellt - die interne Namen enthalten. Diese neuen Regeln sollen sowohl die Sicherheit verbessern als auch die ordnungsgemäße Verwendung neuer Top-Level-Domain-Namen ermöglichen (z. B. sind sowohl .london als auch .nyc jetzt öffentliche TLDs). Jeder Exchange-Benutzer muss sich jedoch die Netzwerk- und Sicherheitseinstellungen genau ansehen und Änderungen vornehmen, um diese neuen Regeln zu bestätigen. Da in vielen Exchange-Sicherheitsdesigns in der Vergangenheit interne Namen verwendet wurden, kann dies zu schwerwiegenden Problemen mit Ihrem E-Mail-Dienst führen, wenn und wenn Ihre Zertifikate ablaufen, da keine neuen Zertifikate mit internen Namen ausgestellt werden können, um Ihre vorhandenen zu ersetzen - schlimmer noch, ein Zertifikat mit mehreren Domänen Wenn Sie nur einen internen Namen enthalten, schlägt die Erneuerung fehl und Ihr E-Mail-Verkehr ist möglicherweise böswilligen Exploits ausgesetzt.

Wenn Sie dies nicht tun, kann sich dies negativ auf Ihren E-Mail-Verkehr, Ihr Unternehmen und / oder Ihren Ruf auswirken.

Klingt dumm.

Es könnte sehr gut sein - es hängt wirklich davon ab, wie gut Sie vorbereitet sind. Dies könnte ein sehr leicht zu übersehendes Problem sein, und die Folgen könnten für Ihr Unternehmen absolut fatal sein - if Sie handeln nicht im Voraus.

Der Zertifikatsanbieter von AwfulBigCo hat seine Anfrage an seinen Robotern vorbeigeführt, diese internen Namen erkannt und (gemäß den Regeln des CA / B-Forums) die Verlängerung abgelehnt.

Das ist ein Problem. Der UCC wird NICHT erneuert und nicht nur Dienste, die die zulässigen internen Namen (dh alle Unternehmenspost und die FTP-Sicherungen) verwenden, werden nicht mehr geschützt, und auch keine anderen im UCC enthaltenen Domänen wie die primäre und die .co. UK Domains für AwfulBigCo.

Sicher, dies ist ein extremes Worst-Case-Szenario - aber wir glauben wirklich, dass die volle Sicherheit davon abhängt, sich darauf vorzubereiten.

Okay, ich habe Legit Scared - Was mache ich jetzt?

Wenn Sie in Ihren SSL-Zertifikaten interne Namen verwenden, müssen Sie Maßnahmen ergreifen, um dies zu beheben. Je früher, desto besser.

Grundsätzlich gibt es einige Optionen, die Sie auswählen können:

1. Konfigurieren Sie das System so, dass nur öffentlich registrierte Domainnamen verwendet werden.
   Dies ist wahrscheinlich die beste Lösung - es macht das interne Namensproblem strittig und wird in Zukunft insgesamt einfacher zu warten und zu erweitern sein. Leider erfordert diese Option im Vorfeld wahrscheinlich erhebliche Arbeit, aber Microsoft Exchange-Server können eingerichtet werden um vollqualifizierte Public Domain Namen zu verwenden (und dieses CA / Browser-Forum WHITE PAPER Weitere Informationen zum Implementieren von vollqualifizierten Domänennamen in Active Directory-Netzwerken. Die Verwaltung nach der Umstellung wird mit ziemlicher Sicherheit genauso einfach oder einfacher sein als zuvor (ein großes Plus für Bob). In Zukunft kann AwfulBigCo öffentlich vertrauenswürdige Zertifikate verwenden, um den gesamten Datenverkehr sowohl intern als auch extern zu sichern. Ein möglicher Nachteil dieser Methode besteht darin, dass möglicherweise Informationen über die interne Infrastruktur eines Unternehmens über DNS erkannt werden können. Eine geschickte Konfiguration von DNS-Zonen kann jedoch dazu beitragen, dies zu beheben, indem beispielsweise Subdomains wie „interne“ oder separate Domainnamen verwendet und die Auflösung eingeschränkt werden davon außerhalb von Unternehmensnetzwerken.
2. Registrieren Sie interne Namen als FQDNs.
   Leider gibt es keine Option für diese reservierte IP-Adresse, und "Mail" und "Gandalf" sind natürlich richtig. (Wir gehen aus Gründen der Gesundheit von Bob davon aus, dass die Domains .com und .co.uk bereits sicher registriert sind - sein Tag ist schon hart genug.)
   Auch wenn abc.austausch ist verfügbar - und denken Sie daran, dass .exchange eine der neuen TLDs ist, deren Einführung dazu beiträgt, diese Regeländerung voranzutreiben. Es könnte durchaus besetzt sein und nur zu einem exorbitanten Preis verfügbar sein. Einfachere und billigere Alternativen sind wahrscheinlich verfügbar.
3. Richten Sie eine Unternehmenszertifizierungsstelle ein
   Dies ist eine Methode, die bereits von wirklich großen Unternehmen angewendet wird, die hauptsächlich interne Kommunikation sichern müssen. Eine Unternehmenszertifizierungsstelle dient als Zertifizierungsstelle für Unternehmen. Im Wesentlichen werden anstelle der Vertrauenskette, die bis zu einer externen Zertifizierungsstelle läuft, alle Zertifikate letztendlich durch ein intern generiertes Stammzertifikat gesichert. Dies führt jedoch zu einer stärkeren Anpassung (und würde es Bob ermöglichen) Beibehaltung der alten Namensstruktur AwfulBigCo) Es gibt schwerwiegende Sicherheitsprobleme, die zu berücksichtigen sind. Ein Hack im Sony-Stil kann das Stammzertifikat und / oder den privaten Schlüssel des Unternehmens offenlegen und eine nahezu unbegrenzte Nutzung des Netzwerks ermöglichen. Intern ausgestellte Zertifikate werden an keiner anderen Stelle als vertrauenswürdig eingestuft. Dies ist eine Methode, die die interne Kommunikation sichert, aber das Vertrauen nicht über die Wände Ihres Unternehmensnetzwerks hinaus erweitern kann. Schließlich ist das Einrichten einer Unternehmenszertifizierungsstelle keineswegs eine Lösung über Nacht und möglicherweise viel schwieriger als die anderen hier aufgeführten Optionen und daher nur für sehr große (oder wachsende) Netzwerke geeignet.
   
   SSL.com bietet gerne Beratungs- und Verwaltungsdienste an, mit denen Sie den Weg zum Einrichten Ihrer eigenen Unternehmenszertifizierungsstelle aushandeln können. Senden Sie einfach eine Nachricht an Enterpriseca@ssl.com und einer unserer leitenden Administratoren wird Sie bald kontaktieren.
4. Verwenden Sie selbstsignierte Zertifikate
   Diese Option hat ähnliche Nachteile wie die Unternehmenszertifizierungsstelle, lässt sich jedoch nicht gut skalieren. Da jedes selbstsignierte Zertifikat keine über sich selbst hinausgehende Vertrauenskette aufweist, müsste jedes einzelne Zertifikat auf jedem Client installiert werden, um Fehlermeldungen zu vermeiden . Die Verwaltung über ein breites Netzwerk würde auch dem armen Bob eine Reihe neuer Kopfschmerzen bereiten - etwas so Einfaches wie automatische Browser-Updates könnte Chaos verursachen, wenn nicht auf jedem Gerät die ständige Wachsamkeit aufrechterhalten wird.

Wie immer, kontaktieren Sie uns bei SSL.com, wenn Sie Fragen haben. Denken Sie daran - ein sichereres Internet ist ein besseres Internet.