Die Einführung von digitalen Zertifikaten und PKI hat einiges in den letzten Jahren verändert. Vorbei sind die Zeiten, in denen Zertifikate nur Synonyme für SSL/TLS waren. Compliance-Triebkräfte wie stärkere Authentifizierungsanforderungen und Vorschriften für digitale Signaturen (wie z. B. eIDAS) haben die Rolle der PKI im Unternehmen stark erweitert.

Da sich der Einsatzbereich von PKI ausgeweitet hat, hat sich die Diskussion über die Anzahl und Art der benötigten Zertifikate hin zu einem tiefergehenden Dialog über benutzerdefinierte PKI-Bereitstellungen verschoben. Ein großer Teil der Diskussion dreht sich um untergeordnete Zertifizierungsstellen, die manchmal als ausstellende oder Zwischenzertifizierungsstellen bezeichnet werden, und warum es sinnvoll ist, dass ein Unternehmen seine eigene hat. Wenden wir uns dem Thema zu.

Was sind CA-Hierarchien und warum brauchen wir sie?

Bevor wir uns mit untergeordneten/Zwischenzertifizierungsstellen befassen, ist es wahrscheinlich hilfreich, das Thema CA-Hierarchien ein wenig aufzufrischen. Wie wir wissen, sind CAs Einheiten, die digitale Zertifikate ausstellen. Aber weniger bekannt ist, dass eine CA tatsächlich aus einer Reihe von CAs besteht. Obwohl ein Unternehmen wie GlobalSign als öffentliche CA (Singular) bezeichnet wird, betreiben wir in Wirklichkeit eine Reihe von CAs. Diese CA-Hierarchie schafft eine Vertrauenskette, auf die sich alle Endeinheitzertifikate verlassen.

Beispiel für CA-Hierarchien

Die Anzahl der Ebenen zwischen der Root und den Endeinheitzertifikaten und die Gesamtkomplexität der Hierarchie können je nach Umgebung stark variieren. Zum Beispiel haben einige unserer Kunden im IoT- und industriellen Internetbereich, die Geräteidentitätszertifikate in ihre Fertigungsprozesse einbauen, benutzerdefinierte Hierarchien mit wechselseitigem Vertrauen, separaten untergeordneten CAs für jede Komponente in der Lieferkette, standortspezifische CAs und mehr implementiert. Egal wie komplex die Gesamthierarchie auch ist, sie besteht immer noch aus drei Hauptkomponenten:

• Root-CA - Die Root-CA ist die höchste Hierarchieebene und dient als Vertrauensanker. Damit ein Endeinheitzertifikat vertrauenswürdig ist, muss die Root-CA, mit der es verkettet ist, in das Betriebssystem, den Browser, das Gerät oder was das Zertifikat validiert, eingebettet sein. Root-CAs sind stark gesichert und werden offline gehalten (mehr dazu unten).

• Untergeordnete CAs - Diese befinden sich zwischen der Root und Endeinheitzertifikaten. Ihr Hauptzweck besteht darin, die Zertifikattypen zu definieren und zu autorisieren, die von der Root-CA angefordert werden können. In öffentlichen Hierarchien muss man beispielsweise untergeordnete SSL- und S/MIME-CAs voneinander trennen. Ein anderes häufiges Szenario sind separate untergeordnete CAs für verschiedene Standorte oder eine CA für Zertifikate mit ECC-Schlüsseln und eine CA für RSA-Schlüssel.

Hinweis: Es kann eine oder mehrere untergeordnete CAs zwischen einer Root-CA und Endeinheitzertifikaten geben. Untergeordnete CAs, die zwischen der Root-CA und einer anderen untergeordneten CA liegen, werden manchmal Zwischen-CAs genannt (siehe Diagramm rechts oben). 

• • Endeinheitzertifikate - Dies sind die Zertifikate, die auf Servern, Computern, kryptografischer Hardware und Geräten installiert sind (z. B. SSL/TLS ausgestellt für Server, Code Signing, Clientzertifikate, die für Einzelpersonen zur E-Mail-Verschlüsselung, zum digitalen Signieren, Authentifizierung ausgestellt werden).

Jede Einheit wird von der ihr übergeordneten Einheit in der Hierarchie signiert, um die zuvor erwähnte Vertrauenskette zu schaffen. Die Root-CA ist selbstsigniert und signiert alle direkt darunterliegenden untergeordneten CAs. Diese wiederum signieren die unter ihnen liegenden Einheiten, entweder zusätzliche untergeordnete CAs oder die endgültigen Endeinheitzertifikate.

