Root CA - Verständnisfrage

[Beetlejuice 11]

Hallo zusammen,

 

ich habe da ein Problem mit einem ausgestellten Zertifikat für meinen neuen Exchange 2010 Server. Um den Fehler zu verstehen muss ich eben mein Verständis für die CA abklopfen.

 

Ich habe einen Server Win2k8R2 Standard der als Eigenständiger Zertifikatsserver fungiert. (ROOT-CA-01)

Ich habe einen 2. Server Win2k8R2 Standard der als Unternehmes Zertifkatsserver im AD mitspielt. (SUB-CA-02)

 

Die ROOT-CA-01 stellt ihre Sperrliste aus und wird auf der SUB-CA-02 eingespielt. Der Server wird dann ausgeschaltet. Die SUB-CA-02 wiederrum stellt eigene Sperrlisten aus (Sperrliste und Delta-Sperrliste).

Dann sollten die ausgestellten Zertifikate doch nur die Sperrlisten der SUB-CA-02 abfragen und nur die SUB-CA-02 bei bedarf eine neue Version der Sperrliste von der ROOT-CA-01 verlangen. (Wenn die alte abgelaufen ist)

 

Bin ich hier soweit richtig oder liege ich da falsch?

 

Mein Problem ist nun, dass der Exchange das Zertifikat nicht überprüfen kann, weil die Sperrlisten nicht überprüft werden können. Habe das ausgestellte Zertifkat auch mit dem "certutil -verify" geprüft und bekomme bei der Prüfung der Sperrfunktion die Meldung "Die Speerfunktion konnte die Sperrung nicht überprüfen, da der Sperrserver offline war. 0x80092013".

 

Die Sperrlisten der SUB-CA-02 sind über LDAP, HTTP und FILE ereichbar und verfügbar.

 

Bin ich da auf dem falschen Ast oder stimmt da was nicht?

 

cu

[Dunkelmann 96]

Du musst die Sperrliste der Root CA veröffentlichen (AD und/oder Webserver) und nicht auf der Sub CA im lokalen Speicher installieren.

 

Immer wieder gerne genommen:

Brian Komar - PKI and Certificate Security

[blub 115]

Dann sollten die ausgestellten Zertifikate doch nur die Sperrlisten der SUB-CA-02 abfragen und nur die SUB-CA-02 bei bedarf eine neue Version der Sperrliste von der ROOT-CA-01 verlangen. (Wenn die alte abgelaufen ist)

 

Bin ich hier soweit richtig oder liege ich da falsch?

 

 

Hi,

da liegst du falsch. Wenn ein Rechner ein Zertifikat prüft, dann prüft er die gesamte Zertifikatskette. Dazu hat dieser Rechner unter vertrauenswürdige Stammzertifizierungsstellen Zertifikate der ROOT-CA-01 und SUB-CA-02 importiert. Neben der Gültigkeit, Einsatzbereich etc. prüft er bei jedem dieser StammZertifikate auch ob es in der jeweiligen CRL steht. Jede CA hat ihre eigene CRL, von der eine Kopie von einem Distributionpoint auf deinen Exchangeserver kopiert werden muss.

 

Zum Verständnis: Geh mal in den ..\Cryptenturlcache\content - Ordner und benenne die dortigen Dateien nach *.crl um. Dann kannst du dir die crl(s) ansehen.

 

Per User

C:\Users\username\AppData\LocalLow\ Microsoft\CryptnetUrlCache

 

Per Computer

C:\Windows\System32\config\ systemprofile\AppData\LocalLow\ Microsoft\CryptnetUrlCache

 

blub

bearbeitet 6. Juni 2012 von blub

[Beetlejuice 11]

Du musst die Sperrliste der Root CA veröffentlichen (AD und/oder Webserver) und nicht auf der Sub CA im lokalen Speicher installieren.

 

Die Eigenständige CA hat keine direkte Verbindung zum LDAP. Also kann die CRL nur über Webserver veröffentlicht werden.

 

Vermutlich muss ich auch alle bisherigen Zertifikate der SUB-CA neu Ausstellen.

 

Muss ich das Zertifikat auch für die Sub-CA-02 neu ausstellen, diese hat ja den CRL von der Root-CA? Es dürfte auch so gehen, da die Sperrlisten im lokalen Speicher der Sub-CA liegen.

[Dunkelmann 96]

Mit "certutil -dspublish ..." kannst du Zertifikate und Sperrlisten von offline CAs im Active Directory veröffentlichen.

 

Muss ich das Zertifikat auch für die Sub-CA-02 neu ausstellen, diese hat ja den CRL von der Root-CA? Es dürfte auch so gehen, da die Sperrlisten im lokalen Speicher der Sub-CA liegen.

Es geht bei einer PKI nicht darum, dass der Zertifikatsinhaber seinem eigenen Zertifikat vertraut, sondern dass alle anderen Teilnehmer dem Zertifikat vertrauen.

Das geht nur wenn alle Teilnehmer in der Lage sind die Zertifikatskette zurück zu verfolgen und die Sperrlisten zu überprüfen.

 

