Zertifikatsspeicher Update

[phatair 38]

Hallo zusammen,

 

ich habe mal eine kurze Frage zum Windows Zertifikatsspeicher und dessen Aktualisierung.

 

Unsere Server haben alle keinen bzw. sehr eingeschränkten Internet Zugriff.

Nun ist es ja so, dass der Zertifikatsspeicher auch aktualisiert werden muss, damit Root Zertifikate usw. aktualisiert werden.

Wie funktioniert dieses Update. Erfolgt das über die Kumulativen Updates die man über den WSUS freigibt oder erfolgt dies immer direkt übers Internet?

Das würde dann ja bedeuten, dass man bestimmte Microsoft IPs freigeben müsste, damit der Zertifikatsspeicher aktualisiert werden kann.

 

Oder sehe ich das falsch?

Vielen Dank im Voraus.

[NorbertFe 1.805]

Du könntest dir natürlich auch die notwendigen Zertifikate selbst verteilen. :) Dann hast du komplette Kontrolle.

[phatair 38]

vor 9 Minuten schrieb NorbertFe:

Du könntest dir natürlich auch die notwendigen Zertifikate selbst verteilen. :) Dann hast du komplette Kontrolle.

das wäre natürlich auch eine Idee.

Aber mal eine blöde Frage, woher bekomme ich diese bzw. gibt es da eine Übersicht? Ich kann zwar in den ZertSpeicher schauen, aber das sind ja extrem viele Zertifikate und Kategorien und das ist doch recht komplex.

[NorbertFe 1.805]

Die Empfehlung lt. Security Guide ist sowieso den Store komplett zu leeren und nur die reinzunehmen, von denen man weiß, dass man sie benötigt. ;)

Alternativ schau mal, ob das auch noch für 2016 aufwärts gilt. Ich habs nicht getestet:

https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn265983(v=ws.11)

[phatair 38]

Alles klar. Danke für den Hinweis und den Denkanstoß.

 

Das heißt aber, um auf die ursprüngliche Frage zurückzukommen, dass die Zertifikate standardmäßige durch die CUs aktualisiert werden oder direkt übers Internet aktualisiert werden?

[NorbertFe 1.805]

vor 1 Minute schrieb phatair:

direkt übers Internet aktualisiert werden?

standardmäßig auf jeden Fall übers I-net. Kann man per Policy abdrehen, damit nicht ständig Anfragen an der Firewall ankommen. Da könnte man dann aber sehen, wo die Kisten hinwollen. Lt. obigem Link muss das dann ja http://ctldl.windowsupdate.com sein.

[phatair 38]

Hallo zusammen, 

 

Ich hole nochmal den alten Beitrag hoch. 

Das Thema wird jetzt wieder aktuell bei uns, da es in den letzten Wochen etwas vernachlässigt wurde. 

 

Es wurde jetzt ein neuer 2019er Server installiert und dieser hat kein WAN Zugriff. 

Aus diesem Grund sind auch die root Zertifikate nicht auf dem aktuellen Stand. 

 

Nun haben wir eine Software, welche sich mit einem Dienst von uns verbindet der über https kommuniziert und ein öffentliches Zertifikat verwendet (also nicht von unserer internen pki ausgestellt wurde). 

 

Der Dienst verbindet sich nicht, da die zertifikstskette nicht vollständig ist. Schaue ich mir das Zertifikat an, sehe ich das eben das root und Zwischenzertifikat fehlt.

 

Die Zertifikate werden doch nur dafür benötigt, dass ich öffentliche Zertifikate problemlos auf dem Server nutzen kann und Browser usw diesen auch vertrauen, oder werden diese auch für interne windows Dienste, Funktionen usw. verwendet und abgelaufene root Zertifikate könnten somit irgendwann zu Windows Problemen führen? 

 

Eine manuelle Pflege der Zertifikate ist aktuell etwas schwierig, daher sehe ich aktuell 2 Möglichkeiten.

 

1. Download direkt über http://ctldl.windowsupdate.com

Diese URL habe ich in der Firewall schon freigegeben inkl wildcard. Aber wie kann ich den automatischen download von Microsoft anstoßen?  Normalerweise passiert das wohl 1x in der Woche. Aber auch nach einem Neustart scheinen sich die Zertifikate noch nicht erneuert zu haben. Kann ich das irgendwie manuell anstoßen? 

 

2. Ich lade die CTLs usw per Certutil.exe in einen freigegeben Ordner und Verweis per gpo auf diesen. 

Damit müsste ich die Server nicht zu den MS Servern lassen.

 

Wie handhabt ihr das bei euch und gibt es gravierende Nachteile bei einer der beiden Lösungen? 

 

Vielen Dank euch. 

[NilsK 2.785]

Moin,

 

