Zertifizierungsstelle – Uwe Gradenegger

Grundlagen: Deltasperrlisten

Um ausgestellte Zertifikate vor Ende ihrer Gültigkeitsdauer aus dem Verkehr ziehen zu können, werden Zertifikatsperrlisten (engl. "Certificate Revocation List", CRL) eingesetzt.

Hierbei handelt es sich um eine signierte Liste der Seriennummern von Zertifikaten, die von der Zertifizierungsstelle widerrufen wurden. Die Sperrliste hat ein (in der Regel wenige Tage kurzes) Ablaufdatum und wird von der zugehörigen Zertifizierungsstelle in regelmäßigen Abständen neu ausgestellt und signiert.

Zertifikatsperrlisten können bei einem hohen Volumen widerrufener Zertifikate eine beträchtliche Größe erreichen (als Faustregel kann man mit ca. 5 Megabyte pro 100.000 Einträgen rechnen). Der regelmäßige Download großer Zertifikatsperrlisten durch die Teilnehmer kann eine große Netzwerklast erzeugen. Um dieses Problem zu adressieren gibt es das Konzept der Deltasperrlisten.

Rückbau einer Active Directory integrierten Zertifizierungsstelle (Enterprise CA)

Anleitungen für den Aufbau und die Inbetriebnahme von IT-Diensten gibt es sehr viele. Meistens wird jedoch die dazugehörige Anleitung für die Außerbetriebnahme vergessen.

Nachfolgend wird beschrieben wie eine ins Active Directory integrierte Zertifizierungsstelle (Enterprise Certification Authority) korrekt außer Betrieb genommen wird.

Nachträgliche Archivierung privater Schlüssel

Für die Veschlüsselung von E-Mail Nachrichten verwenden Unternehmen üblicherweise den Secure / Multipurpose Internet Message Extensions (S/MIME) Standard und stellen ihren Benutzern hierfür entsprechende Zertifikate zur Verfügung.

Ein wichtiger Aspekt hierbei ist, dass die privaten Schlüssel der Benutzer – im Gegensatz zu den ansonsten meist verwendeten Signaturzertifikaten – zentral gesichert werden sollten. Eingehende Nachrichten sind für einen bestimmten privaten Schlüssel verschlüsselt und können nur von diesem auch wieder entschlüsselt werden. Somit muss unbedingt eine Sicherung dieser Schlüssel vorliegen – auch für die Synchronisierung auf mobile Endgeräte ist dies unabdingbar. Hierfür bieten die Microsoft Active Directory Certificate Services die Funktion der Archivierung privater Schlüssel (engl. Private Key Archival).

Was aber, wenn die Archivierung der privaten Schlüssel nicht eingerichtet wurde, und Benutzer bereits entsprechende Zertifikate beantragt haben?

Signieren von Zertifikaten unter Umgehung der Zertifizierungsstelle – allein mit Bordmitteln

Im Artikel "Signieren von Zertifikaten unter Umgehung der Zertifizierungsstelle" habe ich beschrieben, wie sich ein Angreifer, der im Besitz administrativer Rechte auf der Zertifizierungsstelle ist, unter Umgehung der Zertifizierungsstellen-Software, also unter direkter Verwendung des privaten Schlüssels der Zertifizierungsstelle, ein Anmeldezertifikat für administrative Konten der Domäne erzeugen kann.

Im vorigen Artikel habe ich das PSCertificateEnrollment Powershell Modul verwendet, um das Vorgehen zu demonstrieren. Microsoft liefert mit certreq und certutil allerdings bereits ab Werk perfekt geeignete Pentesting-Werkzeuge direkt mit dem Betriebssystem mit.

Die Installation eines neuen Zertifizierungsstellen-Zertifikats schlägt fehl mit Fehlercode "ERROR_INVALID_PARAMETER"

Folgendes Szenario angenommen:

Für eine untergeordnete Zertifizierungsstelle wird ein neues Zertifizierungsstellen-Zertifikat beantragt und von der übergeordneten Zertifizierungsstelle ausgestellt.
Der Subject Distinguished Name (Subject DN) ist identisch zu dem des vorigen Zertifizierungsstellen-Zertifikats.
Dennoch schlägt die Installation des Zertifizierungsstellen-Zertifikats mit folgender Fehlermeldung fehl:

An error was detected while configuring Active Directory Certificate Services.
The Active Directory Certificate Services Setup Wizard will need to be rerun to complete the configuration.
The new certificate subject name does not exactly match the active CA name.
Renew with a new key to allow minor subject name changes: The parameter is incorrect. 0x80070057 (WIN32: 87 ERROR_INVALID_PARAMETER).

Zeichenkodierung im Subject Distinguished Name von Zertifikatanforderungen und ausgestellten Zertifikaten

Üblicherweise ist die Kodierung von Zeichen und Zeichenketten in Zertifikaten kein Thema, welches die Nutzer einer PKI groß interessiert. Es gibt jedoch Fälle, in welchen die Standardeinstellungen der Zertifizierungsstelle nicht die gewünschten Ergebnisse liefern.

Ein Policy Modul, um sie zu bändigen: Vorstellung des TameMyCerts Policy Moduls für die Microsoft Zertifizierungsstelle

Als Betreiber einer Zertifizierungsstelle ist man (unter Anderem) für die Identifikation der Antragsteller und die Bestätigung der beantragten Identitäten verantwortlich. Dass diese Aufgabe gewissenhaft und fehlerfrei ausgeführt wird, ist der zentrale Grundpfeiler für das Vertrauen, dass der Zertifizierungsstelle eingeräumt wird. Namhafte Firmen sind bereits an dieser Aufgabe gescheitert, mussten in Folge von Falschausstellungen sogar Insolvenz anmelden und/oder wurden durch die großen Player am Markt empfindlich bestraft.

