SRV2008: Konfiguration Active Directory Zertifikatdienste

Alle Antworten

• 

  

  0

  Anmelden

  Hi DPM,
  
  ist denn die neue CRL / Delta CRL überhaupt schon auf dem Client angekommen? Falls nicht, müßtest Du in jedem Fall erst darauf warten bzw. die Zeiträume der Sperrlistenveröffentlichung verkürzen.
  Unter Vista kannst Du mit "certutil -URLCache CRL" den lokalen Cache löschen, unter XP funktioniert das nicht so einfach.
  
  Zum Online Responder: Was genau heißt "es funktioniert nicht"?
  
  Viele Grüße
  Fabian

  ---

  http://blogs.technet.com/deds

  Mittwoch, 5. August 2009 10:27

  Antworten

  |

  Zitieren
• 

  

  0

  Anmelden

  Hi Fabian,
  
  danke für die fixe Rückantwort!
  
  Wenn ich auf Server2 den Befehl "certutil -URLCache CRL" ausführe, erhalte ich folgendes Ergebnis:
  
  ldap:///CN=Contoso-Stammzertifizierungsstelle,CN=Server3,CN=CDP,CN=Public%20Key%
  20Services,CN=Services,CN=Configuration,DC=contoso,DC=com?certificateRevocationL
  ist?base?objectClass=cRLDistributionPoint
  
  Das bedeutet wohl, das die Konfiguration der Sperranbieter falsch ist, da Server2 die Sperrliste von der RootCA auf Server3 und nicht von der ZS auf Server4 bezieht? Hmm...  Soll ich sämtliche URL Erweiterungen (CRL-Verteilungspunkt + Stelleninformationen) und deren Optionen auf der RootCA auf Server3 somit deaktivieren? Was ist wenn mehrere ausstellende ZS habe? Dachte das würde zentral im AD abgelegt?!?
  
  Zum Online-Responder komme ich später, da mir momenten die Muße zur Formulierung der Problematik fehlt. ;-)
  
  Danke ersma!
  
  Dominik

  Mittwoch, 5. August 2009 10:53

  Antworten

  |

  Zitieren
• 

  

  0

  Anmelden

  Hi Dominik,
  
  leider komme ich jetzt gerade, was Deine Gesamtumgebung betrifft, nicht ganz mit. ;)
  
  Vom Prinzip her muß in einem ausgestellten Zertifikat die CRL / CDP der ausstellenden CA zu finden sein.
  Stellt also CA3 ein Zertifikat aus, muß in dem Zertifikat die SPerrliste von CA 3 aufgeführt sein. Wenn das nicht der Fall ist, müßtest Du den Pfad zu den Sperrlisten zentral auf der CA anpassen und dann die Zertifikate neu ausstellen.
  
  Viele Grüße
  Fabian

  ---

  http://blogs.technet.com/deds

  • Als Antwort vorgeschlagen Fabian Müller [MSFT]Microsoft employee Freitag, 4. September 2009 21:17

  Mittwoch, 5. August 2009 15:50

  Antworten

  |

  Zitieren
• 

  

  0

  Anmelden

  Hallo Dominik,
  
  welcher LDAP-Pfad steht den nun genau im Computerzertifikat vom Server 2 ?
  
  ergänzend zu Fabian:
  >Vom Prinzip her muß in einem ausgestellten Zertifikat die CRL / CDP der ausstellenden CA zu finden sein.
  außer es handelt sich um ein RootCa-Zertifikat selbst.
  
  
  

  ---

  Gruß Ralph Andreas Altermann

  Mittwoch, 5. August 2009 19:55

  Antworten

  |

  Zitieren
