Server 2008 PKI - Verteilungspunkte HTTP trotz Deaktivierung vorhanden

toasti · 21. Februar 2010

Hallo zusammen,

hatte ursprünglich in folgenden Thread gepostet: http://www.mcseboard.de/windows-forum-allgemein-83/unternehmens-pki-http-fehler-2-152914.html

olc hat mir dann empfohlen einen neuen Thread aufzumachen - hier ist er ;-)

Ich lerne grad auf die 70-640 und kaue grad PKI durch. Habe mit http-Fehlern bei der StammCert-Stelle zu kämpfen. Hier heißt es "Download nicht möglich" obwohl ich bei den "Sperrlisten-Verteilungspunkten" und "Zugriff auf "Stelleninformationen die Haken bei HTTP rausgenommen habe, d.h. diese Speicherorte sollten im Endeffekt nicht veröffentlich werden.

Werden sie aber doch und ich bekomme ebenfalls bei AIA-Speicherort #2 und Speicherort für Sperrlisten-Verteilungspunkte #2 den Fehler "Download nicht möglich"

Bei der Ausstellenden Certstelle wiederum klappt das wunderbar, nur die 3 LDAP Speicherorte tauchen auf (AIA-Speicherort, DeltaCRL und Speicherort für Verteilungspunkte).

Das Stammzertifizierungsstellen-Cert habe ich bereits erneuert.

Habt ihr einen Tipp??

Grüße und vielen Dank im Voraus

toasti

toasti · 21. Februar 2010

Ups, seh grad, dass ich im Client Forum geschrieben habe - könnte das bitte ein Mod ins Server Forum verschieben? Danke!

blub · 21. Februar 2010

Ups, seh grad, dass ich im Client Forum geschrieben habe - könnte das bitte ein Mod ins Server Forum verschieben? Danke!

nicht solange arbeiten! ;)

blub

olc · 21. Februar 2010

Hi,

so richtig verstanden habe ich das Problem ehrlich gesagt nicht. Daher noch einmal die Nachfrage:

Du möchtest die AIA und CDP Lokationen aus dem Zertifikat Deiner Root CA "entfernen", korrekt?

Für von der Root CA ausgestellte Zertifikate funktioniert es (wobei das in den meisten Fällen nicht empfehlenswert ist), aber die Root CA selbst hat auch nach der Neuerstellung des Root CA Zertifikats die URLs weiterhin im Zertifikat. Habe ich das korrekt verstanden?

Falls ja, dann wäre das "normal" - Du kannst die Verteilungspunkte, die die Root CA in Ihr Zertifikat einträgt, nicht über die GUI regeln, über die Du die Einstellungen für die auszustellenden Zertifikate setzt.

Du benötigst dafür eine "CAPolicy.inf" Datei, siehe dazu: CAPolicy.inf Syntax

In den Beispielen des Technet Artikels siehst Du, daß die AIA und CDP Einträge leer gelassen werden:

[CRLDistributionPoint]
[AuthorityInformationAccess]

Solltest Du jetzt das Root Zertifikat neu erstellen, dann bedenke dabei, daß ausgestellte Zertifikate auf das alte Root CA Zertifikat / den Private Key Thumbprint etc. verweisen. Daher werden die damit ausgestellten Zertifikate auch weiterhin Probleme melden.

Ich bin mir gerade nicht sicher - aber wenn Du den alten privaten Schlüssel der Root CA für die Zertifikaterneuerung der CA nutzt, könnte es klappen. Kannst das ja einmal testen. ;)

Viele Grüße

olc

toasti · 21. Februar 2010

nicht solange arbeiten! ;)
blub

Ich steh zur Zeit so unter Strom, die 70-640 endlich fertig zu machen, bin manchmal en weng durchn wind...gibts irgendwie Therapie Programme für Lerngeschädigte IT'ler? ;-)

Danke für's verschieben!

Hi,

so richtig verstanden habe ich das Problem ehrlich gesagt nicht. Daher noch einmal die Nachfrage:

