CA Checkliste

Lesen und verstehen Sie auch die SSL-Grundlagen und lesen Sie die Vorüberlegungen vor der Installation einer Privaten CA

Achtung:
Verstehen Sie unbedingt die Funktion und Bedeutung einer CA für den internen Einsatz, ehe Sie eine CA installieren.

Fremde RootCA

Vielleicht wollen Sie gar keine Windows CA installieren, sondern haben eine andere Plattform sich ausgesucht. Eine AD-Integrierte Windows CA hat den großen Vorteil, dass das Stammzertifikat dieser CA über das Active Directory automatisch zu allen Domain Clients eingebunden werden. Diese Funktion können Sie aber auch für andere Zertifikate nutzen.

certutil.exe -dspublish -f c:\Install\rootca01.cer RootCA

Über den gleichen Weg können auch SubCAs als auch CRLs hinterlegt werden:

certutil -dspublish -f "ROOTCA.crt" RootCA 
certutil -dspublish -f "POLICYCA.crt" SubCA 
certutil -dspublish -f "ROOTCA.crl"
certutil -dspublish -f "POLICYCA.crl"

Das ist auch sehr hilfreich, wenn Sie eine TestUmgebung aufgebaut haben und dort aber keine PKI nutzen, sondern die Zertifikate aus der Produktion übernehmen. So können Sie die FirmenCA dann auch mit anderen Produkten betreiben.

Zeitplan für ein CA Projekt

Sicher können sie ganz schnell "Setup" etc. ausführen aber eine CA ist schnell installiert aber schwer wieder verändert. daher sollte man ein bisschen planen. Hier ein Muster einer Vorgehensweise, die natürlich auf die individuelle Situation angepasst werden muss.

  • CA. Informationsworkshop für die beteiligen Personen
    Ziel ist hier die Vermittlung des Themas als solches, damit die späteren Fragen und Entscheidungen begründet sind. Dies kann auch mit einer Analyse einer vorhandenen CA eingehend und deren "Schwächen" zu erkennen
  • Interview zu den Anforderungen an eine neue CA-Struktur
    Hier sollte ermittelt werden, welche Zertifikate benötigt werden, welchem Einsatzweck die CA dienen soll und welche Abläufe wie geregelt werden sollen
  • Planung und Entwurf einer CA. Struktur mit Abstimmung der anderen Standorten
    Gerade wenn eine Firma größer ist, dann sollte man nicht in seiner kleinen Kammer etwas entwerfen. Es muss auch den anderen Administratoren vorgestellt werden. Sie glauben gar nicht wie viel Bedarf es nach Zertifikaten gibt, wenn die Plattform erst mal etabliert ist
  • Festlegen der Templates, CRLs, Server, administrativen Berechtigungen
    Jetzt kommt der Papierkram. Mit den gesammelten Daten gilt es die geplante Konfiguration zu beschreiben.
  • Definieren der Abläufe (Beantragen, Ausstellen, zurückrufen, überwachen)
    Dazu zählen auch die Regelungen, wer welche Zertifikate anfordern darf und wer diese dann ausstellt. Wie wird geklärt, dass die Anforderung zurecht erfolgt ist oder soll ein "Autoenrollment" zugelassen werden ?
  • Aufbau und Konfiguration der CA-Struktur
    Erst dann kann man daran gehen, die Server entsprechend der Vorgaben zu installieren. Manchmal muss man da "schnell" sein, da sich eine Windows CA per Default im AD einrichtet und wenn Sie die Verknüpfung zu den Templates nicht schnell entfernen oder Berechtigungen pflegen, haben die ersten DCs schon ein Zertifikat.
  • Einweisung der CA-Administratoren/Operatoren in die Verwendung, Feindokumentation der Arbeitsabläufe
    Nach der Installation können Sie am Objekt selbst die Administratoren dann in ihre Arbeit einweisen und das Arbeitshandbuch mit den "richtigen Bildern" erstellen.
  • Unterstützung beim Ausrollen der neuen Zertifikate auf die verschiedenen Clients
    Nun kann der Kunde alle geforderten Zertifikate ausstellen. Oft ist das aber auf dem Server nicht so einfach. Sonderfälle wie Router, Switches, NAS-Boxen o.ä. funktionieren anders als ein Windows IIS oder Exchange mit Assistent für Zertifikate. Da muss man eventuell einen Request erstellen, mit OpenSSL konvertieren o.ä.
  • Kür
    Und dann gibt es Dinge, die nach der Installation einer CA auf einmal ganz einfach werden können z.B. die Anmeldung am PC mittels Smartcard oder die Absicherung eines WiFi-Zugriffspunkts per 802.1x. Solche zusätzliche Tätigkeiten festigen zudem das Wissen und Verständnis um das Thema Zertifikate.

