Automatisierung der SAN-Konformität mit CMS 5.0

Chrome 58 Patch sorgt für Kontroverse und Aufregung

Vor einigen Monaten veröffentlichte Google einen Patch (v.58) für seinen weit verbreiteten Chrome-Browser. Dieser Patch zwang uns alle, die Art und Weise, wie wir Zertifikate ausstellen, in Frage zu stellen, und brach rückwirkend viele Browser- und Webserver-Verbindungen gleichzeitig.

Abbildung - 1

Das Support-Team von Certified Security Solutions (CSS) bearbeitete eine Flut von Anfragen und beriet unsere Kunden, wie sie mit diesem damals aktuellen Thema umgehen sollten. Nachdem wir den steigenden Bedarf an Support nach diesem Patch festgestellt hatten, veröffentlichten wir einen Blog-Artikel, in dem wir beschrieben, wie wir dieses Problem kurz- und langfristig lösen können. Die langfristige Lösung bestand darin, die Subject Alternative Names (SANs) -Attributeinträge in der Umgebung zu korrigieren und einige Best Practices für die Ausstellung von Zertifikaten zu übernehmen. Dies wäre letztlich die beste Lösung für die Zukunft, da das Attribut "CommonName" (CN=Maschinenname) allein nicht mehr RFC 2818-konform wäre (Feld, das in einem Zertifikat für die TLS -Verschlüsselung verwendet wird), um die TLS -Verschlüsselung zu ermöglichen und schließlich mindestens ein SAN-Attribut für das Domain Name System (DNS) zu erzwingen. Als diese Bemühungen als Lösung feststanden und die Ausfälle behoben wurden, tauchte ein weiteres Problem auf.

Sowohl die Administratoren als auch die für die Ausstellung von Bescheinigungen zuständigen Mitarbeiter standen nun vor neuen Herausforderungen bei der Einführung dieser besseren Verfahren in der Organisation. Frühere Prozesse waren bereits definiert und die Ausstellung von Zertifikaten war bereits seit vielen Jahren automatisiert. Einige dieser Prozesse reichen bis Mai 2000 zurück, als das Attribut "CommonName" noch für die Verschlüsselung von TLS akzeptiert wurde. Das CSS-Supportteam dokumentierte verschiedene Anwendungsfälle und Verfahren für Kunden. Durch die Beratung des Kunden in Verbindung mit den internen Experten für Public Key Infrastructure (PKI) und den Erkenntnissen des Entwicklungsteams war CSS in der Lage, eine praktikable Lösung für die bestehenden PKI- und Zertifikatsprozesse zu entwickeln, die in der neuen Version der branchenführenden digitalen Zertifikats- und PKI-Verwaltungsplattform CMS 5.0 verfügbar sind.

Nahtlos ist hier wirklich das Schlüsselwort. Bei bestehender und neu aufgebauter PKI-Infrastruktur und -Richtlinien ist die Notwendigkeit, ein Problem ohne langwieriges, zeitraubendes "Rip & Replace" von Prozessen oder PKI zu lösen, um ein bereits untergegangenes Problem zu beheben, von größter Bedeutung. Wie kann CMS genutzt werden, um diesen Zustand zu beheben?

In den meisten Fällen müssen wir, um ein andauerndes Problem zu stoppen, zuerst erkennen, woher das Problem kommt, und aufhören, ihm Nahrung zu geben. Mit dem Patch für Chrome 58 wurde der Schuldige in der anfänglichen Zertifikatsregistrierung gefunden. Die Webserver- und Administratorenteams müssen aufhören, Zertifikate zu registrieren und auszustellen, die nicht beanstandet wurden. Das hört sich einfach an, aber die Herausforderung lag in größeren Organisationen, in denen Prozesse und Automatisierung seit Jahren definiert waren. Es ist auch leicht möglich, dass Zertifikate ausgestellt werden, ohne dass die neue SAN-Attribut-Anforderung erfüllt ist. CSS hat in CMS 5.0 eine Option eingebaut, die die Registrierung für ein Zertifikat bei einer bestimmten Zertifizierungsstelle (CA), die auf einem der CMSAdminEnroll-Portale definiert ist, nicht zulässt (CMS 5.0-Funktion zur Ausstellung von PFX und CSRs).

Abbildung - 2

Dadurch wird eine nahtlose Grenze der Konformität geschaffen, indem das CMS 5.0-Produkt als einfacher Ein- und Ausschalter für eine bestimmte CA verwendet wird, der Operationen für die Registrierung übertragen werden (CA definiert in CMS für die Registrierung). Wenn also eine Ausstellung über das CMSAdminEnroll-Portal erfolgt, wird CMS jeden Versuch, dieses Zertifikat auszustellen, das nicht mindestens einen DNS SAN-Eintrag hat, ablehnen.

Um das Wort nahtlos noch einen Schritt weiter zu führen, hat CSS auch ein CA-Richtlinienmodul entwickelt, das einer Zertifikatsanforderung automatisch mindestens ein SAN hinzufügt.

Richtlinienmodule sind Programme, die Anforderungen von den Zertifikatsdiensten empfangen, diese Anforderungen bewerten und optionale Eigenschaften der Zertifikate angeben, die zur Erfüllung dieser Anforderungen erstellt werden.

Abbildung - 3

Zu diesem Zweck wird der RFC 2818 Policy Handler auf der CA installiert und dann werden bestimmte Vorlagen in der Handler-Konfiguration definiert. Wenn die CA eine Zertifikatsanforderung für diese bestimmte Vorlage erhält, übernimmt sie das Attribut "CommonName" der Zertifikatsanforderung und setzt es als DNS SAN-Attribut ein, wodurch das Zertifikat konform wird.

Abbildung - 4

Nahtlose Automatisierung von SANs - Nachbereitung der Compliance

Wir sprachen über einige der Probleme bei der Generierung von SAN-Attributen und die nahtlose Integration, die dazu beiträgt, die Zügel bei der Herausgabe und Einhaltung von Vorschriften in der Hand zu halten. Wir stellten auch die neueste Version von CMS 5.0 vor (erzwungene Beschwerdeeinträge und Richtlinienmodul), die dazu beitragen kann, Ausfälle und Anwendungsausfallzeiten zu vermeiden.

Weitere großartige Funktionen und Verbesserungen von CMS 5.0:

• stabilere Arbeitsabläufe für die Zertifikatserneuerung
• Unterstützung für die Verwaltung von NetScaler-Zertifikaten
• erweiterte Optionen für den Datenbankschutz
• Agentenentwürfe
• Web-API (Anwendungsprogrammierschnittstelle) PowerShell SDK
• Vollständige Überarbeitung der Benutzeroberfläche

Die neuesten Funktionen machen die digitale Zertifikats- und PKI-Managementplattform CMS von CSS nicht nur zu einer Notwendigkeit, sondern zu einem Kraftpaket für jede Organisation und jedes Unternehmen.