In der heutigen Zeit ist es unumgänglich, die Authentisierung von Geräten am Unternehmens-Netzwerk sowie administrative Schnittstellen zu schützen. In der Regel kommen hierbei auf digitale Zertifikate zum Einsatz.
Auch Drucker benötigen somit in der Regel digitale Zertifikate, um sicher betrieben werden zu können. Ab einer gewissen Anzahl von Geräten kommt man um eine automatische Zertifikatverteilung nicht mehr herum.
Manche Drucker-Hersteller bieten für die Zertifikatverteilung zentrale Management-Lösungen an.
Leider zeigt sich immer wieder, dass der sichere Umgang digitalen Zertifikaten viel Wissen, Erfahrung und Sorgfalt erfordert, was leider oft nicht gegeben ist.
Im konkreten Fall ist die Zertifikatbeantragung durch die Management-Lösung so implementiert, dass der für Webserver-Zertifikate zwingend erforderliche Alternative Antragstellername nicht – wie es eigentlich vorgesehen ist – als Teil der Zertifikatanforderung übertragen wird, sondern (Microsoft-proprietär) über das "san" Request-Attribut.
Dieses Attribut wird aber nur dann verarbeitet, wenn das hochgefährliche EDITF_ATTRIBUTESUBJECTALTNAME2 Flag auf der Zertifizierungsstelle aktiviert ist, was im schlimmsten Fall zur Kompromittierung der kompletten Active Directory Gesamtstruktur des Unternehmen führen kann.
Hier laufen wir in ein recht typisches Problem in der PKI-Welt: Auf der einen Seite möchten wir all unsere Geräte mit Zertifikaten ausstatten können, um das Sicherheits-Niveau anheben zu können. Auf der anderen Seite wollen wir hierfür keinesfalls die Sicherheit unserer PKI reduzieren.
Darauf, dass der Hersteller seine fehlerhafte Implementierung korrigiert, kann man in der Regel nicht bauen. In der Regel wird hier argumentiert, dass doch alles funktioniere, wie es soll – in diesem Fall eben die Ausstellung der Zertifikate. Oft ist auch eine vermeintlich einfache Änderung an einem Software-Produkt für den Hersteller ein kompliziertes Unterfangen, da der ursprüngliche Entwickler des Codes vielleicht gar nicht mehr zur Verfügung steht.
Wie lösen wir also nun das Dilemma?
Die Lösung: Das TameMyCerts Policy Modul für Microsoft Active Directory Certificate Services
Mit dem TameMyCerts Policy Modul für die Microsoft Active Directory Certificate Services gibt es nun eine Möglichkeit, auf sichere Weise und vollautomatisch fehlerhafte oder unvollständige Zertifikatanforderungen zu korrigieren – ohne hierfür unsichere Einstellungen auf der Zertifizierungsstelle aktivieren zu müssen.
TameMyCerts ist ein Policy Modul, um die Microsoft Zertifizierungsstelle (Active Directory Certificate Services) abzusichern. Es erweitert die Funktionen der Zertifizierungsstelle und ermöglicht die erweitere Anwendung von Regelwerken, um die sichere Automatisierung von Zertifikatausstellungen zu ermöglichen. TameMyCerts ist einzigartig im Microsoft-Ökosystem und steht unter einer freien Lizenz. Es kann über GitHub heruntergeladen und kostenlos verwendet werden.
Die Lösung unseres Dilemmas liegt also darin, das gefährliche EDITF_ATTRIBUTESUBJECTALTNAME2 auf der Zertifizierungsstelle zu deaktivieren, und TameMyCerts entsprechend zu konfigurieren, den Subject Alternative Name (SAN) automatisch aus dem im Subject Distinguished Name (DN) vorhandenen DNS-Namen zu erzeugen.
TameMyCerts ist Open Source und kann kostenfrei verwendet werden. Für den Einsatz im Unternehmensbereich empfiehlt sich jedoch der Abschluss eines Wartungsvertrags. Dies stellt sicher, dass Sie qualifizierte Unterstützung erhalten und dass das Modul langfristig in hoher Qualität weiterentwickelt werden kann.
Weiterführende Links:
- Ein Policy Modul, um sie zu bändigen: Vorstellung des TameMyCerts Policy Moduls für Microsoft Active Directory Certificate Services
- Gefährdung der Active Directory Gesamtstruktur durch das Flag EDITF_ATTRIBUTESUBJECTALTNAME2
- Wie das TameMyCerts Policy Modul für Active Directory Certificate Services (ADCS) eingehende Zertifikatanträge reparieren kann, um sie RFC-konform zu machen
- Den Subject Alternative Name (SAN) eines Zertifikats vor dessen Ausstellung verändern – aber sicher!