In enger Abstimmung mit einen Kunden gilt es hier natürlich ein individuelles Angebot zu erstellen.

Grundsätzliche Fragen

Gerade unter Windows ist die Installation einer Zertifizierungsstelle so einfach, dass es keinerlei zusätzlicher Kenntnisse erfordert und selbst die Assistenten fast immer eine funktionierende Konfiguration vorgeben. Zumindest solange keine besondere Anforderungen bestehen. Über Systemsteuerung - Software - Windows Komponenten wird einfach die Zertifizierungsstelle addiert und der Assistent fragt die erforderlichen Werte ab. Aber vorher sollten Sie ein paar grundlegende Eckpunkte beantworten.

Die hier gemachten Aussagen ersetzen keine individuelle Betrachtung bezüglich der Sicherheit und Risikoabschätzung und sind als Beispiele zu verstehen.

Wert Beschreibung mögliche/Ihre Einstellung

AD oder nicht AD
RootCA oder SubCA

Bei der Installation werden Sie sehr früh vor die Auswahl gestellt, ob die CA "Standalone" oder "AD-integriert" installiert wird. Nur wenn diese AD-Integriert arbeitet, wird das Stammzertifikat über das AD allen Clients direkt eingerichtet und die Windows Gruppen können zur Zugriffssteuerung genutzt werden.

Die zweite Entscheidung steuert, ob die CA selbst "Wurzel" ist oder nur als untergeordnete CA einer anderen CA agiert. Eine untergeordnete CA erlaubt es dem Admin der übergeordneten CA diese als "ungültig" zu kennzeichnen, wenn Sie korrumpiert wurde. Dies wäre auch die richtige Wahl, wenn Sie tatsächlich unter einer offiziellen Root-CA installieren würden. Dies ist wohl eher für große Firmen und öffentliche Einrichtungen (Universitäten) relevant, da zum Betrieb einer solchen CA einige Randbedingungen zu erfüllen sind.

AD-integrierte RootCA

Gültigkeitsdauer des Stammzertifikats
Default 5 Jahre

Eine Windows CA installiert nach Rückfrage ein Selbstzertifikat mit 5 Jahren Gültigkeit. Hört sich viel an aber alle davon abgeleiteten Zertifikate sind natürlich auch nicht länger gültig. Wenn Sie einmal die Stammzertifikate öffentlicher CAs anschauen, dann beträgt die Gültigkeit oft 10-20 Jahre. Eine längere Gültigkeit kann also ihnen viel Arbeit ersparen aber erhöht das Risiko, wenn die CA korrumpiert (Diebstahl etc.) wird.

20 Jahre

Windows Version
Standard
Enterprise