Du möchtest die AIA und CDP Lokationen aus dem Zertifikat Deiner Root CA "entfernen", korrekt?

Ganz genau!

Für von der Root CA ausgestellte Zertifikate funktioniert es (wobei das in den meisten Fällen nicht empfehlenswert ist), aber die Root CA selbst hat auch nach der Neuerstellung des Root CA Zertifikats die URLs weiterhin im Zertifikat. Habe ich das korrekt verstanden?

Richtig, habe das Root Cert erneuert -> über Stamm-Cert-Stelle -> Alle Aufgaben -> Zertifizierungsstellenzertifikat erneuern. Dabei das Schlüsselpaar behalten, als auch schon einmal ein neues Paar generiert.

Warum ist das nicht empfehlenswert?

Falls ja, dann wäre das "normal" - Du kannst die Verteilungspunkte, die die Root CA in Ihr Zertifikat einträgt, nicht über die GUI regeln, über die Du die Einstellungen für die auszustellenden Zertifikate setzt.

Du benötigst dafür eine "CAPolicy.inf" Datei, siehe dazu: CAPolicy.inf Syntax

In den Beispielen des Technet Artikels siehst Du, daß die AIA und CDP Einträge leer gelassen werden:
[CRLDistributionPoint]
[AuthorityInformationAccess]
Solltest Du jetzt das Root Zertifikat neu erstellen, dann bedenke dabei, daß ausgestellte Zertifikate auf das alte Root CA Zertifikat / den Private Key Thumbprint etc. verweisen. Daher werden die damit ausgestellten Zertifikate auch weiterhin Probleme melden.

Ich bin mir gerade nicht sicher - aber wenn Du den alten privaten Schlüssel der Root CA für die Zertifikaterneuerung der CA nutzt, könnte es klappen. Kannst das ja einmal testen. ;)

Viele Grüße

olc

Ich habe das ganze mal als Screenshot hochgeladen um es besser zu zeigen:

http://img716.imageshack.us/img716/192/pki.jpg

Ich lerne ja mit dem offiziellen MS Press Buch und hier sind ja bekanntlich einige Fehler drin. Ich habe anhand der Übungen eben die http Punkte entfernt und laut Buch sollte diese damit auch verschwinden.

Begründung war hier, dass wir keine Sperrlisten extern zur Verfügung stellen müssen, d.h. ldap reicht da im Verzeichnisdienst gespeichert und intern von jedem zu erreichen.

Klärt mich ruhig auf, wenn was verkehrt ist bzw. ich falsch verstanden habe - die PKI Geschichte ist die Hölle für mich.

olc · 21. Februar 2010

Hi toasti,

Warum ist das nicht empfehlenswert?

Nicht meine Worte durcheinander bringen ;) :

Nicht empfehlenswert ist es, in den CA Eigenschaften keine AIA / CDP Lokationen anzugeben. Denn dann würden die von der CA ausgestellten Zertifikate keine Möglichkeit zum revocation check bekommen.

Die Einstellung gilt jedoch nicht für die Root CA selbst, daher bringt Dir die Aktion nichts (zumindest nicht für das Root CA Zertifikat).

Ich lerne ja mit dem offiziellen MS Press Buch und hier sind ja bekanntlich einige Fehler drin. Ich habe anhand der Übungen eben die http Punkte entfernt und laut Buch sollte diese damit auch verschwinden.

In den von der CA ausgestellten Zertifikaten verschwinden die URLs, nicht aus dem Root CA Zertifikat.

Begründung war hier, dass wir keine Sperrlisten extern zur Verfügung stellen müssen, d.h. ldap reicht da im Verzeichnisdienst gespeichert und intern von jedem zu erreichen.

Wie gesagt, wenn Du die Verteilungspunkte im Root Zertifikat selbst verändern möchtest, mußt Du eine CAPolicy.inf Datei verwenden und das Zertifikat der Root CA erneuern (siehe Link oben).

die PKI Geschichte ist die Hölle für mich.