ich habe bislang nicht mit Umgebungen zu tun gehabt, in denen sowas ein Thema war. Aber weiter unten in dem von Norbert empfohlenen Link steht ja ein Verfahren, in dem man die Root-Zertifikate von einem Client (der ins Internet darf und so die CTLs aktualisiert) exportiert, um sie komplett oder teilweise einem Rechner zur Verfügung zu stellen, der das nicht im Internet aktualisieren darf.  Schon probiert?

 

Der gravierende Nachteil von 1. scheint mir im Moment ja zu sein, dass du es nicht zum Laufen bekommst.

 

Gruß, Nils

 

[phatair 38]

Hi Nils,

 

danke für deine Antwort.

Der Zugriff auf http://ctldl.windowsupdate.com funktioniert nun auf den Servern, ohne diesen kompletten Internet Zugriff oder Zugriff auf die Windows Updates Services zu geben.

Bezüglich der "manuellen Verteilung" der CTLs - das wäre eine Lösung, ist mir aber zu fehleranfällig und wenn ich den Zugriff über die Firewall so granular steuern kann, würde ich es gerne direkt durchführen.

Nur verstehe ich den Update Prozess der Root Zertifikate noch nicht wirklich.

 

Ich habe ein Sectigo Zertifikat, welches ein Zwischenzertifikat und ein Root Zertifikat von Sectigo benötigt.

Das Zwischen- und das Root Zertifikat fehlt im Windows Cert Store. Wenn ich die oben genannte URL freigebe kann ich die Cab bzw. SST Datei von der URL runterladen. Der Zugriff funktioniert also.

 

Rufe ich die Webseite mit dem gebundenen SSL Zertifikat auf, erhalte ich die Meldung, dass die Zertifikatskette nicht geprüft werden konnte. Das ist auch korrekt, da eben die beiden Zertifikate fehlen. Nur werden diese nicht automatisch von MS runtergeladen. Das hätte ich jetzt erwartet - zumindest das root Zertifikat. Auch verstehe ich nicht, welche Zertifikate in "vertrauenswürdige Stammzertifizierungstellen" automatisch geladen werden. Aktuell sind dort 22 Zertifikate vorhanden, führe ich ein manuelles certutil -verifyCTL -f AuthRootWU aus, werden über 300 Zertifikte für vertrauenswürdige Stammzertifizierungstellen geladen.

 

Im Zertifikat sehe ich, dass bei "Zugriff auf Stelleninformationen" die URL für die Zwischenzertifikate und das Root Zertifikat hinterlegt ist. Das heißt der Browser prüft direkt online die Zertifikate ab. Dazu musste ich in der Firewall den Service "Sectigo" freigeben. Damit wird dann das Zwischenzertifikat online geprüft (erscheint nie automatisch im Windows Zertifikatsspeicher) und das Root Zertifikat wird dann automatisch runtergeladen und landet im Windows Zertifikatsspeicher unter "vertrauenswürdige Stammzertifizierungstellen". Somit wird das Root Zertifikat nicht von http://ctldl.windowsupdate.com geladen, sondern von einer Sectigo Seite.

 

Das Thema ist wahrscheinlich zu komplex um es hier im Forum zu besprechen. Wollte die Infos nur noch mal teilen

Wir geben jetzt am Ende die http://ctldl.windowsupdate.com frei, damit im Falle Windows die Zertifikate laden kann und geben in der Firewall die Sectigo Internet Services frei, damit dort auch die notwendigen Zertifikate geladen/geprüft werden können. Da wir nur öffentliche Zertifikate von Sectigo verwenden, sollten andere CAs auch nicht benötigt werden. Die meisten Dienste/Anwendungen sind sowieso von der internen PKI ausgestellt und da stellt sich die Frage mit dem Root und Zwischenzertifikat nicht, da diese sowieso automatisch verteilt werden.

bearbeitet 15. März 2023 von phatair

[NorbertFe 1.805]

vor 5 Minuten schrieb phatair:

Ich habe ein Sectigo Zertifikat, welches ein Zwischenzertifikat und ein Root Zertifikat von Sectigo benötigt.

Das Zwischen- und das Root Zertifikat fehlt im Windows Cert Store. Wenn ich die oben genannte URL freigebe kann ich die Cab bzw. SST Datei von der URL runterladen. Der Zugriff funktioniert also.

Das Zwischenzertifikat muss dir eigentlich der Webserver liefern. Das Rootzertifikat kommt aus dem Cert-Store. Aber frag mich jetzt nicht, wie das da reinkommt. Üblicherweise über obigen Weg.

[phatair 38]

vor 4 Minuten schrieb NorbertFe:

Das Zwischenzertifikat muss dir eigentlich der Webserver liefern. Das Rootzertifikat kommt aus dem Cert-Store. Aber frag mich jetzt nicht, wie das da reinkommt. Üblicherweise über obigen Weg.

