CA Planung

Immer mehr Dienste und Produkte nutzen Zertifikate für die Absicherung von Zugriffen, den Nachweis der Identität oder Verschlüsselung von Daten. SSL ist eine der wesentlichen Komponenten, um eine Datenübertragung zu sichern. Dazu zählen zwei wichtige Aspekte:

  • Verschlüsseln der Daten
    Mit dem asymmetrischen Schlüssel
  • Kontrolle des richtigen Zielsystem
    Mit einem Zertifikat können Sie sicherstellen, dass Sie auch auf dem "richtigen" Server gelandet sind und nicht jemand anderes ihre Daten annimmt um Sie auszuspähen.

Dabei handelt es sich bei weitem nicht nur um Probleme von Banken, Sparkassen und Katalogwebseiten, die per SSL die Kundendaten sichern wollen, sondern gerade auch im internen Einsatz wird der Einsatz von Zertifikaten immer wichtiger. Beispiele sind:

  • Webserver per SSL absichern
  • POP3/IMAP4-Zugriffe verschlüsseln
  • Dateisysteme verschlüsseln (EFS)
  • Anmeldung per Smartcard
  • Absicherung von Netzwerk per 802.1x

Während für die Bereitstellung einer Verschlüsselung (SSL) auf einem Webserver vielleicht noch ein einzelnes Zertifikat gekauft werden kann oder in Ausnahmefällen auch ein Selbstzertifikat ausreicht, greifen diese Ansätze zu kurz, um einen umfangreicheren Einsatz von Zertifikaten zu erlauben. Irgendwann kommen Sie zur Entscheidung, dass eine eigene Zertifizierungsstelle im Netzwerk Sinn macht. Ehe sie nun per Setup wie auf Win2003CA installieren oder Windows 2008 CA installieren beschrieben starten, sollten Sie einen kleinen Moment innehalten und ein paar Entscheidungen überdenken.

Einsatzbereiche für eine private CA

Zuerst müssen Sie natürlich Argumente finden, warum sie überhaupt eine CA installieren und über lange Zeit betreiben wollen. Zählen wir einmal die verschiedenen Bereiche auf, bei denen Zertifikate zum Einsatz kommen und inwieweit diese durch eine private CA abgedeckt werden können:

Bereich Beschreibung CA

Serverzertifikate
HTTPS, SMTPS, POP3S, IMAP4S, LDAPS, Proxy, Router, Switches

Immer mehr Dienste werden über "Internetprotokolle" gesteuert. Neben den bekannten Protokollen POP3 und IMAP4, bei denen die Kennworte bitte per SSL gesichert werden sollten, nutzen auch immer Geräte interne Webserver. Es ist natürlich einfach per HTTP einfach auf das Monitoring-Board im Server zu gehen oder andere Webdienste zu verwenden. Auch Exchange WebServices nutzen HTTP. Aber erst mit Zertifikaten werden die Daten verschlüsselt und eine Validierung der Gegenstelle möglich. Hier "sehen" sie am ehesten den Erfolg und den Bedarf an einer CA.

Da die meisten Dienste aber nicht aus dem Internet von fremden Clients verwendet werden, bietet sich hierfür eine interne private CA zu.

Private CA

S/MIME

Für die Verschlüsselung von Mails sind ebenfalls Zertifikate für die Anwender oder das Gateway erforderlich. Da hierbei externe Partner involviert sind, ist eine private CA hier kritisch zu bewerten. Wer also keine Subordinate-CA einer öffentlichen CA betreibt, sollte die ausgewählten Anwender eher mit einem offiziellen Personenzertifikat ausstatten oder eine Gateway-Lösung einsetzen.

individuelle Zertifikate oder Gateway.

802.1x., Radius-Server

"Offene" Netzwerkports sind für viele Firmen ein Problem. 802.1x ist ein gangbarer Weg, die Zugänge über eine Authentifizierung zu schützen. für die Radius-Server sind hierzu aber auch Zertifikate erforderlich. Wenn es sich um interne Clients handelt, ist hier eine eigene CA gut geeignet.

Private CA

Client-Zertifikate

Passend zur Authentifizierung gegen 802.1 oder auch für die Anmeldung an internen Webseiten eigenen sich Computer oder Benutzerzertifikate einer internen CA.

Private CA

Smartcard-Anmeldung

Einige Firmen nutzen sogar Chipkarten, um die Anmeldung am PC besser abzusichern (d.h. Besitz der Chipkarte + PIN + Benutzername) statt Benutzername Kennwort. Auch hierzu werden Zertifikate benötigt, die aber meist von einer internen CA ausgerollt werden

Private CA

IPSec
Windows Direct Access

Wer sich den Windows 2008 R2 Direct Access genauer angeschaut hat, weiß um die Bedeutung von IPV6 und IPSec als sichere Verbindung. Auch hier kommen Zertifikate zum Einsatz zu denen aber die CRL auch extern erreichbar sein muss. Aber auch dies kann durch eine interne CA erreicht werden

Private CA

Codesigning
VBA-Makro Signatur

VBScript, VBA und viele andere "ausführbare" Programme können gutartig oder Viren sein. Es ist sehr einfach in einem Netzwerk z.B. nur VBA-Makros, PowerShell-Skripte oder andere Programme nur dann zuzulassen, wenn diese digital signiert sind. Damit wird zuverlässig verhindert, dass veränderte oder fremde Programme aufgeführt werden. für den internen Gebrauch reicht dazu ebenfalls eine eigene CA. Wenn sie Programme nach "extern" vertreiben, sollten Sie aber über ein Zertifikat einer bekannten CA nachdenken. Es reicht hier ja eines für en Entwickler oder die Firma.