Wenn man sonst nichts damit zu tun hat, ist der Einstieg sicher nicht einfach. Aber das ist doch eigentlich bei jedem Thema so - nur die Lernkurve ist bei PKI Themen recht steil. ;)

Viele Grüße

olc

toasti · 21. Februar 2010

Hi olc,

also wenn ich das richtig verstehe, kann ich in der Root CA zwar die http Verteilungspunkte aushaken, verschwinden tun sie aber nicht?

Bei der ausstellenden CA sind die aber verschwunden, aber doch auch nur weil ich es direkt bei der Issuing CA eingestellt habe und nicht aufgrund dessen, dass ich sie bei der Root CA deaktiviert habe? Richtig?

Die CA soll ja Verteilungspunkte haben, eben nur nicht die http ;-)

Wenn ich das Root Cert erneuere und vorher die Punkte ausgehakt habe, verschwinden diese trotzdem nicht aus dem Root Cert, verstehe ich das richtig?

Ich müsste dazu die CAPolicy.inf verwenden und dann das Cert erneuern? Aber dann sind doch gar keine Verteilungspunkte mehr angegeben, oder?

olc · 21. Februar 2010

Hi toasti,

noch einmal Schritt für Schritt:

1. Root CA

Das Zertifikat der Root CA enthält im Normalfall keine AIA und keine CDP. Wenn das Zertifikat der Root CA also diese Verteilungspunkte nicht enthalten soll, mußt Du diese über die CAPilcy.inf Datei als leer markieren.

2. Issuing CA

Die Issuing CA bekommt in ihr Zertifikat diejenigen Verteilungspunkte, die Du auf der Root CA in den CA Eigenschaften festgelegt hast. D.h. die Root CA stellt das Issuing CA Zertifikat aus - daher muß die Einstellung auf der Root CA durchgeführt werden.

3. Ausgestellte Zertifikate der Issuing CA

Die von der Issuing CA ausgestellten Zertifikate enthalten diejenigen URLs, die Du in den Eigenschaften der Issuing CA definiert hast. Sollen also die ausgestellten Zertifikate für Benutzer und Clients keine LDAP URL o.ä. bekommen sollen, dann mußt Du auf der Issuing CA diese URLs deaktivieren und die Benutzer bzw. Computer Zertifikate neu ausstellen.

Viele Grüße

olc

toasti · 21. Februar 2010

Hi toasti,

noch einmal Schritt für Schritt:

1. Root CA

Das Zertifikat der Root CA enthält im Normalfall keine AIA und keine CDP. Wenn das Zertifikat der Root CA also diese Verteilungspunkte nicht enthalten soll, mußt Du diese über die CAPilcy.inf Datei als leer markieren.

2. und 3. ist mir nun klar. Aber Punkt 1 liest sich für mich wie ein Wiederspruch in sich. Irgendwie versteh ichs nicht.

Wenn das Cert der Root CA keine AIA und CDP enthält, warum muss ich dann noch die INF verwenden?

Und warum werden diese als Verteilungspunkte aufgeführt?

Sorry, aber ich tu mich hier einfach umheimlich schwer...

olc · 21. Februar 2010

Hi,

wenn die Verteilungspunkte des Root CA Zertifikats jetzt schon leer sind, dann brauchst Du die CAPolicy.inf natürlich nicht mehr anlegen / anpassen. ;)

Ich hatte es so verstanden, daß auch das Zertifikat der Root CA derzeit (ungewünschte) URLs enthält.

Viele Grüße

olc

toasti · 21. Februar 2010

Also die Verteilungspunkte über http sind ausgehakt, ja. An der Root CA wie auch an der Issuing CA.

Wenn wir den oberen Teil meines Screenshots anschauen sehen wir ja die 2 http Verteilungspunkte mit dem Fehler "Download nicht möglich". Diese tauchen ja auf wenn ich auf die Root CA klicke. Wenn ich diese doch aber in der Root CA bereits ausgehakt habe, sollten die doch verschwinden.

Wenn nämlich das Cert der Root CA normal keine AIA und CDP Punkte enthalten, warum tauchen sie dann hier auf?

