TameMyCerts als Policy-Modul – wann sinnvoll, wann übertrieben

Kurzfassung vorab: TameMyCerts ist ein kostenloses Open-Source-Policy-Modul, das genau dort ansetzt, wo das native ADCS-Vorlagenmodell an seine Grenzen stößt: bei der inhaltlichen Prüfung von Zertifikatsanträgen. Es schließt ESC1- und ESC6-Lücken auf Ausstellungsebene, indem es SAN-Inhalte filtert, an AD-Attribute bindet und Formate erzwingt. Meine ehrliche Position: Für Vorlagen mit „SAN aus dem Request" ist es nahezu konkurrenzlos — für eine saubere Standard-PKI ohne diese Anforderung ist es schlicht überflüssig.

Abb. 1: TameMyCerts als Policy-Modul im Ausstellungsfluss — es prüft jeden Request gegen XML-Regeln, bevor die CA das Zertifikat signiert.

1. Was ein Policy-Modul überhaupt macht

Um TameMyCerts einzuordnen, musst du verstehen, wo es im Ausstellungsprozess sitzt. Jede Windows-CA hat ein Policy-Modul — standardmäßig das mitgelieferte „Windows Default". Dieses Modul entscheidet bei jedem eingehenden Antrag, ob das Zertifikat sofort ausgestellt, zurückgehalten (Pending) oder abgelehnt wird. Das Default-Modul ist dabei erschreckend simpel: Es prüft im Wesentlichen die Vorlagen-Berechtigung und gut ist.

Genau hier liegt das Problem. Wenn eine Vorlage „SAN aus dem Request" erlaubt, prüft das Default-Modul den Inhalt dieses SAN nicht. Der Antragsteller darf reinschreiben, was er will — und wir sind mitten in ESC1. TameMyCerts ersetzt das Default-Policy-Modul und schiebt eine regelbasierte Inhaltsprüfung dazwischen. Pro Vorlage definierst du in einer XML-Datei, was erlaubt ist: welche SAN-Typen, welche Werte, welche Formate, welche Bindung an das antragstellende Konto.

2. Was TameMyCerts kann, was Bordmittel nicht können

Der Kern der Sache: Es gibt eine Reihe von Sicherheits- und Compliance-Anforderungen, die sich mit der nativen Vorlagen-Konfiguration schlicht nicht abbilden lassen. Genau diese Lücke füllt das Modul. Die wichtigsten Fähigkeiten:

Das mit Abstand stärkste Argument ist die Bindung an AD-Attribute. Damit lässt sich erzwingen, dass ein Antragsteller nur ein Zertifikat bekommt, dessen SAN tatsächlich zu seinem eigenen AD-Konto passt — der UPN im Zertifikat muss dem UPN des antragstellenden Kontos entsprechen. Damit ist ESC1 auf Ausstellungsebene tot, selbst wenn die Vorlage „SAN aus dem Request" weiterhin erlaubt. Das ist genau die Konstellation, die in Auto-Enrollment-Szenarien mit Geräte-Zertifikaten oft unvermeidbar ist.

3. Wann es sinnvoll ist — und wann Overkill

Jetzt zur Gretchenfrage, die mir in jedem zweiten Workshop gestellt wird: „Sollen wir das einsetzen?" Meine Antwort ist konsequent dieselbe — es kommt darauf an, ob du Vorlagen betreibst, die SAN aus dem Request erlauben und die du nicht abschalten kannst. Der folgende Entscheidungsbaum bringt es auf den Punkt:

Abb. 2: Entscheidungsbaum — TameMyCerts lohnt sich genau dort, wo die native Vorlage das Risiko nicht allein bändigt.

Die ehrliche Einordnung in drei Sätzen: Wenn deine PKI nur Auto-Enrollment mit sauberen Vorlagen fährt, bei denen der SAN aus dem AD kommt und nicht aus dem Request, brauchst du TameMyCerts nicht. Dann erledigt die Vorlagen-Konfiguration alles. Sobald du aber Szenarien hast, in denen der Antragsteller den SAN mitliefern muss — etwa bei bestimmten SCEP/NDES-Setups, manchen Web-Server-Vorlagen oder Drittanbieter-Integrationen — wird TameMyCerts vom Nice-to-have zum Sicherheitsnetz.

4. Installation und eine Beispielregel

Die Installation ist unspektakulär: MSI-Paket auf der Issuing CA installieren, CA-Dienst neu starten, fertig. TameMyCerts klinkt sich als Policy-Modul ein und liest pro Vorlage eine gleichnamige XML-Datei aus seinem Konfigurationsverzeichnis. Liegt für eine Vorlage keine Regeldatei vor, verhält es sich wie das Default-Modul und stellt normal aus — das macht den Rollout schön granular.

Eine typische Regel, die ESC1 für eine Web-Server-Vorlage entschärft, sieht im Kern so aus: Sie erlaubt im SAN ausschließlich DNS-Namen (keine UPNs, keine anderen Typen), begrenzt deren Anzahl und prüft sie gegen ein erlaubtes Namensmuster. Die XML ist gut lesbar und dokumentiert — du definierst Erlaubtes statt Verbotenes, was den Wartungsaufwand niedrig hält. Ein Antrag, der einen UPN „Administrator@domain" mitschmuggeln will, fällt damit durch, weil UPNs für diese Vorlage gar nicht erst zugelassen sind.