Sie können diese Hierarchie tatsächlich in Aktion sehen, wenn Sie sich die Details eines Zertifikats ansehen. Wenn Sie beispielsweise zu einer Website gehen, die SSL/TLS verwendet (suchen Sie nach dem HTTPS am Anfang der Adressleiste) und sich das Zertifikat ansehen, finden Sie den Zertifikatpfad. Im folgenden Beispiel sehen Sie:

• • Die Root-CA - "GlobalSign Root-CA - R3".
  • Untergeordnete CA - "GlobalSign Extended Validation CA - SHA256 - G3".
  • Endeinheitzertifikat - www.globalsign.com

Beispiel für den Zertifikatpfad eines öffentlich vertrauenswürdiges SSL/TLS-Zertifikats in Chrome.

Warum brauchen wir CA-Hierarchien?

Sie wundern sich vielleicht, warum wir diese Vertrauenskette in erster Linie brauchen. Schließlich ist jede CA in der Hierarchie in der Lage, Zertifikate auszustellen. Warum stellen wir dann nicht einfach direkt von der Root aus? Warum muss man sich mit der Pflege dieser separaten Einheiten herumschlagen?

Dies liegt daran, was passiert, wenn eine CA kompromittiert wird.  Dies sollte mit geeigneten Kontrollen nicht möglich sein. Aber im bedauerlichen Fall, dass es passiert, müssen die CA selbst und alles "darunter" - alle untergeordneten CAs und alle ausgestellten Zertifikate - widerrufen werden. Dies stellt ein besonders schwieriges Problem für Root-CAs dar, da sie als Vertrauensanker diejenigen sind, die überall verteilt und eingebettet sein müssen. Das bedeutet, dass, damit neuen Endeinheitzertifikaten wieder vertraut wird, müssen Sie sie erneut auf einzelne Root-Programme anwenden, die von Microsoft, Mozilla, Google, Apple (und dem Rest) ausgeführt werden, was ein ziemliches Unterfangen sein kann. Wenn diese Root öffentlich vertrauenswürdig sein muss, steht Ihnen bevor, sie an alle Browser, Betriebssysteme, Geräte, Konsolen, E-Mail-Clients, Programm-Suiten usw. zu verteilen - eine ziemlich lange Liste. Hinzu kommt das Problem, dass das Updaten von Roots, die in Geräten oder auf Geräten, die nicht remote zugänglich sind, hartcodiert sind, problematisch sein kann (z. B. POS-Systeme, Geldautomaten, vernetzte Telefone usw.).

Aus diesem Grund empfiehlt es sich, stattdessen Endeinheitzertifikate von den untergeordneten CAs auszustellen (und bei öffentlich vertrauenswürdigen Roots verbietet das CA/Browser Forum gänzlich die Ausstellung von Roots aus). Auf diese Weise minimieren Sie im Falle einer Kompromittierung das, was widerrufen und letztendlich ersetzt werden muss. Wenn eine Ihrer untergeordneten CAs kompromittiert wird, müssen Sie „nur“ diese und die darunter liegenden Zertifikate widerrufen. Zertifikate, die von anderen untergeordneten CAs ausgestellt wurden, wären immer noch in Ordnung und Sie müssten Ihre Vertrauensanker (d. h. Root-CAs) nicht neu verteilen. Dies ist auch der Grund für die extremen Sicherheitsmaßnahmen, die rund um die Root-CAs getroffen werden, und warum sie offline gehalten werden sollten - wenn etwas mit Ihrer Root-CA passiert, sehen Sie schlechten Zeiten entgegen. Sie sollten nur aktiviert werden, wenn sie benötigt werden, um eine neue untergeordnete CA oder eine Certificate Revocation List (CRL) zu signieren.

Warum brauchen Sie Ihre eigene untergeordnete CA?

Nachdem Sie nun wissen, was untergeordnete oder Zwischen-CAs sind und wo sie in die allgemeine CA-Architektur passen, können wir uns jetzt damit befassen, warum es sinnvoll ist, dass Unternehmen ihre eigene haben - d.h. eine dedizierte untergeordnete CA in ihrem Namen. Hier sind einige der häufigsten Gründe:

Client-Authentifizierung

Die zertifikatbasierte Client-Authentifizierung validiert häufig Zertifikate, die auf untergeordneten CAs basieren. Wenn Sie eine exklusive untergeordneten CA haben, können Sie einschränken, wer Zertifikate hat, die den Zugang zu einem System gewähren. Diese untergeordneten CAs können je nach den Anforderungen des Unternehmens privat oder öffentlich vertrauenswürdig sein.

SSL-Inspection/Entschlüsselung