Das dachte ich auch. Aber ist wohl nicht so. Laut unserem Dienstleister wird das online abgerufen (kann so passieren, muss aber nicht immer so sein).

 

Das steht in unserem Zertifikat. Und hier wird auf das Zwischenzertifikat gezeigt. Dieses Zwischenzertifikat ist auch im lokalen Windows Zertifikatsspeicher gar nicht vorhanden, trotzdem ist die Zertifikatskette gültig. Das geht eben nur, wenn die FW Sectigo Services zulässt.

[NilsK 2.785]

Moin,

 

es klingt so, als erwartest du eine Art Zertifikats-Download bei Bedarf. So verstehe ich die Mimik aber nicht. Wenn man Windows lässt, wie es will, dann installiert und aktualisiert es einen großen Schwung von Zertifikaten, mit denen ein großer Schwung von Diensten funktioniert. Das ist mehr oder weniger zeitgesteuert, Updates gibt es dann, wenn welche vorliegen. Die Auswahl der so verteilten Zertifikate liegt bei Microsoft und wird sicher auf Verträgen mit deren Anbietern beruhen.

 

Willst du das so nicht, dann musst du eben selbst eingreifen und den Aufwand in Kauf nehmen, den das bedeutet. Da kann es dann eben vorkommen, dass du das im Einzelfall nachsteuern musst. Hier wird die Annahme sein, dass der Einzelfall bei einem konkreten System eben ein Einzelfall ist, weil man da dann ja auch nicht so viele Services braucht.

 

Das ist jetzt aber nur mein Verständnis ohne weitere Recherche. Um Details habe ich mich da mangels Bedarf noch nie gekümmert.

 

Gruß, Nils

 

[NorbertFe 1.805]

vor 31 Minuten schrieb phatair:

Da wir nur öffentliche Zertifikate von Sectigo verwenden, sollten andere CAs auch nicht benötigt werden.

Wärs dann nicht das einfachste, einfach die Root/Intermediate CAs von Sectigo runterzuladen und zu verteilen? Dann brauchst du doch nur noch die CRL URLs freigeben (wenn gewünscht) und alles läuft. Klingt für mich nach weniger Aufwand.

[phatair 38]

vor 29 Minuten schrieb NilsK:

es klingt so, als erwartest du eine Art Zertifikats-Download bei Bedarf. So verstehe ich die Mimik aber nicht. Wenn man Windows lässt, wie es will, dann installiert und aktualisiert es einen großen Schwung von Zertifikaten, mit denen ein großer Schwung von Diensten funktioniert. Das ist mehr oder weniger zeitgesteuert, Updates gibt es dann, wenn welche vorliegen. Die Auswahl der so verteilten Zertifikate liegt bei Microsoft und wird sicher auf Verträgen mit deren Anbietern beruhen.

 

Ja, stimmt. So hatte ich das vermutet, dass Windows die Root Zertifikate bei Bedarf runterlädt. Aber mir fehlt jetzt auch die Zeit das Thema im Ganzen zu recherchieren und mit der aktuellen Lösung es sauber und Risiken sehe ich dort aktuell nicht.

 

vor 24 Minuten schrieb NorbertFe:

Wärs dann nicht das einfachste, einfach die Root/Intermediate CAs von Sectigo runterzuladen und zu verteilen? Dann brauchst du doch nur noch die CRL URLs freigeben (wenn gewünscht) und alles läuft. Klingt für mich nach weniger Aufwand.

Manuell möchte ich die Zertifikate eigentlich nicht laden, da ich dann immer aufpassen muss, dass ich diese auch erneuere.

Da ich bei unserer Firewall vordefinierte und automatisch gepflegte "Internet Services" in den Regeln definieren kann, wähle ich hier einfach "Sectigo" aus. Damit erschlage ich gleich auch die CRL Urls. 

Nachteil ist natürlich, dass in dem "Internet Service" Sectigo nicht nur die URLs für die Zertifikate hinterlegt sind, sondern ein Großteil der Sectigo Infrastruktur. 

Aber das Risiko ist es mir wert und das dieser Zugriff missbraucht werden könnte halte ich für eher unwahrscheinlich. Aber da driften wir schon in den Bereich Security ab ;)

 

Vielen Dank für eure Antworten und Hilfe!

[NorbertFe 1.805]

Gerade eben schrieb phatair:

Manuell möchte ich die Zertifikate eigentlich nicht laden, da ich dann immer aufpassen muss, dass ich diese auch erneuere.

 

Die Root CA wechselt ja nun auch nicht ständig und bei jedem Wechsel eurer Sectigo Zertifikate würde man ja grundsätzlich auch die Intermediate und Root CAs prüfen können. Also der Aufwand hält sich in Grenzen. Aber ja in wär auch für Automatismus.