In vielen Fällen sind wir als (Microsoft-)PKI-Betreiber in Unternehmen (ungeachtet der damit einhergehenden Qualität) in der Lage, unsere Aufgabe der eindeutigen Identifikation eines Antragstellers an das Active Directory zu delegieren. In vielen Fällen müssen wir unsere Zertifizierungsstelle(n) aber auch anweisen, einfach alles auszustellen, was beantragt wird.

Die Partition des Hardware Security Moduls (HSM) läuft voll

Folgendes Szenario angenommen:

Eine Zertifizierungsstelle verwendet ein Hardware Security Modul (HSM).
Die Partition des Hardware Security Moduls füllt sich über die Lebenszeit der Zertifizierungsstelle mit immer mehr Schlüsseln.
Bei SafeNet Hardware Security Modulen kann dies sogar dazu führen, dass die Partition voll läuft. In Folge dessen werden die Ereignisse 86 und 88 der Zertifizierungsstelle protokolliert.

Änderungen an der Zertifikatausstellung und an der zertifikatbasierten Anmeldung am Active Directory mit dem Patch für Windows Server vom 10. Mai 2022 (KB5014754)

Mit dem Patch vom 10. Mai 2022 versucht Microsoft, eine Sicherheitslücke im Active Directory zu schließen, in welcher die zertifikatbasierte Anmeldung (im Allgemeinen bekannt als PKINIT oder auch Smartcard Logon) zu schließen.

Das Update ändert sowohl das Verhalten der Zertifizierungsstelle als auch das Verhalten des Active Directory beim Verarbeiten von zertifikatbasierten Anmeldungen.

Grundlagen: Namenseinschränkungen (Name Constraints)

Namenseinschränkungen sind ein Teil des X.509 Standard und im RFC 5280 beschrieben. Sie sind ein Werkzeug, das im Rahmen der qualifizierten Subordinierung eingesetzt werden kann, um den Gültigkeitsbereich eines Zertifizierungsstellenzertifikats feingranular zu steuern.

Es wird Zeit: Migrieren der PKI Komponenten von Windows Server 2012 auf ein neues Betriebssystem

Zum Jahreswechsel ein Hinweis an alle Betreiber einer Microsoft Zertifizierungsstelle und angeschlossener Dienste:

Das Ende der Produktunterstüzung von Microsoft für Windows Server 2012 und 2012 R2 rückt langsam näher, es ist der 10. Oktober 2023.

Es wird somit Zeit, den Umzug auf ein neues Betriebssystem vorzubereiten.

Grundlagen: Elliptische Kurven in Hinsicht auf ihre Verwendung in der Public Key Infrastruktur

Mit Windows Vista und Windows Server 2008 wurde die Cryptography API: Next Generation (CNG) in die Windows Systeme eingeführt.

Unter diesem Begriff wird eine Sammlung moderner kryptographischen Funktionen verstanden. Unter Anderem ermöglicht die CNG die Verwendung von Zertifikaten, welche auf elliptischen Kurven (auch Elliptic Curve Cryptography, ECC genannt) basierende Schlüssel verwenden, mit der Microsoft Zertifizierungsstelle und dem Windows Betriebssystem.

Betreiben der Zertifizierungsstelle ohne Exit Modul

Wird eine Zertifizierungsstelle installiert, ist automatisch das "Windows Default" Exit Modul aktiviert. Dieses ermöglicht den Versand von E-Mail Nachrichten bei bestimmten Ereignissen der Zertifizierungsstelle. Die meisten Unternehmen verwenden diese Funktion jedoch überhaupt nicht.

Aber auch wenn das Exitmodul überhaupt nicht verwendet wird, verursacht es Sitzungen auf der Zertifizierungsstellen-Datenbank (siehe Ereignis Nr. 46). Auf Zertifizierungsstellen mit hoher Last kann dies problematisch sein.

Wenn die Funktionen, die es bietet, gar nicht verwendet werden (unter Windows Server Core funktioniert das "Windows Default" Exitmodul grundsätzlich nicht), kann es auch komplett deaktiviert werden.

Das Datenbankschema der Zertifizierungsstellen-Datenbank

Möchte man Abfragen gegen die Zertifizierungsstellen-Datenbank formulieren, muss man zuerst wissen, wonach man suchen möchte.

Es gibt die Möglichkeit, das Datenbankschema der Zertifizierungsstellen-Datenbank ausgeben zu lassen.

Grenzen der Microsoft Active Directory Certificate Services

Die Active Directory Certificate Services bestehen (wenn auch unter anderem Namen) in ihren Grundzügen seit Windows NT 4.0. Die heutzutage verwendete auf Active Directory besierende Architektur wurde mit Windows 2000 Server eingeführt. Die AD CS sind sehr gut in das Windows-Ökosystem integriert und erfreuen sich weiterhin weltweit großer Beliebtheit in Unternehmen und Behörden jeglicher Größenordnung.

Gerne wird auf die vielen Möglichkeiten hingewiesen, welche die Active Directory Certificate Services bieten. Selten wird allerdings darauf verwiesen, was mit ihnen nicht möglich ist. Das Produkt stößt nämlich mittlerweile an vielen Stellen auch an seine Grenzen.

Welche das sind, soll nachfolgend näher ausgeführt werden, um besser entscheiden zu können, ob die AD CS für geplante Vorhaben die richtige Lösung sein können.

Deutsch