Damit SSL Inspection Appliances Inhalte entschlüsseln und neuverschlüsseln können, müssen sie bei Bedarf Zertifikate ausstellen können. Dies bedeutet, dass sie eine eigene untergeordnete CA benötigen und dass diese nicht öffentlich vertrauenswürdig ist.

Weitere Informationen zu Überlegungen über untergeordnete und Root-CA für SSL Inspection finden Sie in unserem zugehörigen Blog.

Zertifikate für spezielle Anwendungsfälle

Einige Zertifikatarten, z. B. SSL/TLS und EV Code Signing, werden durch die Baseline Requirements des CA/Browser Forum geregelt, in denen beispielsweise Gültigkeitsdauer und Schlüsselgröße festgelegt sind. Alle öffentlich vertrauenswürdigen Zertifikate müssen diese Leitlinien einhalten. Zertifikate, die unter privaten Hierarchien ausgestellt werden, liegen jedoch außerhalb des Geltungsbereichs dieser Requirements und können ältere Anwendungen und eigene Konfigurationen, wie längere Gültigkeitsdauern und kleinere Schlüsselgrößen, unterstützen.

Hinweis: Wenn Sie nur private SSL/TLS-Zertifikate, aber keine dedizierte untergeordnete Zertifizierungsstelle benötigen, bietet GlobalSign auch gemeinsam genutzte (nicht dedizierte) privat vertrauenswürdige Zertifikate durch unseren IntranetSSL-Service an.

Benutzerdefinierte Profile

Sie können eine untergeordnete Zertifizierungsstelle so konfigurieren, dass sie Ihren spezifischen Anforderungen hinsichtlich erweiterter Schlüsselverwendung, Zertifikatrichtlinie, CRL-Verteilung, kurzlebigen Zertifikaten und mehr entspricht.

Branding

Für Unternehmen, die ihren Endkunden Zertifikate anbieten oder diese in ihre Dienste bündeln, kann eine dedizierte untergeordnete CA in ihrem Namen zusätzliche Branding-Möglichkeiten bieten. Das sehen wir am häufigsten bei Unternehmen, die ihren Endkunden SSL/TLS-Zertifikate anbieten (z. B. Hosting-Unternehmen, Webdesigner, E-Commerce-Plattformen), bei denen das Vorhandensein einer eigenen, öffentlich vertrauenswürdigen, untergeordneten CA heißt, dass sie Marken-Bestellseiten und -Zertifikate bereitstellen können.

So erhalten Sie Ihre eigene untergeordnete CA - Interne vs. gehostete PKI

Sie haben, wie bei bei so vielen anderen heutigen Aspekten der Technologie, die Möglichkeit, Ihre eigene CA aufzubauen oder eine SaaS-Lösung zu nutzen.

Wenn Sie jedoch öffentliches Vertrauen brauchen, ist diese Debatte irgendwie irrelevant - Sie müssen mit einer öffentlichen CA arbeiten. Für private Anwendungsfälle, wie die oben genannten und andere, die einzigartig für das Unternehmen sind, ist das Betreiben einer internen CA immer noch eine Option.

Warum sollten Sie eine eigene CA betreiben müssen?

In der Vergangenheit war es nicht so ungewöhnlich für große Unternehmen, PKI selbst zu übernehmen. Normalerweise geschah dies durch den Einsatz einer Microsoft CA und Zertifikatsdienste. Zusätzlich zu den allgemeinen Zielen, die für die meisten DIY vs. SaaS-Debatten gelten, wie größere Kontrolle und Sicherheit, sind einige der PKI-spezifischen Triebkräfte:

• Die Möglichkeit, sich mit Active Directory zu verbinden, um Zertifikate für alle mit Domänen verbundenen Benutzer und Endpunkte automatisch zu registrieren und installieren - dies reduziert den Zeitaufwand für die Verwaltung von Zertifikatlebenszyklen erheblich.
• Es ist kostenlos - Microsoft CA-Dienste sind in Windows Enterprise Server enthalten, sodass Sie nicht für einzelne Zertifikate oder unterstützende Dienste bezahlen müssen.
• Sie benötigen kein öffentliches Vertrauen. Ausgehend vom vorherigen Punkt: Warum sollte ein Unternehmen für öffentlich vertrauenswürdige Zertifikate bezahlen, wenn es nicht-öffentliche Zertifikate kostenlos erhalten kann?
• Dedizierte untergeordnete CAs - Indem Sie Ihre eigene PKI verwalten, können Sie eigene untergeordnete CAs schaffen und sicherstellen, dass nur Ihr Unternehmen Zugang zu diesen hat.