olc · 21. Februar 2010

Hi,

dann hast Du scheinbar doch AIA und CDP im Root CA Zertifikat hinterlegt. Wir drehen uns im Kreis.

Anders: Poste bitte einmal die Ausgabe von

C:\> certutil -v -dump RootCA.cer
C:\> certutil -v -dump IssuingCA.cer

"RootCA.cer" und "IssuingCA.cer" sind dabei die jeweils exportierten Zertifikate der Root und Issuing CA. Darin kann man dann sehen, ob AIA oder CDP URLs eingetragen sind.

Falls ja, dann muß das Root CA Zertifikat ohne diese URLs mittels CAPolicy.inf Datei neu erstellt werden. Falls nicht, schauen wir weiter.

Viele Grüß

olc

toasti · 21. Februar 2010

Hier das Cert der Issuing CA - die 2 http Adressen sind mit drin.

X.509-Zertifikat:
Version: 3
Seriennummer: 613fb7da000000000002
Signaturalgorithmus:
   Algorithmus Objekt-ID: 1.2.840.113549.1.1.5 sha1RSA
   Algorithmusparameter:
   05 00
Aussteller:
   CN=Contoso-Stammzertifizierungsstelle
   DC=contoso
   DC=com

Nicht vor: 05.02.2010 18:07
Nicht nach: 05.02.2011 18:17

Antragsteller:
   CN=Contoso-Ausstellende-ZS01
   DC=contoso
   DC=com

Öffentlicher Schlüssel-Algorithmus:
   Algorithmus Objekt-ID: 1.2.840.113549.1.1.1 RSA (RSA_SIGN)
   Algorithmusparameter:
   05 00
Länge des öffentlichen Schlüssels: 2048 Bits
Öffentlicher Schlüssel: Nicht verwendete Bits = 0
   0000  30 82 01 0a 02 82 01 01  00 e2 0e 29 4e 68 0e 47
   0010  0c da 9f 6f be 56 00 93  ee 7f ed db 8c 8e 3b a0
  ......
   0100  9a 7e be 3e 3c 98 b6 d9  a3 02 03 01 00 01
Zertifikaterweiterungen: 8
   2.5.29.19: Flags = 1(Kritisch), Länge = 5
   Basiseinschränkungen
       Typ des Antragstellers=Zertifizierungsstelle
       Einschränkung der Pfadlänge=Keine

   2.5.29.14: Flags = 0, Länge = 16
   Schlüsselkennung des Antragstellers
       f3 b7 56 81 3f e1 98 5d 19 8f ff 39 9a ea 09 cd ed 11 04 de

   2.5.29.15: Flags = 0, Länge = 4
   Schlüsselverwendung
       Digitale Signatur, Zertifikatsignatur, Offline Signieren der Zertifikatsperrliste, Signieren der Zertifikatsperrliste (86)

   1.3.6.1.4.1.311.21.1: Flags = 0, Länge = 3
   Version der Zertifizierungsstelle
       V0.0

   1.3.6.1.4.1.311.20.2: Flags = 0, Länge = c
   Zertifikatvorlagenname (Zertifikattyp)
       SubCA

   2.5.29.35: Flags = 0, Länge = 18
   Stellenschlüsselkennung
       Schlüssel-ID=76 5d c4 ad 35 df de da 35 7e d7 75 28 9a 44 43 f3 96 fa 1c

   2.5.29.31: Flags = 0, Länge = 12c
   Sperrlisten-Verteilungspunkte
       [1]Sperrlisten-Verteilungspunkt
            Name des Verteilungspunktes:
                 Vollst. Name:
                      URL=ldap:///CN=Contoso-Stammzertifizierungsstelle,CN=Server03,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=contoso,DC=com?certificateRevocationList?base?objectClass=cRLDistributionPoint
                      URL=http://server03.contoso.com/CertEnroll/Contoso-Stammzertifizierungsstelle.crl

   1.3.6.1.5.5.7.1.1: Flags = 0, Länge = 138
   Zugriff auf Stelleninformationen
       [1]Stelleninformationszugriff
            Zugriffsmethode=Zertifizierungsstellenaussteller (1.3.6.1.5.5.7.48.2)
            Alternativer Name:
                 URL=ldap:///CN=Contoso-Stammzertifizierungsstelle,CN=AIA,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=contoso,DC=com?cACertificate?base?objectClass=certificationAuthority
       [2]Stelleninformationszugriff
            Zugriffsmethode=Zertifizierungsstellenaussteller (1.3.6.1.5.5.7.48.2)
            Alternativer Name:
                 URL=http://server03.contoso.com/CertEnroll/Server03.contoso.com_Contoso-Stammzertifizierungsstelle.crt