Ich empfehle dringend, dich zunächst mit den Grundlagen einer mehrstufigen PKI vertrautzumachen.

[Beetlejuice 11]

Danke für die Unterstützung. Werd nun noch meine defizite in der PKI ausbessern.

 

Glücklicherweise stellt die PKI erstmal nur interne Webserver Zertifikate und DC Zertifikate aus. Da macht das auswechseln der Zertifikate nur etwas Arbeit.

 

cu

[Beetlejuice 11]

Eine Frage habe ich noch, die sich mir gerade stellt und ich keine direkte Antwort drauf habe.

 

Wie kann ich auf der Offline Root-CA (die nicht in der Domain ist) die CDP und AIA location korrekt fürs LDAP konfigurieren?

 

Die CDP und AIA für die Root-CA zu veröffentlichen macht doch nur sin, wenn in der CA das LDAP als location angegeben wird!? Zusätzlich werden die CDP und AIA Informationen auf dem Webserver der Sub-CA bereitgestellt.

 

Jedenfalls wird beim Ausstellen eines neuen Zertifikates, das LDAP als Ort für AIA und CPD angegeben, aber mit fehlerhaften Domain (URL=ldap:///CN=Meine%20Firma,CN=Server01,CN=CDP,CN=Public%20Key%20Services,CN=Services,DC=UnavailableConfigDN?certificateRevocationList?base?objectClass=cRLDistributionPoint). Wie auch, woher soll er auch wissen welche ich verwende.

 

Um auf die Frage oben zurück zu kommen, wie kann ich das nun am besten konfigurieren? Trage ich den letzten LDAP-Pfad manuell ein, oder ist es generell nicht notwendig für eine Root-CA, da CDP und AIA via HTTP ebenfalls bereitgestellt werden?

[Dunkelmann 96]

Ob du das Zertifikat im AD veröffentlichst oder per GPO verteilst ist Geschmackssache. Wichtig ist nur, dass alle Teilnehmer das Zertifikat als "Vertrauenswürdige Stammzertifizierungsstelle" bekommen und das die Sperrlisten überprüft werden können.

 

Ich habe mal kurz meinen Spieker für eine Laborumgebung ausgegraben. Dabei verzichte ich auf eine Veröffentlichung im LDAP und nutze nur interne und externe CDP/AIA per Webserver.

Die Scripte und HowTos kommen übrigens aus dem oben genannten Buch. ;)

 

Vor der Installation der Root CA eine Datei "capolicy.inf" ins Windows Verzeichnis packen:

[Version]
Signature= "$Windows NT$"

[certsrv_server]
renewalkeylength=2048
RenewalValidityPeriodUnits=20
RenewalValidityPeriod=years

CRLPeriod=weeks
CRLPeriodUnits=26
CRLOverlapPeriod=weeks
CRLOverlapUnits=2
CRLDeltaPeriod=days
CRLDeltaPeriodUnits=0

DiscreteSignatureAlgorithm=1

 

Nach der Installation der Root CA folgendes Skript auf der Root CA laufen lassen.

Ob die externen CDP und AIA "xxxx.xxxxx.biz" benötigt werden, sollte vorher unbedingt evaluiert werden. Eine PKI entwirft man für eine Zeit von 5, 10 oder mehr Jahren und da sollte man sich genau überlegen was künftig benötigt werden könnte.

 

::
:: Direkt nach der Installation der Root CA auf der Root CA ausführen!
::

:: Define CRL Publication Intervals
certutil -setreg CA\CRLPeriodUnits 26
certutil -setreg CA\CRLPeriod "Weeks"
certutil -setreg CA\CRLDeltaPeriodUnits 0
certutil -setreg CA\CRLDeltaPeriod "Days"
certutil -setreg CA\CRLOverlapPeriod "Weeks"
certutil -setreg CA\CRLOverlapUnits 2

:: Apply the required CDP Extension URLs
certutil -setreg CA\CRLPublicationURLs "1:%windir%\system32\CertSrv\CertEnroll\%%3.crl\n2:http://xxxx.xxxxx.biz/CDP/%%3.crl\n2:http://lab-root-ca.labor.test/CDP/%%3.crl"

:: Apply the required AIA Extension URLs
certutil -setreg CA\CACertPublicationURLs  "1:%windir%\system32\CertSrv\CertEnroll\%%3.crt\n2:http://xxxx.xxxxx.biz/AIA/%%3.crt\n2:http://lab-root-ca.labor.test/AIA/%%3.crt"

:: Enable all auditing events for the Root CA
certutil -setreg CA\AuditFilter 127

:: Set Validity Period for Issued Certificates
certutil -setreg CA\ValidityPeriodUnits 10
certutil -setreg CA\ValidityPeriod "Years"

:: Enable discrete signatures in subordinate CA certificates
Certutil -setreg CA\csp\DiscreteSignatureAlgorithm 1

:: Restart Certificate Services
net stop certsvc & net start certsvc

:: Publish CRL
certutil –crl

pause

 

Nach dem Skript können Zertifikat und Sperrliste in die Produktivumgebung transferiert werden.

Ich verteile das Stammzertifikat im Anschluss per GPO in meiner jeweiligen Testdomäne.