Private CA oder Einzelzertifikat

Abhängig von ihren Einsatzbereichen ist es daher nicht nur nützlich, sondern sogar ratsam, eine Zertifizierungsstelle zu betreiben.

Windows oder Unix

Von der technischen Funktion ist es in vielen Fällen sogar irrelevant, ob Sie nun die Windows CA oder eine andere CA (z.B. auf Basis von OpenSSL o.ä. einsetzen. Sie werden in den meisten Fällen sowieso die Zertifikate auf den entsprechenden Systemen erstellen und von der Zertifizierungsstelle nur signieren lassen. Und natürlich muss die Zertifizierungsstelle selbst auf allen Clients als "Vertrauenswürdige Stammzertifizierungsstelle" addiert werden. Das ist in einer Windows Active Directory Umgebung mit einer "Active Directory integrierten" Windows CA sowieso gegeben. Aber es ist über Gruppenrichtlinien auch kein Problem, andere Stammzertifikate automatisiert zumindest auf die Windows Clients zu verteilen. Andere Betriebssysteme und Clients (z.B. Mac, Unix, PDAs, Router, Switches, Apache etc.) sind getrennt zu betrachten. Zum Teil muss hier das Zertifikat noch umgewandelt werden (PEM nach PFX nach CER nach P7B etc.)

Enterprise oder Standard

Mit Windows 2012 ist die unterscheidung nicht mehr relevant:

Q5:What are some of the features now available in WindowsServer 2012 Standard that were previously only available in Windows Server 2008 R2 Enterprise and Datacenter editions?
A5: There are a variety of new features in Windows Server 2012 Standard edition. Here are just a few examples of what was previously only available in the premium editions:
- Windows Server Failover Clustering
- BranchCache Hosted Cache Server
- Active Directory Federated Services
- Additional Active Directory Certificate Services capabilities
- Distributed File Services (support für more than 1 DFS root)
- DFS-R Cross-File Replication

Quelle: Windows 2012 Licensing FAQ
http://download.microsoft.com/download/4/D/B/4DB352D1-C610-466A-9AAF-EEF4F4CFFF27/WS2012_Licensing-Pricing_FAQ.pdf

Windows 2012: What's New in AD CS?
http://technet.microsoft.com/library/hh831373.aspx

Dann gibt es auch unterschiede, die an der eingesetzten Windows Version festgemacht sind. Es gibt hier durchaus unterschiede, da die Windows 2003 Standard Server CA nicht alle Funktionen unterstützt. Besonders wenn Sie über 802.1x Authentifizierung und RADIUS/IAS nachdenken, ist eine Windows 2003 Standard CA nicht ausreichend.

Zertifikattemplates

Eine CA auf Windows 2003 Enterprise Server hat z.B. folgende Funktionserweiterungen:

  • Erstellen eigener Templates
    z.B. mit eigenen Gültigkeitszeiten
  • Autoenrollment von eigenen Templates und einigen besonderen Zertifikaten
  • AutoEnroll von Wifi Certificates
    Dies ist besonders ärgerlich, da Sie für den Einsatz von 802.1x eine Enterprise CA brauchen oder Zertifikate einer anderen CA kaufen müssen.
  • RAS/IAS Zertifikat
    Auch dieses Zertifikat, welches man auf dem IAS-Server installierten muss (802.1x), kann man nur mit der Windows 2003 CA
  • Private Key Recovery
    Die Enterprise CA kann eine Kopie der privaten Schlüssel vorhalten.

Beachten Sie dazu auch die Gegenüberstellung auf Private CA.

Root oder Subordinate

Eine CA ist daher schnell installiert und einfach, aber Sie sollten schon wissen was sie tun. Es gibt zwar viele Optionen aber im Grund gibt es nur drei häufig genutzte Konstruktionen:

CA-Typ Einsatzbereich

AD-Integrierte StammCA mit privatem Selbstzertifikat
PrivateCA

Kleine und mittlere unternehmen, die eine CA für die Absicherung interner Webserver und andere Kommunikationen suchen.

Kann man auch extern nutzen, wenn das Stammzertifikat auf die Clients verteilt wird, was bei PCs im gleichen Active Directory per Gruppenrichtlinien sehr einfach ist.

Das Problem ist hier, dass bei einer Kompromittierung der CA die ausgestellten Zertifikate nicht zurückgerufen werden können, da damit auch die Rückrufliste die falschen Zertifikate nicht enthält.

AD-integrierte SubCA mit
SubCA

Sicherer ist die Konfiguration, bei der die ausstellende CA nur eine untergeordnete Zertifizierungsstelle ist, die von einer StammCA zertifiziert ist. Die StammCA sollte dann natürlich nicht im Active Directory integriert sein.

Sie kann auf einem PC, Notebook oder virtuellen Maschine laufen, und dient nur dazu, dass man das Stammzertifikat extrahiert um es über Gruppenrichtlinien als Vertrauenswürdig zu verteilen, die untergeordnete CA zu installieren und die Rückrufliste bereit zu stellen. Da man aber eine solche RootCA nicht im Netzwerk erreichbar machen sollte, sollte man die URLs zu der CRL anpassen und die CRLs einfach auf einen anderen Webserver im Hausnetzwerk kopieren, so dass die Clients die CRL auflösen und erreichen können, ohne dass die eigentliche RootCA am Netzwerk sein muss.

Nebenbei könnte man so die SubCA später auch durch eine offizielle CA bestätigen lassen.

Wenn jemand eine CA unter Windows installiert, dann kann man diese auch ohne Integration in das Active Directory installieren. Ist ist nach meiner Erfahrung aber selten, da die vielen Vorteile der Integration dann nicht mehr gegeben sind.

Weitere Links