Neue Dienste von Drittanbieter-CAs haben Outsourcing zu einer Option gemacht

Ich habe extra oben "in der Vergangenheit" gesagt, weil es zwar immer noch viele Unternehmen gibt, die ihre eigenen internen CAs betreiben, und es immer noch einige berechtigte Gründe dafür gibt, viele der oben genannten Faktoren aber dank der Innovationen durch öffentliche CAs nicht mehr relevant sind. Die Integration in Active Directory, andere Automatisierungsmechanismen, die Möglichkeit, eine eigene untergeordnete CA zu haben (öffentlich vertrauenswürdig oder nicht) - dies alles ist jetzt durch viele öffentliche CAs verfügbar.

Die versteckten Kosten der internen PKI

Auch wenn Sie denken, dass ich den Kostenfaktor geflissentlich übergehe und vorschlage, dass alle die Tatsache ignorieren sollen, dass Microsoft CAs kostenlos sind, trifft "kostenlos" es hier nicht ganz genau. Obwohl Sie nicht für MS CA-Dienste oder die Zertifikate selbst bezahlen müssen, gibt es viel mehr, was in den Betrieb Ihrer eigenen CA fließt, von dem vieles die Gesamtbetriebskosten stark in die Höhe treiben kann.

Beispielsweise benötigen Sie Personal, um die CA und die Hardware zur Speicherung Ihrer Root und Signierschlüssel zu pflegen. Wenn Sie bedenken, dass ein einzelnes Hardwaresicherheitsmodul (HSM) 20.000 $ kosten kann und Sie mehr als eines für die Redundanz benötigen, können Sie sehen, dass diese versteckten Kosten nicht geringfügig sind.

Überlegungen zu Sicherheit und PKI für den Betrieb Ihrer eigenen CA

Die wohl wichtigsten Überlegungen in der ‚interne vs. gehostete PKI‘ -Debatte sind, zumindest für mich, Sicherheit der Infrastruktur, Verfügbarkeit und Einhaltung der Baseline Requirements. Wenn Sie auslagern, muss sich die öffentliche CA um das alles kümmern und Sie können sich stattdessen auf Ihre Kernkompetenzen konzentrieren. Wenn Sie sie intern betreiben wollen, müssen Sie Folgendes bedenken:

• wie Sie Ihre Offline-Root schützen und speichern wollen,
• Erstellen und Pflege einer CRL- und OCSP-Widerruf-Infrastruktur,
• ein Disaster Recovery Plan zur Wiederherstellung des Betriebs,
• Richtlinie und Prozedur für das Lebenszyklusmanagement, um sicherzustellen, dass nur autorisierte Benutzer Zugriff haben, Zertifikate nicht ablaufen und Ihre Hierarchie richtig gepflegt wird
• wie Sie Compliance mit diversen Netzwerkanforderungs-Audits und Root-Programmen erfüllen und aufrechterhalten wollen (wenn Sie öffentliches Vertrauen benötigen).

Wenn Sie sehen möchten, wie die Sicherheitsinfrastruktur von GlobalSign funktioniert, schauen Sie hier nach.

All dies bedeutet: Wenn Sie unter allen Umständen Ihre eigene interne CA betreiben möchten, dann tun Sie es! Beachten Sie jedoch alle beteiligten Faktoren und denken Sie daran, dass es Drittanbieter-CAs gibt, die Ihnen helfen können, Ihre Ziele zu erreichen (egal ob dies Automatisierung, Integration in Active Directory, private Hierarchien, benutzerdefinierte Zertifikatprofile, gehostete Widerrufdienste, dedizierte untergeordnete CAs usw. ist), ohne dass Sie sich selbst mit der PKI-Verwaltung belasten müssen.

Insbesondere sollten Sie wissen, dass es gehostete Optionen gibt, wenn Sie dedizierte untergeordnete CAs (öffentlich oder privat, aus einem der oben genannten Gründe und mehr) suchen. Sie müssen kein PKI-Experte sein, um PKI zu verwenden. Sie müssen nur wissen, mit wem Sie sprechen können.

Wenn Sie eine dedizierte untergeordnete CA und/oder eine interne PKI für einen der oben beschriebenen Anwendungsfälle in Betracht ziehen, sollten Sie wissen, dass das Outsourcing an eine Drittanbieter-CA eine Option ist. Die Verwaltung von CAs und Vertrauensankern, sowohl öffentlich als auch privat, ist das, was wir machen - lassen Sie uns dies für Sie erledigen. Kontaktieren Sie uns noch heute, wenn Sie Fragen hierzu haben.