5. Praxis-Beispiel — die Musterwerk GmbH

Die Musterwerk GmbH, ein Industrie-Mittelständler mit rund 1.200 Mitarbeitern, betrieb ein gewachsenes NDES/SCEP-Setup, über das Intune-verwaltete Geräte ihre Zertifikate bezogen. Das Problem: Die SCEP-Architektur erfordert konstruktionsbedingt eine Vorlage, bei der der SAN aus dem Request kommt — abschalten war also keine Option, ohne das gesamte Geräte-Enrollment lahmzulegen. Im ESC-Scan leuchtete diese Vorlage erwartungsgemäß rot auf.

Die klassische Gegenmaßnahme „SAN-Flag entfernen" schied aus. Manager-Approval für jedes einzelne Geräte-Zertifikat war bei mehreren tausend Geräten ebenfalls indiskutabel. Genau hier spielte TameMyCerts seine Stärke aus: Wir haben eine Regel definiert, die für diese Vorlage ausschließlich Geräte-SANs in einem festgelegten Namensschema zulässt und die Anzahl der SAN-Einträge begrenzt. Ein Versuch, über diese Vorlage ein Auth-Zertifikat für ein Benutzerkonto zu ziehen, scheitert seitdem an der Inhaltsprüfung.

Wichtig für die Ehrlichkeit des Beispiels: Wir haben das Modul nur auf dieser einen problematischen Vorlage scharfgeschaltet. Die übrigen rund vierzig Vorlagen der Musterwerk-PKI laufen weiter über das saubere native Modell — sie brauchen TameMyCerts gar nicht. Genau so sollte es sein: gezielter Einsatz dort, wo es ein echtes Problem löst, statt flächendeckende Einführung aus Prinzip. Der Aufwand für die eine Regel inklusive Audit-Modus-Test: ein halber Tag.

Verwandte Themen

Pillar-Seite: Active Directory Certificate Services – der komplette Leitfaden

Häufige Fragen (FAQ)

Was ist TameMyCerts?

TameMyCerts ist ein kostenloses Open-Source-Policy-Modul für die Windows-Zertifizierungsstelle, das die native Inhaltsprüfung von Zertifikatsanträgen erweitert. Es ersetzt das Default-Policy-Modul und prüft jeden Antrag gegen pro Vorlage definierte XML-Regeln — etwa erlaubte SAN-Typen, Namensmuster oder die Bindung an das antragstellende AD-Konto. Es stammt von einem ehemaligen Microsoft-PKI-Berater und nutzt die offizielle Policy-Modul-Schnittstelle.

Wann sollte ich TameMyCerts einsetzen?

Immer dann, wenn du Vorlagen betreibst, die „SAN aus dem Request" erlauben und die du nicht abschalten kannst — etwa in SCEP/NDES-Setups oder bestimmten Web-Server-Szenarien. Dort schließt es die ESC1-Lücke auf Ausstellungsebene. Wenn deine PKI dagegen nur saubere Auto-Enrollment-Vorlagen fährt, bei denen der SAN aus dem AD kommt, brauchst du es nicht.

Ist TameMyCerts ein Ersatz für saubere Vorlagen?

Nein. Es ist ein Sicherheitsnetz für die Fälle, die sich nicht anders lösen lassen, kein Freibrief für großzügige Vorlagen. Die Vorlage selbst muss so eng wie möglich konfiguriert bleiben. Fiele das Modul aus oder würde die Regeldatei gelöscht, stünde eine zu großzügige Vorlage wieder offen — deshalb härtet man beides, nicht nur das Modul.

Was kann TameMyCerts, was ADCS nativ nicht kann?

Vor allem die inhaltliche Prüfung von SAN-Einträgen: Whitelisting erlaubter Namen, Bindung des SAN an das antragstellende AD-Konto, Regex-Prüfungen auf Subject und SAN sowie das Verbot bestimmter SAN-Typen. Besonders die AD-Bindung ist mächtig, weil sie ESC1 auch dann unterbindet, wenn die Vorlage SAN aus dem Request weiterhin erlaubt. All das bildet das native Vorlagenmodell nicht ab.

Ist der Einsatz im Audit problematisch?

In der Regel nicht. TameMyCerts nutzt die offizielle, von Microsoft dokumentierte Policy-Modul-Schnittstelle und ist quelloffen einsehbar — das macht es deutlich besser vertretbar als undokumentierte Bastellösungen. Wichtig ist, den Einsatz im PKI-Konzept zu dokumentieren und die Regeldateien in die Konfigurationsverwaltung aufzunehmen.

Wie führe ich TameMyCerts gefahrlos ein?

Über den Audit-Modus. In diesem protokolliert das Modul, welche Anträge es ablehnen würde, ohne sie tatsächlich abzulehnen. So prüfst du gegen den realen Antragsverkehr, ob deine Regeln legitime Anträge erwischen, und korrigierst sie, bevor du scharfschaltest. Erst nach einer sauberen Audit-Phase aktivierst du die Durchsetzung.

Nächste Schritte mit boddenberg.de

Ob ein Policy-Modul für deine Umgebung das richtige Werkzeug ist, hängt an deinen konkreten Vorlagen und Enrollment-Szenarien. Drei Wege, das zu klären und umzusetzen:

Kontakt: Uli Boddenberg · boddenberg.de · Dortmund