Signaturalgorithmus:
   Algorithmus Objekt-ID: 1.2.840.113549.1.1.5 sha1RSA
   Algorithmusparameter:
   05 00
Signatur: Nicht verwendete Bits=0
   0000  89 aa 1f bd d6 6b 3e 94  09 b5 be 61 94 15 ac 7c
   ...
   00f0  cc 4a d8 06 72 9f 81 fe  c7 7d 4f c8 e4 ea 10 55
Kein Stammzertifikat
Schlüssel-ID-Hash(rfc-sha1): f3 b7 56 81 3f e1 98 5d 19 8f ff 39 9a ea 09 cd ed 11 04 de
Schlüssel-ID-Hash(sha1): e0 1a c3 69 c7 0d a3 fa 4e ba 51 13 b1 14 77 11 bd 50 de 22
Zertifikathash(md5): dd b5 ef da ff 82 2a 13 a8 ba 55 50 2e 1f e0 24
Zertifikathash(sha1): 61 a6 72 5b 7f 2b 57 1d 97 21 e0 d9 e8 82 09 6d ed 3e 4b 86
CertUtil: -dump-Befehl wurde erfolgreich ausgeführt.

Ich habe zwischendrin ein bißchen gekürzt, der Post ist auf 4000 Zeichen beschränkt...

olc · 21. Februar 2010

Hi,

ok, dann würde ich sagen, daß Du das Issuing CA Zertifikat noch nicht neu ausgestellt hast, nachdem Du auf der Root CA die Änderung durchgeführt hast (also die LDAP oder HTTP URL entfernt hast) - denn das Datum des Zertifikats ist vom "05.02.2010 18:07".

Oder das ist der Dump des falschen Zertifikats, also eines alten Issuing CA Zertifikats.

Kann es sein, daß wir ein wenig aneinander vorbei reden? ;) Du weißt, daß Du bestehende Zertifikate nicht ändern kannst, sondern diese neu ausstellen mußt?

Wie sieht es mit dem Root CA Zertifikat aus? Auch ein Dump verfügbar?

Viele Grüße

olc

toasti · 21. Februar 2010

Hi,

ok, dann würde ich sagen, daß Du das Issuing CA Zertifikat noch nicht neu ausgestellt hast, nachdem Du auf der Root CA die Änderung durchgeführt hast (also die LDAP oder HTTP URL entfernt hast) - denn das Datum des Zertifikats ist vom "05.02.2010 18:07".

Oder das ist der Dump des falschen Zertifikats, also eines alten Issuing CA Zertifikats.

Kann es sein, daß wir ein wenig aneinander vorbei reden? ;) Du weißt, daß Du bestehende Zertifikate nicht ändern kannst, sondern diese neu ausstellen mußt?

Wie sieht es mit dem Root CA Zertifikat aus? Auch ein Dump verfügbar?

Viele Grüße

olc

Aber klaro, hier ist es:

X.509-Zertifikat:
Version: 3
Seriennummer: 7fb5b3753cff90874ef618a1beb0bb2b
Signaturalgorithmus:
   Algorithmus Objekt-ID: 1.2.840.113549.1.1.5 sha1RSA
   Algorithmusparameter:
   05 00
Aussteller:
   CN=Contoso-Stammzertifizierungsstelle
   DC=contoso
   DC=com

