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"
Die Einträge könnten auch per MMC mit "pkiview.msc" unter "Enterprise PKI" - "Manage AD Containers" eingesehen werden.
Die Einträge landen dann im AD unter:
"CN=Certification Authorities,CN=Public Key Services,CN=Services,CN=Configuration,[DomainDN]"
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.
- Manually publishing a CA
certificate or CRL into a LDAP
store
http://blogs.technet.com/b/pki/archive/2007/04/13/manually-publishing-a-ca-certificate-or-crl-into-a-ldap-store.aspx - Publish Offline Certificates
and CRLs to Active Directory
http://networkerslog.blogspot.de/2010/12/publish-offline-certificates-and-crls.html - How to Publish Root/Policy
CAs in Active Directory
http://beccabits.com/2011/06/06/how-to-publish-rootpolicy-cas-in-active-directory/
Wenn Sie eine CA wieder deinstallieren, dann lesen Sie dazu auch Deinstallation einer CA,
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 |
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 |
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 |
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.
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:
|
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. 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. |
|
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.
- Certification Authority Guidance
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831574(v=ws.11)
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 HardwareServertyp, Hardware: Speicher, Festplatten, Netzwerk, Strom |
|
Installation Basissystem
|
Windows 2008 Enterprise x64 IIS Hardware Management Tools |
Installation Zertifizierungsstelle
Installation KB922706 wegen Vista/Win7 Clients |
AD-integrierte Stammzertifizierungsstelle Stammzertifikat Datenbank |
Vorlagen / TemplatesMit 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. |
|
PrivateKey StoreWenn 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öffentlichenDie 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-ZertifikateWenn 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 einstellenAuch 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 anpassenPer 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 anpassenWenn 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. |
|
UpdatesDamit 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. |
|
MonitoringAuch denn die CA problemlos installiert wurde, sollten Sie sich spätestens nach der Inbetriebnahme Gedanken über eine überwachtung zu machen
|
|
CAPolicy.inf
Ohne diese Datei installiert Windows die CA nach Standards, die ihnen vielleicht nicht gefallen. Nutzen Sie daher die Zeit um wenigstens ein paar Einstellungen zu prüfen und ggfls. anzupassen. Dies ist relevant, wenn Sie eine Subordinate CA anlegen und hier schon z.B.: die CRL abweichend eintragen wollen.
Wenn Sie eine mehrstufige PKI aufbauen und eine kleine RootCA brauchen, die nutz die SubCAs signiert, dann können Sie dies auch per OpenSSL machen.
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. Sie liegt in
%windir%/CAPOLICY.INF
Hier ein Muster-Inhalt
[Version] Signature="$Windows NT$" [Certsrv_Server] RenewalKeyLength=2048 RenewalValidityPeriod=Years RenewalValidityPeriodUnits=30 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" [AuthorityInformationAccess] Empty=True
Die Verwendung zweier URLs als CRL ist denkbar, wenn Sie keinen "Split-DNS" betreiben. Stellen Sie einfach sicher, das jeder die von der RootCA ausgestellten Zertifikate prüfen kann.
- CRL
-
CAPolicy.inf Syntax
https://docs.microsoft.com/de-de/windows-server/networking/core-network-guide/cncg/server-certs/prepare-the-capolicy-inf-file - Creating Certificate Policies and Certificate
Practice Statements
http://technet.microsoft.com/en-us/library/cc780454(WS.10).aspx - OpenSSL Certificate Authority
https://jamielinux.com/docs/openssl-certificate-authority/introduction.html - Authority Information Access (AIA) Extension
http://www.pkiglobe.org/auth_info_access.html
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:
- 298138 How to move a certification authority to another server
- 555012 HOWTO: Move a certificate authority to a new
server running on a domain controller.
Aus meiner Sicht ist der Artikel unvollständig - Move a CA to a Different Computer
http://technet.microsoft.com/en-us/library/cc755153(WS.10).aspx - http://www.scottfeltmann.com/index.php/2010/03/02/move-root-ca-from-w2k3-to-w2k8/
- http://smtpport25.wordpress.com/2010/01/16/migrating-windows-certificate-authority-server-from-windows-2003-standard-to-windows-2008-enterprise-server/
Weitere Links
- Private CA
- SSL-Grundlagen
- SAN-Zertifikate
- IIS Zertifikat einrichten
- Clientzertifikat anfordern
- ISA-Server und SSL
- CRL - Zertifikate zurückziehen
- SelfSSL
- OpenSSL
-
Checklisten
Eine Übersicht aller Checklisten der MSXFAQ - Certification Authority Guidance
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831574(v=ws.11) - Anhänge - Sichern von Wireless LANs mit Zertifikatsdiensten
http://www.microsoft.com/germany/technet/datenbank/articles/900177.mspx - CAPolicy.inf Syntax
http://technet2.microsoft.com/WindowsServer/en/library/25127c1f-4880-4764-85e8-226ce41588881033.mspx?mfr=true - Building an Enterprise Root Certification Authority in Small and
Medium Businesses
http://www.microsoft.com/technet/security/smallbusiness/prodtech/windowsserver2003/build_ent_root_ca.mspx - How to re-install the default certificate templates?
http://blogs.technet.com/pki/archive/2007/08/06/how-to-re-install-the-default-certificate-templates.aspx - Sample Script to Configure CorporateRootCA
http://technet.microsoft.com/de-de/library/cc779083(WS.10).aspx - 555151 How to remove manually Enterprise Windows Certificate Authority from Windows 2000/2003 Domain
- 254632 How to change the expiration date of certificates that are issued by a Windows Server 2003 or a Windows 2000 Server Certificate Authority
- 293819 How to Remove a Root Certificate from the Trusted Root Store
- 298138 How to move a certification authority to another server
- Move Root Certificate Authority from Windows Server 2003 to Windows
Server 2008
http://www.scottfeltmann.com/index.php/2010/03/02/move-root-ca-from-w2k3-to-w2k8/ - Active Directory Certificate Services Step-by-Step Guide
http://technet.microsoft.com/en-us/library/cc772393.aspx - Simple Certificate Enrollment Protocol (SCEP) Add-on für Certificate
Services
http://www.microsoft.com/Downloads/details.aspx?familyid=9F306763-D036-41D8-8860-1636411B2D01&displaylang=en - Certificate Concepts
http://blogs.technet.com/askds/archive/2008/04/04/certificate-concepts.aspx - http://www.psw.net/ssl.cfm
- www.godaddy.com
- www.thawte.com
- How to install a PKI based on Microsoft Certificate Services in Windows
Server 2003
http://www.windowsecurity.com/articles/Microsoft-PKI-Quick-Guide-Part3.html