• 

  

  0

  Anmelden

  N'Abend,
  
  meine Aussage war auf die konkrete Frage von Dominik gemünzt - daher der Verweis auf die CRL / CDP der CA 3. Grundsätzlich aber hast Du natürlich Recht - eine self signed Root CA hat im Normalfall keine CDP in den eigens ausgestellten Zertifikaten.
  
  P.S.: Der korrekte Befehl lautet: certutil -URLCache CRL -delete ".
  
  Viele Grüße
  Fabian

  ---

  http://blogs.technet.com/deds

  Mittwoch, 5. August 2009 20:15

  Antworten

  |

  Zitieren
• 

  

  0

  Anmelden

  Da bin ich wieder! ;-)
  
  Nachdem ich mich in dem Thema PKI ziemlich verloren gefühlt habe, besorgte ich mir das Buch Server 2008 PKI und Zertifikat-Sicherheit von Brian Komar, das wirklich toll ist.
  
  Der initiale Thread bezog sich auf meine ersten Installationsversuche, während derer ich noch keine Ahnung von einer CAPolicy.inf und weiteren Finessen hatte.
  
  Nun begann ich die PKI nach den Beschreibungen des Buches neu aufzusetzen. Leider aber wieder mit dem gleichen mir unerklärlichen Ergebnis.
  
  Meine virtuelle Umgebung umfasst nun eine Root CA (Offline), Policy CA (Offline) und eine Issuing CA (Online, ausstellende) + einem Online Responder. Die PKI-View meiner Umgebung ist wunderbar OK. Alle CDP und AIA-Erweiterungen sind korrekt:
  
  CAPolicy.inf der Root CA:
  [Version]
  Signature="$Windows NT$"

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

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

  DiscreteSignatureAlgorithm=1
  
  Nachinstallations-Batch der Root-CA:
  ::Deklariere den Namenskontext Configuration
  certutil -setreg CA\DSConfigDN CN=Configuration,DC=contoso,DC=com

  ::Definiere die Sperrlistenveröffentlichungsintervalle
  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

  ::Richte die erforderlichen CDP-Erweiterungs-URLs ein
  certutil -setreg CA\CRLPublicationURLs "1:%WinDir%\System32\CertSrv\CertEnroll\%%3%%8%%9.crl\n10:ldap:///CN=%%7%%8,CN=%%2,CN=CDP,CN=Public Key Services,CN=Services,%%6%%10\n2:http://www.contoso.com/Certdata/%%3%%8%%9.crl"

  ::Richte die erforderlichen AIA-Erweiterungs-URLs ein
  certutil -setreg CA\CACertPublicationURLs "1:%WinDir%\System32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n2:ldap:///CN=%%7,CN=AIA,CN=Public Key Services,CN=Services,%%6%%11\n2:http://www.contoso.com/Certdata/%%1_%%3%%4.crt"

  ::Aktiviere alle Überwachungsereignisse der Stammzertifizierungsstelle von Contoso Corporate
  certutil -setreg CA\AuditFilter 127

  ::Lege die Gültigkeitsdauer für auszustellende Zertifikate fest
  certutil -setreg CA\ValidityPeriodUnits 10
  certutil -setreg CA\ValidityPeriod "Years"

  ::Aktiviere in untergeordneten Zertifizierungsstellenzertifikaten diskrete Signaturen
  certutil -setreg CA\csp\DiscreteSignatureAlgorithm 1
  
  CAPolicy.inf der Policy-CA:
  [Version]
  Signature="$Windows NT$"

  [PolicyStatementExtension]
  Policies=ContosoCPS

  [ContosoCPS]
  OID=1.3.6.1.4.1.311.509.3.1
  NOTICE=Contoso Industries-Zertifikatverwendungserklärung
  URL=http://www.contoso.com/CPS/CPStatement.asp

  [certsrv_server]
  Renewalkeylength=2048
  RenewalValidityPeriodUnits=10
  RenewalValidityPeriod=years

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

  DiscreteSignatureAlgorithm=1
  
  Nachinstallations-Batch der Policy-CA:
  ::Deklariere den Namenskontext Configuration
  certutil -setreg CA\DSConfigDN CN=Configuration,DC=contoso,DC=com

  ::Definiere die Sperrlistenveröffentlichungsintervalle
  certutil -setreg CA\CRLPeriodUnits 26
  certutil -setreg CA\CRLPeriod "Weeks"
  certutil -setreg CA\CRLOverlapUnits 2
  certutil -setreg CA\CRLOverlapPeriod "Weeks"
  certutil -setreg CA\CRLDeltaPeriodUnits 0
  certutil -setreg CA\CRLDeltaPeriod "Days"

  ::Richte die erforderlichen CDP-Erweiterungs-URLs ein
  certutil -setreg CA\CRLPublicationURLs "1:%WinDir%\System32\CertSrv\CertEnroll\%%3%%8%%9.crl\n10:ldap:///CN=%%7%%8,CN=%%2,CN=CDP,CN=Public Key Services,CN=Services,%%6%%10\n2:http://www.contoso.com/Certdata/%%3%%8%%9.crl"

  ::Richte die erforderlichen AIA-Erweiterungs-URLs ein
  certutil -setreg CA\CACertPublicationURLs "1:%WinDir%\System32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n2:ldap:///CN=%%7,CN=AIA,CN=Public Key Services,CN=Services,%%6%%11\n2:http://www.contoso.com/Certdata/%%1_%%3%%4.crt"

  ::Aktiviere alle Überwachungsereignisse für die Contoso Policy CA
  certutil -setreg CA\AuditFilter 127

  ::Lege die Gültigkeitsdauer für auszustellende Zertifikate fest
  certutil -setreg CA\ValidityPeriodUnits 5
  certutil -setreg CA\Validityperiod "Years"

  ::Aktiviere in untergeordneten Zertifizierungsstellenzertifikaten diskrete Signaturen
  certutil -setreg CA\csp\DiscreteSignatureAlgorithm 1
  
  Per Batch wurden die Zertifikate der Root und Policy-CA auf der Issuing CA im AD veröffentlicht:
  for %%c in ("ContCA01*.crt") do certutil -dspublish -f "%%c" RootCA
  for %%c in ("ContCA02*.crt") do certutil -dspublish -f "%%c" SubCA
  for %%c in ("Contoso Root*.crl") do certutil -dspublish -f "%%c"
  for %%c in ("Contoso Policy*.crl") do certutil -dspublish -f "%%c"
  gpupdate /force
  
  CAPolicy.inf der Issuing CA:
  [Version]
  Signature="$Windows NT$"

  [certsrv_server]
  RenewalKeyLength=2048
  RenewalValidityPeriodUnits=5
  RenewalValidityPeriod=years

  CRLPeriod=3
  CRLPeriodUnits=days
  CRLOverlapPeriod=4
  CRLOverlapUnits=hours
  CRLDeltaPeriod=12
  CRLDeltaPeriodUnits=hours

  DiscreteSignatureAlgorithm=1
  LoadDefaultTemplates=0
  
  Nachinstallations-Batch der Issuing-CA:
  ::Deklariere den Namenskontext Configuration.
  certutil -setreg CA\DSConfigDN CN=Configuration,DC=contoso,dc=com

  ::Definiere die Sperrlistenveröffentlichungsintervalle
  certutil -setreg CA\CRLPeriodUnits 3
  certutil -setreg CA\CRLPeriod "Days"
  certutil -setreg CA\CRLOverlapUnits 4
  certutil -setreg CA\CRLOverlapPeriodUnits "Hours"
  certutil -setreg CA\CRLDeltaPeriodUnits 12
  certutil -setreg CA\CRLDeltaPeriod "Hours"

  ::Richte die erforderlichen CDP-Erweiterungs-URLs ein
  certutil -setreg CA\CRLPublicationURLs "65:%WinDir%\System32\CertSrv\CertEnroll\%%3%%8%%9.crl\n79:ldap:///cn=%%7%%8,CN=%%2,cn=CDP,CN=Public Key Services,cn=Services,%%6%%10\n6:http://www.contoso.com/CertData/%%3%%8%%9.crl\n6:http://%%1/CertEnroll/%%3%%8%%9.crl"

  ::Richte die erforderlichen AIA-Erweiterungs-URLs ein
  certutil -setreg CA\CACertPublicationURLs "1:%WinDir%\System32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n3:ldap:///cn=%%7,cn=AIA,cn=Public Key Services,cn=Services,%%6%%11\n2:http://www.contoso.com/CertData/%%1_%%3%%4.crt\n2:http://%%1/CertEnroll/%%1_%%3%%4.crt"

  ::Aktiviere alle Überwachungsereignisse für die ausstellende Zertifizierungsstelle von Contoso
  certutil -setreg CA\AuditFilter 127

  ::Aktiviere in den ausgestellten Zertifikaten diskrete Signaturen
  certutil -setreg CA\csp\DiscreteSignatureAlgorithm 1

  ::Lege die maximale Gültigkeitsdauer für ausgestellte Zertifikate fest
  certutil -setreg CA\ValidityPeriodUnits 2
  certutil -setreg CA\ValidityPeriod "Years"
  
  Hinter der URL http://www.contoso.com/CertData/ läuft ein seperater IIS, auf welchen nach jeder Veröffentlichung der Basis- bzw. Delta-Sperrliste die aktuellen Zertifikatsperrlisten per Robocopy kopiert werden.
  
  Nach der Online-Responder Installation folgende Anpassung der Erweiterungen auf der Issuing CA:
  ::Lege die URLs in der AIA-Erweiterung fest.
  certutil -setreg CA\CACertPublicationURLs "1:%WinDir%\System32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n3:ldap:///cn=%%7,cn=AIA,cn=Public Key Services,cn=Services,%%6%%11\n2:http://www.contoso.com/CertData/%%1_%%3%%4.crt\n2:http://%%1/CertEnroll/%%1_%%3%%4.crt\n32:http://contca03.contoso.com/ocsp"
  
  ::Ermögliche die Erneuerung von OCSP-Antwortsignaturzertifikaten unter Verwendung der vorhandenen Schlüssel
  certutil -setreg CA\UseDefinedCACertInRequest 1
  
  Mein Problem ist nun, dass ich beispielsweise die V1-Zertifikatsvorlage "Computer" kopiere und als eine neue V3-Vorlage mit dem Zweck "Serverauthentifizierung" auf der Issuing CA bereitstelle. Per GPO wird die Automatische Registrierung angewiesen und die Server erhalten das V3-Zertifikat ausgestellt, soweit alles wunderbar. Mein Problem ist nun, das die Zertifikate weiterhin im lokalen Zertifikatspeicher der Server (2008 & 2008 R2) als gültig deklariert bleiben (auch nach einem Neustart!), obwohl das jeweilige Zertifikat auf der Issuing-CA gesperrt (Abgelöst) und eine neue Sperrliste veröffentlicht wurde. Ich versteh das nicht! Was mach ich falsch?
  
  <EDIT>
  Wenn das gesperrte Serverzertifikat als CER-Datei exportiert wird, läßt sich der Sperrstatus mit folgendem Befehl prüfen:
  certutil -url "C:\<Servername>.cer"
  Das Ergebnis der OCSP-Prüfung lautet GESPERRT.
  
  Den gleichen Sperrstatus des Zertifkats erhalte ich per:
  certutil -config "contca03\Contoso Issuing CA" -isvalid "<Seriennummer>"
  
  Leider erschliesst sich mir aber immer noch nicht die fehlerhafte Anzeige des Zertifikatsstatus im lokalen Cache (MMC, Zertikate, Lokaler Computer) des Servers (Anzeige: Zertifikat ist gültig). Wenn die Eigenschaften des gesperrten Zertifikats innerhalb der Zertifizierungsstelle geöffnet werden, lautet dort der Status "Dieses Zertifikat wurde durch seine Zertifizierungsstelle gesperrt."
  
  Des weiteren ist es Clients ohne Fehlermeldung möglich sich auf einen Terminalserver zu verbinden, der dieses gesperrte Zertifikat verwendet."
  </EDIT>
  
  Ich weiss, ist eine etwas längere Beschreibung, aber auch ein etwas komplexeres Themengebiet :)
  
  Grüße,
  
  Dominik

  • Bearbeitet dpm78 Mittwoch, 11. November 2009 18:06 Korrektur

  Mittwoch, 11. November 2009 17:58

  Antworten

  |

  Zitieren