Nicht vor: 04.02.2010 18:51
Nicht nach: 04.02.2030 19:01

Antragsteller:
   CN=Contoso-Stammzertifizierungsstelle
   DC=contoso
   DC=com

Öffentlicher Schlüssel-Algorithmus:
   Algorithmus Objekt-ID: 1.2.840.113549.1.1.1 RSA (RSA_SIGN)
   Algorithmusparameter:
   05 00
Länge des öffentlichen Schlüssels: 2048 Bits
Öffentlicher Schlüssel: Nicht verwendete Bits = 0
   0000  30 82 01 0a 02 82 01 01  00 a1 26 a9 bc 47 c9 21
...
   0100  a2 35 01 6a 22 b3 35 81  51 02 03 01 00 01
Zertifikaterweiterungen: 4
   2.5.29.15: Flags = 0, Länge = 4
   Schlüsselverwendung
       Digitale Signatur, Zertifikatsignatur, Offline Signieren der Zertifikatsperrliste, Signieren der Zertifikatsperrliste (86)

   2.5.29.19: Flags = 1(Kritisch), Länge = 5
   Basiseinschränkungen
       Typ des Antragstellers=Zertifizierungsstelle
       Einschränkung der Pfadlänge=Keine

   2.5.29.14: Flags = 0, Länge = 16
   Schlüsselkennung des Antragstellers
       76 5d c4 ad 35 df de da 35 7e d7 75 28 9a 44 43 f3 96 fa 1c

   1.3.6.1.4.1.311.21.1: Flags = 0, Länge = 3
   Version der Zertifizierungsstelle
       V0.0

Signaturalgorithmus:
   Algorithmus Objekt-ID: 1.2.840.113549.1.1.5 sha1RSA
   Algorithmusparameter:
   05 00
Signatur: Nicht verwendete Bits=0
   0000  76 69 bb b6 70 26 29 e1  85 3a fc 9a 15 a1 26 c6
...
   00f0  af 23 1b 94 6c 90 9b df  58 1c 6d 2b 18 f2 59 91
Signatur stimmt mit dem öffentlichen Schlüssel überein.
Stammzertifikat: Antragsteller stimmt mit Aussteller überein
Schlüssel-ID-Hash(rfc-sha1): 76 5d c4 ad 35 df de da 35 7e d7 75 28 9a 44 43 f3 96 fa 1c
Schlüssel-ID-Hash(sha1): 0f 03 01 b5 ad e9 14 65 db 46 95 3c d9 87 96 d3 34 0b 07 73
Zertifikathash(md5): fc d6 39 a5 9a cc 96 7b 5b 47 60 af 21 e5 92 6b
Zertifikathash(sha1): aa 3a 30 1f 89 cc ef fa 2f d5 25 bf 6c 52 50 a9 84 e1 06 c5
CertUtil: -dump-Befehl wurde erfolgreich ausgeführt.

****e Frage, aber mit dem Erneuern ist es nicht getan, oder?

Ich versuchs mal neu auszustellen, hab da natürlich noch null Routine.

Ich danke dir für deine Geduld, ehrlich!! ;-)

Anmelden

Server 2008 PKI - Verteilungspunkte HTTP trotz Deaktivierung vorhanden

Empfohlene Beiträge

toasti 11

Link zu diesem Kommentar

toasti 11

Link zu diesem Kommentar

blub 115

Link zu diesem Kommentar

olc 18

Link zu diesem Kommentar

toasti 11

Link zu diesem Kommentar

olc 18

Link zu diesem Kommentar

toasti 11

Link zu diesem Kommentar

olc 18

Link zu diesem Kommentar

toasti 11

Link zu diesem Kommentar

olc 18

Link zu diesem Kommentar

toasti 11

Link zu diesem Kommentar

olc 18

Link zu diesem Kommentar

toasti 11

Link zu diesem Kommentar

olc 18

Link zu diesem Kommentar

toasti 11

Link zu diesem Kommentar

Schreibe einen Kommentar

Menu

Aktivitäten