Auf den ersten Blick enthalten Standard, Enterprise und Datacenter eine CA. Aber leider ist die CA von Windows Standard an einigen Stellen beschränkt, so dass eine Enterprise-Version in vielen Fällen anzuraten ist.

  • RADIUS-Zertifikate für 802.1x
    Eine Standard-CA kann keine Radius-Zertifikate ausstellen. Das passende Template ist zwar installiert, aber erst ab Windows Enterprise nutzbar
  • eigene Templates mit längerer Gültigkeit
    Auch die bei Standard vordefinierten Vorlagen (z.B. Gültigkeit für Webserver = 2 Jahre) möchten viele Firmen intern verlängern. Wenn Sie Serverzertifikate für den internen Gebrauch z.B.: auf 5 oder 7 Jahre ausstellen, dann ersparen Sie sich das "Renew" nach 2 Jahren. Der Zeitpunkt wird eh verpasst und führt meist zu einer Betriebsunterbrechung
  • Key Recovery/private Key
    Sobald Sie S/MIME oder EFS einsetzen, ist die Funktion eines Key Recovery" sehr wichtig. Zertifikate und der dazu gehörende private Schlüssel liegen meist im lokalen Benutzerprofile und sind ohne Backup, Roaming Profiles o.ä. beim Verlust das PCs oder Hardwaredefekt verloren. Der Anwender aber auch die Firma kann dann aber auch nicht mehr auf alte Daten zugreifen. Gleiches gilt, wenn der Anwender ausscheidet und das Konto samt Profil gelöscht wird. Eine Enterprise-CA erlaubt hier die Ablage der privaten Schlüssel auf der CA

Dies sind aus meiner Sicht die wichtigsten Argumente für einen Windows Enterprise Server. Gut, wenn Sie die CA auf Hyper-V mit anderen Servern virtuell betreiben und die Enterprise Lizenz auch noch für bis zu drei andere Server auf der gleichen Hardware genutzt werden kann.

Enterprise

Dedicated Server oder mit auf DC

Sehr oft werden Domain Controller auch als "Infrastrukturserver" bezeichnet, die als DC natürlich LDAP und Globale Catalog spielen aber sehr oft auch noch DNS, WINS und DHCP-Server sind. Auch Zertifikatsdienste sind ein Teil der Infrastruktur und bei kleinen Firmen auf auch in der Hand des Domänen Administrators. Ein separates System für eine CA kann aber durchaus Vorteile haben, die den Kosten für die Lizenz und Hardware bzw. VM-Ressourcen gegenüber zu stellen sind:

  • Getrennte Administration
    Soll es irgendwann einmal gewünscht sein, dass Zertifikate durch andere Personen verwaltet werden, dann ist es einfacher diese auf einem eigenen Server zu delegieren.
  • Backup/Restore
    Auch vereinfachst sich das Backup und eine etwaige Wiederherstellung
  • Update/OS-Wechsel
    Steht irgendwann wieder ein upgrade der DCs auf die nächste Version an, dann müssen keine Abhängigkeiten der CA berücksichtig werden.
  • Kann "Offline" betrieben werden
    Wenn die CA keine Computer/Benutzerzertifikate ausstellt, sondern primär für WebZertifikate und andere per Browser angeforderte Zertifikate genutzt wird, dann kann die CA sogar nur zeitweise online sein oder per Firewall gegen Verbindungen von den meisten Clients geschützt werden.
    Achtung: Dies ist kaum möglich, wenn Clients automatisch ein Zertifikat erhalten sollen (z.B. PDAs, 802.1x, Smartcards)
  • eigene GPO
    Als eigener Server können Sie das Computerobjekt in eine eigene OU platzieren und mit eigenen Gruppenrichtlinien weiter absichern.

Eigener Server, VM oder DC

CRL-Pfad

Ehe Sie nun schon zum Setup greifen sollen gibt es noch einen ganz wichtigen Punkt zu berücksichtigen: Jedes von der CA ausgestellte Zertifikat enthält Informationen für den Client, wie er die Gültigkeit des Zertifikats prüfen kann. Der Client greift auf die "Liste der Sperrlistenverteilpunkte" zurück. Zu einer korrekten CA-Konfiguration gehört auch die korrekte Konfiguration dieser Einstellung, da ansonsten Probleme, wie auf Authenticode beschrieben, entstehen können.

Dabei sollte diese URL nicht nur von Intern sondern von überall erreichbar sein. Die CRL-Datei muss dazu nicht einmal auf der CA liegen, sondern kann z.B. auch auf einem anderen (z.B.: auch ihrem öffentlichen) Webserver bereit gestellt werden. Sie müssen beim Zurückrufen eines Zertifikats einfach daran denken, die CRL wieder zu verteilen.