• 

  

  0

  Anmelden

  Ok, dann beantworte ich selbst mein Problem. Die MMC führt keine Sperrüberprüfung durch und deshalb wird auf dem Server das Zertifikat dennoch als gültig ausgewiesen, obwohl es effektiv gesperrt ist.

  • Als Antwort markiert dpm78 Donnerstag, 19. November 2009 07:02
  • Tag als Antwort aufgehoben dpm78 Donnerstag, 19. November 2009 13:44

  Donnerstag, 19. November 2009 07:01

  Antworten

  |

  Zitieren
• 

  

  0

  Anmelden

  Hi,
  
  es freut mich zu hören, daß Du Deine Frage damit beantworten konntest. Jedoch hat die Sperrprüfung der MMC im Kern nichts mit den von Dir gestellten Fragen zu tun oder irre ich mich da?
  
  Viele Grüße
  Fabian

  ---

  http://blogs.technet.com/deds

  Donnerstag, 19. November 2009 11:05

  Antworten

  |

  Zitieren
• 

  

  0

  Anmelden

  Hi Fabian,
  
  als ich diesen Thread erstellt hatte, waren mir die AIA- und CDP-Erweiterungen in den Zertifikaten bzw. der grundsätzlichen Konfiguration innerhalb der AD CS noch unbekannt. Jetzt, nachdem ich mich tiefer in dieses Gebiet hineingewagt habe, machte mich vor allem die Tatsache stutzig, dass wenn ich ein Zertifikat sperrte und ich jenes nach einem GPUPDATE /FORCE auf dem Server per Doppelklick geöffnet habe, es weiterhin als gültig angezeigt wurde. Das muss man halt wissen, dass diese Konsole, die das Zertifikat anzeigt, keine Sperrüberprüfung des Zertifikats durchführt und die Zertifikate dort immer gültig deklariert sind. Iwie unlogisch, oder?
  
  Das Problem mit dem Online-Responder hat sich für mich nun ebenso geklärt. Wenn Clients per OCSP ein Zertifikat als gültig in ihrem Cache zwischengespeichert haben und man daraufhin das Zertifikat sperrt, wird es dennoch bis zur nächsten regulären CRL-Veröffentlichung weiterhin als gültig betrachtet. Die Online Responder Einstellung des Aktualisierungsintervalls der Sperrkonfiguration hat darauf keinerlei Auswirkung. Die OCSP-Antworten richten sich also folglich nach dem definierten Zeitintervall der Delta- bzw. Basis-Sperrlistenveröffentlichung.
  
  Greets,
  
  Dominik
  
  /EDIT: Ahja, wenn ich`s mir noch Recht überlege, hab ich doch noch`n offenes Thema und zwar die Automatische Zertifikatregistrierung per GPO. Wenn ich das automatisch ausgestellte Zertifikat sperre und danach die Gruppenrichtlinien aktualisiere, wird das ausgestellte Zertifikat nicht automatisch entfernt und erneuert. Welcher Mechanismus steckt dahinter bzw. wo kann ich da mehr drüber erfahren. Mir scheint es, als ob es wiederum mit den Zeiten der nächsten CRL-Veröffentlichung zusammenhängt, womöglich :)

  • Bearbeitet dpm78 Donnerstag, 19. November 2009 16:43 +

  Donnerstag, 19. November 2009 13:38

  Antworten

  |

  Zitieren