Nutzen Sie als CRL also vielleicht nicht den internen Servernamen in der Form http://dc1.firma.intern, sondern einen Alias wie "crl.firma.de". Im Active Directory werden hier sicher auch noch LDAP-Pfade etc. enthalten sein, die sie aber entfernen können (und eventuell sollten), wenn das Zertifikat auch von extern erreichbar ist und Sie die interne Struktur nicht offenlegen wollen.

Ansonsten werden Sie bei der Installation von RPC/HTTP oder SSLVPN oder Direct Access Probleme bekommen, sie auch CRL.

A root CA certificate should have an empty CRL distribution point because the CRL distribution point is defined by the certificate issuer. Since the roots certificate issuer is the root CA, there is no value in including a CRL distribution point für the root CA. In addition, some applications may detect an invalid certificate chain if the root certificate has a CRL distribution point extension set.
Quelle: http://technet.microsoft.com/en-us/library/cc780454(WS.10).aspx

Die Angabe einer CRL trifft also nicht auf das Zertifikate der RooCA zu.

http://crl.firma.de

Key Recovery

Die Windows Enterprise CA erlaubt ihnen die Einrichtung eines "Key Recovery", d.h. über eine entsprechende Konfiguration der CA und der Templates kann die Ablage des privaten Schlüssels in der CA erzwungen werden. Dies ist außerordentlich wichtig, um z.B. SMIME-Zertifikate wieder zu erhalten, wenn der PC verloren wurde.
Manage Key Archival and Recovery
http://technet.microsoft.com/en-us/library/cc779638(WS.10).aspx

 

Templates

Per Default sind viele Windows Standard-Templates installiert und mit der CA verbunden. Ohne besondere Vorkehrungen sollten Sie nur die wirklich benötigten Templates aktiv lassen. Es ist mehr als unangenehm, wenn sich Anwender ohne ihr Wissen selbst ein "Benutzerzertifikat" oder "EFS-Zertifikat" anfordern und Mails per SMIME oder Dateien per EFS verschlüsseln und Sie kein Key Recovery konfiguriert haben. Verliert der user den auf der lokalen Disk gespeicherten privaten Schlüssel, kann niemand mehr die Mails oder Dateien lesen.

 

Berechtigungen

Wenn ein Template das Zertifikat nicht sofort ausstellt, müssen CA-Administratoren die Anforderungen bestätigen. Ein entsprechendes Rechtekonzept ist erforderlich.

 

Es ist also tatsächlich einiges zu tun, ehe Sie eine eigene CA mal eben schnell installieren.

Checkliste zur Installation einer Zertifikatsstelle

Die hier gemachte Checkliste und Dokumentation ist also nur exemplarisch zu sehen. Bis das System in den Regelbetrieb überführt werden kann, sind noch einige Konfiguration erforderlich, die sich an den Vorgaben und Entscheidungen von den Antworten auf Firmen CA orientieren.

Tätigkeiten Werte/erledigt

Installation Hardware

Servertyp, Hardware: Speicher, Festplatten, Netzwerk, Strom

Installation Basissystem

  • Windows Version und Edition
  • Features
  • AddOns

Windows 2008 Enterprise x64

IIS

Hardware Management Tools
oder VMWare Tools

Installation Zertifizierungsstelle

  • Typ: z.B. Unternehmens Stamm CA
  • Stammzertifikat Name und Gültigkeit
  • Datenbankpfade

Installation KB922706 wegen Vista/Win7 Clients

AD-integrierte Stammzertifizierungsstelle

Stammzertifikat
Name: cn= Firmen CA,
Gültigkeit: 30 Jahre

Datenbank
Pfad: c:\
Log:

Vorlagen / Templates

Mit einer Windows Enterprise Server CA können Sie die Zertifikatvorlagen anpassen. Es bietet sich z.B. an eine eigene Webservervorlage zu bauen, die eine längere Gültigkeit erlaubt. Zudem sollten Sie umgehend die Vorlagen entfernen, die sie nicht benötigen. Dies gilt z.B. für "Benutzer", solange Sie Key Recovery etabliert haben:

ACHTUNG: Wer z.B. Benutzer mit Autoenrollment verteilt, sollte auf dem Template verhindern, dass jemand mehrere Zertifikate anfordern kann, sondern erst wieder eine Anfrage/Verlängerung ausführen darf, wenn das alte Zertifikat fast abgelaufen ist.

  • Entferne "Benutzer"
  • Entferne "Computer"
  • Addiere "Computer 5 Jahre"

PrivateKey Store

Wenn Sie mit der CA später Zertifikate für EFS und SMIME ausstellen, dann ist der Verlust des privaten Schlüssels auf dem Client ein Problem. Der Benutzer kann z.B.: nicht mehr verschlüsselt empfangene Mails lesen. Der Benutzer muss also seinen Zertifikatsspeicher auf dem Desktop "sichern", z.B. per Roaming Profiles o.ä. Sie können natürlich das Template so anpassen, dass der Client den PrivateKey auf der CA hinterlegen muss, damit er das Zertifikat erhält. dann können Sie das Zertifikat immer wieder regenerieren.

 

Berechtigungen und Templates

Über die Berechtigungen und Verknüpfungen zu den Vorlagen kann bestimmt werden, welche Benutzer und Gruppen Zertifikate anfordern dürfen.

 

CRL konfigurieren und veröffentlichen

Die ausgestellten Zertifikate enthalten auch Adressen, über die ein Client die Rückrufliste erhalten kann. Da sie ihren internen Servernamen vielleicht nicht veröffentlichen möchten, könnten Sie hier einen Alias verwenden, z.B.

CRL = http://crl.firma.tld/certenroll/firma.crl

Beachten Sie, dass sie den verwendeten Namen auch im DNS als Alias auf einen Webserver oder Proxy eintragen müssen, damit die Clients von intern aber idealerweise auch von extern darauf zugreifen können.

 

SAN-Zertifikate

Wenn die Zertifizierungsstelle auch SAN-Zertifikate ausstellen soll, dann muss diese Option erst frei geschaltet werden.

certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
net stop certsvc
net start certsvc

 

Maximale Gültigkeit einstellen

Auch wenn ein Template z-B. 5 Jahre als Gültigkeit erlaubt, gibt es immer noch eine absolute Grenze in der CA, die ebenfalls angepasst werden sollte. Diesen Wert können Sie per Regedit oder per CertUtil umsetzen.

certutil -setreg ca\ValidityPeriodUnits 10
certutil -setreg ca\ValidityPeriod "Years"

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\NAME DER CA]
"ValidityPeriod"="Years"
"ValidityPeriodUnits"=dword:0000000A

 

CRL-Gültigkeit anpassen

Per Default erstellt eine Windows CA alle Woche eine neue CRL, was natürlich auch dazu führt, dass die alte CRL entsprechend früh "verfällt". für den internen Einsatz können Sie dieses Intervall erweitern.

certutil -setreg CA\CRLPeriodUnits 7
certutil -setreg CA\CRLPeriod "Days

Keine Änderung

IIS anpassen

Wenn auf dem CA-Server auch ein IIS installiert war, dann könnten Sie nun die Einstellungen etwas "schöner" machen, d.h. bei einem Zugriff auf die Basisseite wird auf das CERTSRV-Verzeichnis gewechselt oder eine Informationsseite zur Installation der Stammzertifikate auf anderen Systemen angezeigt. Natürlich sollte der Zugriff per SSL möglich sein und wer einen DNS-Alias für die CA angelegt hat (z.B. ca.firma.de) sollte natürlich auch das SSL-Zertifikat entsprechend ausstellen.

Für gewisse Funktionen ist der Zugang per SSL erforderlich. Ein entsprechendes Zertifikat ist daher anzufordern und einzubinden.

 

Updates

Damit Windows 7 und Windows 2008 mit einer Windows 2003 CA funktionieren können, sind entsprechende Updates erforderlich. Zum Zeitpunkt des Artikels war dies der Hotfix 922706.

Auch sonst ist es am Ende einer Installation immer wieder eine übliche Arbeit, nach aktuellen Updates zu suchen und diese gegebenenfalls zu installieren

 

Monitoring

Auch denn die CA problemlos installiert wurde, sollten Sie sich spätestens nach der Inbetriebnahme Gedanken über ein CA Monitoring machen.

 

CAPolicy.inf

In der Regel müssen Sie diese Datei NICHT anlegen. Dies ist relevant, wenn Sie eine Subordinate CA anlegen und hier schon z.B.: die CRL abweichend eintragen wollen.

Nicht alle Einstellungen sind über den Assistenten möglich. (Versionsabhängig). Das Setup liest beim Start daher die Datei "capolicy.inf" ein, welche Sie VOR der Installation erstellen können und in %Systemroot% ablegen. Hier ein Beispiel, um ein Stammzertifikat für 30 Jahre mit einer angepassten CRL-URL zu erstellen. Wenn Sie eine Windows CA nicht mit den Standardwerten installieren wollen, können Sie eine Datei CAPOLICY.INF-anlegen., die einige Parameter des Stammzertifikats vorgibt. welches bei der Einrichtung der CA schon automatisch mit erstellt wird.

%Systemroot%/CAPOLICY.INF

[Version]
Signature="$Windows NT$"
 
[Certsrv_Server]
RenewalKeyLength=2048
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=6
CRLPeriod=days
CRLPeriodUnits=7
CRLOverlapPeriod=hours
CRLOVerlapUnits=12
CRLDeltaPeriodUnits=0
CRLDeltaPeriod=hours
DescreteSignatureAlgorithm=1
LoadDefaultTemplates=0
 
[CRLDistibutionPoint] URL="http://crl.firma.tld/certenroll/caname.crl" URL="http://crl.firma.local/certenroll/caname.crl"
 
[AuthorityInformationAccess]
Empty=True

Die Verwendung zweier CRLs ist denkbar, wenn Sie keinen "Split-DNS" betreiben. Bis vor einiger Zeit hatte ich hier noch geschrieben, dass sie hier eine CRL konfigurieren sollten, damit externe Nutzer Auch die Gültigkeit der RootCA prüfen können. Dies ist aber nicht mehr "Best practice". Siehe dazu auch die folgenden Links.

Die entsprechende Eintragung in der CAPOLICY.INF ist hier also nur noch als Archiv zu betrachten.

[CRLDistributionPoint] URL="http://crl.netatwork.de/CertEnroll/nawca2010.crl"

Achtung: Wenn Sie keinen IIS als Webserver für die CRL nutzen, sondern z.B. einen Apache, dann beachten Sie, dass auf Unix zwischen Groß und Kleinschreibung unterschieden wird. Die Windows CA nutzt den späteren DN auch als Dateinamen. Dieser kann also "groß" geschrieben sein.

Bis vor einiger Zeit hatte ich hier noch geschrieben, dass sie hier eine CRL konfigurieren sollten, damit externe Nutzer Auch die Gültigkeit der RootCA prüfen können. Dies ist aber nicht mehr "Best practice".

A root CA certificate should have an empty CRL distribution point because the CRL distribution point is defined by the certificate issuer. Since the roots certificate issuer is the root CA, there is no value in including a CRL distribution point für the root CA. In addition, some applications may detect an invalid certificate chain if the root certificate has a CRL distribution point extension set.
Quelle: http://technet.microsoft.com/en-us/library/cc780454(WS.10).aspx

CAPolicy.inf is processed für root CA and subordinate CA installations and renewals.
The CDP and AIA extensions in CAPolicy.inf are used für root CA installations and renewals only
Apply CA Policy http://technet.microsoft.com/en-us/library/cc780468(WS.10).aspx

CA verschieben

Es ist in Grenzen möglich, eine Zertifizierungsstelle auf einen anderen Server zu übertragen. Die folgenden Links helfen weiter:

Weitere Links