11
Zertifizierungstelle NEU oder verschieben?
Hallo zusammen,
ich habe heute den halben Tag verbracht mich in das Thema Zertifizierungsstelle einzulesen, da unser 2008er DC in die Rente darf. Neuer DC wird auf 2016 installiert.
Aber mir fehlt irgendwie noch das 100% Verständnis und mein Vorgänger hatte wohl auch keine Ahnung.
In der Zertifizierungsstelle auf dem DC sind eigentlich nur die Zertifikate der DCs. Die anderen Zertifikate sind alle nicht mehr gültig (Zeit abgelaufen).
Was mich wundert ist, warum das Wildcard Zertifikat *.firma.local nicht angezeigt wird. Dieses Wildcard Zertifikat wurde über einen anderen Server im IIS erstellt und wird auch noch hier angezeigt. Es wurde auch EINDEUTIG von der CA die auf dem DC installiert ist ausgestellt und ist noch bis Oktober gültig. Das Zertifikat wird nur bei den beiden Terminalserver Session Hosts verwendet. Sonst nicht.
Der Exchange hat ein Wildcard-Zertifikat von eine öffentlichen CA allerdings mit .de Endung (nicht mit local), das hab ich selbst mal über den Exchange angefragt und muss demnächst erneuert werden.
Ich möchte jetzt ungern auf die Schnauze fallen und habe das auf meinem Testserver bereits probiert. Alte CA deinstalliert und eine neue Installiert. Mich irritiert, dass die Zertifikate auf den Terminal Sessionhosts einfach mal gültig bleiben, obwohl die CA nicht mehr existiert. Soweit ich gelesen habe, hätte ich die Zertifikate auf die Sperrliste setzen müssen und diese veröffentlichen. Ich habe aber nirgends gefunden wie das geht, vorallem weil ja das oben genannte Wildcard (local) Zertifikat nicht mal in der Zertifizierungsstelle auftaucht.
1. Hat jemand eine Idee warum das Zertifikat nicht da ist?
2. Wenn ich jetzt eine komplett neue unabhängige CA auf einem DC installiere, vertrauen die anderen Computer dieser dann automatisch?
3. Wenn ich die CA einfach verschiebe, dann heißt die CA auf dem anderen Server gleich. Soweit ich das gelesen habe, wird das nicht supported aber es funktioniert wohl?
Was spricht dagegen das so zu machen, außer dass der Name verwirrt, weil der noch den alten Servername beinhaltet?
Vielen Dank,
Grüße
Leon
ich habe heute den halben Tag verbracht mich in das Thema Zertifizierungsstelle einzulesen, da unser 2008er DC in die Rente darf. Neuer DC wird auf 2016 installiert.
Aber mir fehlt irgendwie noch das 100% Verständnis und mein Vorgänger hatte wohl auch keine Ahnung.
In der Zertifizierungsstelle auf dem DC sind eigentlich nur die Zertifikate der DCs. Die anderen Zertifikate sind alle nicht mehr gültig (Zeit abgelaufen).
Was mich wundert ist, warum das Wildcard Zertifikat *.firma.local nicht angezeigt wird. Dieses Wildcard Zertifikat wurde über einen anderen Server im IIS erstellt und wird auch noch hier angezeigt. Es wurde auch EINDEUTIG von der CA die auf dem DC installiert ist ausgestellt und ist noch bis Oktober gültig. Das Zertifikat wird nur bei den beiden Terminalserver Session Hosts verwendet. Sonst nicht.
Der Exchange hat ein Wildcard-Zertifikat von eine öffentlichen CA allerdings mit .de Endung (nicht mit local), das hab ich selbst mal über den Exchange angefragt und muss demnächst erneuert werden.
Ich möchte jetzt ungern auf die Schnauze fallen und habe das auf meinem Testserver bereits probiert. Alte CA deinstalliert und eine neue Installiert. Mich irritiert, dass die Zertifikate auf den Terminal Sessionhosts einfach mal gültig bleiben, obwohl die CA nicht mehr existiert. Soweit ich gelesen habe, hätte ich die Zertifikate auf die Sperrliste setzen müssen und diese veröffentlichen. Ich habe aber nirgends gefunden wie das geht, vorallem weil ja das oben genannte Wildcard (local) Zertifikat nicht mal in der Zertifizierungsstelle auftaucht.
1. Hat jemand eine Idee warum das Zertifikat nicht da ist?
2. Wenn ich jetzt eine komplett neue unabhängige CA auf einem DC installiere, vertrauen die anderen Computer dieser dann automatisch?
3. Wenn ich die CA einfach verschiebe, dann heißt die CA auf dem anderen Server gleich. Soweit ich das gelesen habe, wird das nicht supported aber es funktioniert wohl?
Was spricht dagegen das so zu machen, außer dass der Name verwirrt, weil der noch den alten Servername beinhaltet?
Vielen Dank,
Grüße
Leon
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 591200
Url: https://administrator.de/contentid/591200
Ausgedruckt am: 14.11.2024 um 03:11 Uhr
11 Kommentare
Neuester Kommentar
Hallo! Ich hatte mich heute erst mit dem Thema Zertifikate beschäftigt, bin bei weitem aber noch nicht ganz durchgestiegen (extrem Komplexes Thema).
Zu 1.): Ich kann mir, mit meinem aktuellen technischen Verständnis, nicht vorstellen, dass das Zertifikat nicht mehr da ist. Meines Wissens nach wird ein Zertifikat wie folgt erstellt:
CSR wird auf dem System, für welches man ein Zertifikat braucht, erstellt -> Privater Schlüssel wird im Zertifikatsspeicher abgelegt -> CSR wird mit Public Key bei der CA eingereicht -> das erhaltene Zertifikat wird auf dem Zielsystem abgelegt.
Somit sollte das Zertifikat noch auf dem IIS vorhanden und theoretisch nicht mehr gültig sein, wenn es die CA nicht mehr gibt. Was durchaus sein kann ist, dass Browser etc. die Daten aus Performance Gründen Cachen und nur alle X Tage neu prüfen. Es gibt auch weitere Mechanismen, welche das Phänomen erklären könnte. Teilweise könnten Webserver Clients mitgeben, welchem Zertifikat sie vertrauen sollen (ganz grob gesagt).
Zu 2.): Meines Wissens nach vertrauen Domänen Mitgliedern immer Ihrer CA der Domäne, da das Domänen Zertifikat auf den Domänen-Mitgliedern vorhanden sein müsste.
Zu 3.) Außm Bauch heraus würde ich sagen: Neu machen. Technisch kann ich die Aussage nicht stützen aber die CA hat, wie ich annehme, gewisse Parameter mit welchem sie ihre Authentizität „beweist“. Ich vermute das umziehen mehr gefrickel ist und Probleme als nutzen bereitet.
Anschließend kann ich noch anfügen, dass wenn kein Zertifikat mehr gültig ist, einfach neu machen und mit der neuen CA neue Zertifikate ausstellen. Mit deiner Domänen CA wirst du nicht auf öffentliche sperrlisten kommen, wenn dann musst du dies in deiner eigenen CA zurückziehen.
Wie anfangs erwähnt, ich bin auch kein Profi und habe noch nicht so viel tiefes Wissen, hoffe aber das meine Antwort vlt. trotzdem nützlich ist.
Zu 1.): Ich kann mir, mit meinem aktuellen technischen Verständnis, nicht vorstellen, dass das Zertifikat nicht mehr da ist. Meines Wissens nach wird ein Zertifikat wie folgt erstellt:
CSR wird auf dem System, für welches man ein Zertifikat braucht, erstellt -> Privater Schlüssel wird im Zertifikatsspeicher abgelegt -> CSR wird mit Public Key bei der CA eingereicht -> das erhaltene Zertifikat wird auf dem Zielsystem abgelegt.
Somit sollte das Zertifikat noch auf dem IIS vorhanden und theoretisch nicht mehr gültig sein, wenn es die CA nicht mehr gibt. Was durchaus sein kann ist, dass Browser etc. die Daten aus Performance Gründen Cachen und nur alle X Tage neu prüfen. Es gibt auch weitere Mechanismen, welche das Phänomen erklären könnte. Teilweise könnten Webserver Clients mitgeben, welchem Zertifikat sie vertrauen sollen (ganz grob gesagt).
Zu 2.): Meines Wissens nach vertrauen Domänen Mitgliedern immer Ihrer CA der Domäne, da das Domänen Zertifikat auf den Domänen-Mitgliedern vorhanden sein müsste.
Zu 3.) Außm Bauch heraus würde ich sagen: Neu machen. Technisch kann ich die Aussage nicht stützen aber die CA hat, wie ich annehme, gewisse Parameter mit welchem sie ihre Authentizität „beweist“. Ich vermute das umziehen mehr gefrickel ist und Probleme als nutzen bereitet.
Anschließend kann ich noch anfügen, dass wenn kein Zertifikat mehr gültig ist, einfach neu machen und mit der neuen CA neue Zertifikate ausstellen. Mit deiner Domänen CA wirst du nicht auf öffentliche sperrlisten kommen, wenn dann musst du dies in deiner eigenen CA zurückziehen.
Wie anfangs erwähnt, ich bin auch kein Profi und habe noch nicht so viel tiefes Wissen, hoffe aber das meine Antwort vlt. trotzdem nützlich ist.
@8Layer
@leon123
Gruß,
Dani
Somit sollte das Zertifikat noch auf dem IIS vorhanden und theoretisch nicht mehr gültig sein, wenn es die CA nicht mehr gibt.
Warum sollte das Zertifikat nicht mehr gültig sein?Zu 2.): Meines Wissens nach vertrauen Domänen Mitgliedern immer Ihrer CA der Domäne, da das Domänen Zertifikat auf den Domänen-Mitgliedern vorhanden sein müsste.
So ist es. Wird eine Zertifizierungstelle (unabhängig von deren Aufgabe) wird das Zertifikat automatisch an alle Windows-Computer in der Domäne verteilt.@leon123
In der Zertifizierungsstelle auf dem DC sind eigentlich nur die Zertifikate der DCs.
Nie, nie, nie eine Zertifizierungsstelle auf einem Server mit der Rolle "AD DS" installieren. Das ist aus Sicht der Sicherheit ein Mangel.Was mich wundert ist, warum das Wildcard Zertifikat *.firma.local nicht angezeigt wird.
Hast du an der richtigen Stelle im Snap-In der Zertifizierungsstelle nachgesehen? Es wurde auch EINDEUTIG von der CA die auf dem DC installiert ist ausgestellt und ist noch bis Oktober gültig.
Wie hast du die Feststellung überprüft?Mich irritiert, dass die Zertifikate auf den Terminal Sessionhosts einfach mal gültig bleiben, obwohl die CA nicht mehr existiert.
Warum sollten die Zertifikate ihre Gültigkeit verlieren?Soweit ich gelesen habe, hätte ich die Zertifikate auf die Sperrliste setzen müssen und diese veröffentlichen.
So ist es. Bloß muss die Sperrliste nach der Deinstallation auch noch erreichbar sein. Sonst macht das keinen Sinn.Ich habe aber nirgends gefunden wie das geht,
Das Snap-In der Zertifizierungstelle aufrufen, in den Bereich der ausgestellten Zertifikaten wechseln, Zertifikate markieren, Rechtsklick -> Sperren. Anschließend manuell die Sperlisten manuell aktualisieren. Je nachdem auf welchem Protokoll (LDAP, HTTP, etc...) und wo die Sperrlisten abgelegt sind, ist evtl. manuelle Nacharbeit notwendig.Wenn ich jetzt eine komplett neue unabhängige CA auf einem DC installiere, vertrauen die anderen Computer dieser dann automatisch?
Wenn diese Zertifizierungsstelle in die Domäne integrierst - Ja. Wenn ich die CA einfach verschiebe, dann heißt die CA auf dem anderen Server gleich. Soweit ich das gelesen habe, wird das nicht supported aber es funktioniert wohl?
Wo hast du das gelesen? Was spricht dagegen das so zu machen, außer dass der Name verwirrt, weil der noch den alten Servername beinhaltet?
Wenn du damals deine CA richtig geplant hast, düfte der alte Servername irgends vorkommen. Aber ich vermute mal die Detailplanung für Namensgebung, Sperrlisten, Veröffentlichungspunkte, Vorlagen, auto. Verlängerung, OCSP, etc... ist auf der Strecke geblieben.Gruß,
Dani
Zitat von @Dani:
@8Layer
@8Layer
Somit sollte das Zertifikat noch auf dem IIS vorhanden und theoretisch nicht mehr gültig sein, wenn es die CA nicht mehr gibt.
Warum sollte das Zertifikat nicht mehr gültig sein?Technisch nicht korrekt ausgedrückt, dass stimmt! Das Zertifikat an sich hat noch die normale Gültigkeit. Ich würde aber davon ausgehen, dass wenn jene CA, welche dieses Zertifikat ausgestellt hat, nicht mehr existiert, die Authentizität des Zertifikates geprüft werden kann.
*.firma.local nicht angezeigt wird.
.local ist absolut Tabu als Root Domain und sollte mman niemals verwenden. Das ist weltweit fest von der IANA dem mDNS Dienst zugeteilt und wird früher oder später Probleme im Netz machen:https://de.wikipedia.org/wiki/Zeroconf#Multicast_DNS
Mikrosoft selber rät in der Knowlegebase davon ab.
Welche Namen für lokale Domains intelligent und sinnvoll sind erfährt man z.B. hier:
https://www.heise.de/select/ct/2017/26/1513540412603853
Moin,
Wichtig wäre der Ort, wo die Sperrlisten zu finden sind. Wobei nicht einheitlich definiert ist, was geschehen soll, wenn die Sperrliste abgelaufen bzw. nicht erreichbar ist. Da habe ich schon viele Implementierungen von namhaften Softwareschmieden... das glaubt man nicht.
Solange also die alle Zwischenzeritifizierungsstellen und die eigentliche RootCA in Zertifikatsspeicher von Windows, Linux, etc... vorhanden ist und das Zertifikat nicht abgelaufen ist, wird es grundsätzlich als gültig markiert.
Gruß,
Dani
Ich würde aber davon ausgehen, dass wenn jene CA, welche dieses Zertifikat ausgestellt hat, nicht mehr existiert, die Authentizität des Zertifikates geprüft werden kann.
Nicht ganz. Der Rechner bzw. Anwendung(sfall), welche das SSL-Zertifikat verwendet, prüft im Best Case jedes Mal die im Zertifikat verankerte Sperrliste (CRL oder OCSP). Dazu muss die Zertifizierungsstelle, welche das SSL-Zertifikat ausgestellt hat, erst einmal nicht erreichbar sein.Wichtig wäre der Ort, wo die Sperrlisten zu finden sind. Wobei nicht einheitlich definiert ist, was geschehen soll, wenn die Sperrliste abgelaufen bzw. nicht erreichbar ist. Da habe ich schon viele Implementierungen von namhaften Softwareschmieden... das glaubt man nicht.
Solange also die alle Zwischenzeritifizierungsstellen und die eigentliche RootCA in Zertifikatsspeicher von Windows, Linux, etc... vorhanden ist und das Zertifikat nicht abgelaufen ist, wird es grundsätzlich als gültig markiert.
Gruß,
Dani
Zitat von @Dani:
@leon123
Guten Morgen Dani,@leon123
In der Zertifizierungsstelle auf dem DC sind eigentlich nur die Zertifikate der DCs.
Nie, nie, nie eine Zertifizierungsstelle auf einem Server mit der Rolle "AD DS" installieren. Das ist aus Sicht der Sicherheit ein Mangel.warum genau ist das ein Mangel (unser DL hat dies auch so eingerichtet, trotz DataCenter Lizenzen)? Würdest du für das Thema eine eigene VM erstellen?
Und - kann jemand dafür eine gute Schulung für Administratoren empfehlen, rund um das Thema Zertifikate (interne Server, Exchange-Server,...)?
Vielen Dank.
@leon123
In der Zertifizierungsstelle auf dem DC sind eigentlich nur die Zertifikate der DCs.
Nie, nie, nie eine Zertifizierungsstelle auf einem Server mit der Rolle "AD DS" installieren. Das ist aus Sicht der Sicherheit ein Mangel.Eine Domänenzertifizierungstelle muss doch auf den DC? Kann ich die auch einfach auf einen Member Server installieren?
Was mich wundert ist, warum das Wildcard Zertifikat *.firma.local nicht angezeigt wird.
Hast du an der richtigen Stelle im Snap-In der Zertifizierungsstelle nachgesehen?Hmm vielleicht kenne ich die Richtige stelle nicht? Ich hab halt in certsrv [Zertifizierungstelle (Lokal)] bei den Austgestellten Zertifikaten nachgesehen.
Es wurde auch EINDEUTIG von der CA die auf dem DC installiert ist ausgestellt und ist noch bis Oktober gültig.
Wie hast du die Feststellung überprüft?Ich hab mir das Zertifikat angesehen und auch im IIS des Terminalbrokers (ich hab mit meinem Vorgänger telefoniert, er hat es dort angefordert) wird es auch so angezeigt.
Mich irritiert, dass die Zertifikate auf den Terminal Sessionhosts einfach mal gültig bleiben, obwohl die CA nicht mehr existiert.
Warum sollten die Zertifikate ihre Gültigkeit verlieren?Ja ich dachte wenn ich die Zertifizierungstelle deinstalliere, dann verschwindet aus den Vertrauenswürdige Stammzertifzierungstellen das Zertifikat dieser Zertifizierungstelle und damit wäre es nicht mehr valid?
Aber es bleibt drinn hab ich gesehen.
Soweit ich gelesen habe, hätte ich die Zertifikate auf die Sperrliste setzen müssen und diese veröffentlichen.
So ist es. Bloß muss die Sperrliste nach der Deinstallation auch noch erreichbar sein. Sonst macht das keinen Sinn.Wie macht man das, damit die erreichbar bleibt?
Ich habe aber nirgends gefunden wie das geht,
Das Snap-In der Zertifizierungstelle aufrufen, in den Bereich der ausgestellten Zertifikaten wechseln, Zertifikate markieren, Rechtsklick -> Sperren. Anschließend manuell die Sperlisten manuell aktualisieren. Je nachdem auf welchem Protokoll (LDAP, HTTP, etc...) und wo die Sperrlisten abgelegt sind, ist evtl. manuelle Nacharbeit notwendig.Wenn ich jetzt eine komplett neue unabhängige CA auf einem DC installiere, vertrauen die anderen Computer dieser dann automatisch?
Wenn diese Zertifizierungsstelle in die Domäne integrierst - Ja.Was bedeutet in die Domäne integrieren? Reicht es den Server in die Domäne aufzunehmen oder muss
Wenn ich die CA einfach verschiebe, dann heißt die CA auf dem anderen Server gleich. Soweit ich das gelesen habe, wird das nicht supported aber es funktioniert wohl?
Wo hast du das gelesen?In irgendeinem Forum, der ein ähnliches Problem hatte...
Was spricht dagegen das so zu machen, außer dass der Name verwirrt, weil der noch den alten Servername beinhaltet?
Wenn du damals deine CA richtig geplant hast, düfte der alte Servername irgends vorkommen. Aber ich vermute mal die Detailplanung für Namensgebung, Sperrlisten, Veröffentlichungspunkte, Vorlagen, auto. Verlängerung, OCSP, etc... ist auf der Strecke geblieben.Ne es wurde ein Zertifikat für den Terminalserver gebraucht und dann wurde halt einfach eine schnell mit klick klick weiter installiert... Nicht mal die Webregistrierung wurde installiert.
Moin,
Ob ein DL Ahnung von der komplexen Materie hat, zeigt schon das (nicht) vorhandene Konzept sowie Empfehlungen bei der Umsetzung. Nutzt ihr für das Abfragen der Sperrliste das LDAP Protokoll? Dann wird's spätestens bei einer Migration oder dem Einsatz von dedizierten Firewalls unumgänglich entsprechende Löcher zu bohren.
Gruß,
Dani
warum genau ist das ein Mangel (unser DL hat dies auch so eingerichtet, trotz DataCenter Lizenzen)? Würdest du für das Thema eine eigene VM erstellen?
mit der Installation der Rolle mit entsprechenden Feature-Sets (z.B. Webregistierung) etliche Komponenten nachinstalliert werden müssen. Es fängt bei einfachen Dingen an, dass z.B. der Computername nicht mehr geändert werden kann. Has du den Wunsch den Namen eines DCs zu ändern, ist das nicht mehr ohne weiteres möglich. Das geht hin bis zu Sicherheitsbedenken, da durch eine mögliche Schwachstelle in der Webregistierung oder in der Zertifizierungsstelle selbst, direkt ein Domain Controller zu schaden kommen kann. Das ist für einen AD Admin der Worst Case.Ob ein DL Ahnung von der komplexen Materie hat, zeigt schon das (nicht) vorhandene Konzept sowie Empfehlungen bei der Umsetzung. Nutzt ihr für das Abfragen der Sperrliste das LDAP Protokoll? Dann wird's spätestens bei einer Migration oder dem Einsatz von dedizierten Firewalls unumgänglich entsprechende Löcher zu bohren.
Und - kann jemand dafür eine gute Schulung für Administratoren empfehlen, rund um das Thema Zertifikate (interne Server, Exchange-Server,...)?
Schau mal bei Fast Lane, Bechtle & Co. Da gibt es sicherlich was. Wir haben einen anderen Weg beschritten.Rechne aber je nach Art und Aufbau der Schulungen pro Person einen vierstelligen Betrag.Gruß,
Dani
1
Moin,
Gruß,
Dani
Eine Domänenzertifizierungstelle muss doch auf den DC? Kann ich die auch einfach auf einen Member Server installieren?
Wo hast du sowas gelesen? Du wirfst mit gefährlichen Halbwissen um dich. Ja ich dachte wenn ich die Zertifizierungstelle deinstalliere, dann verschwindet aus den Vertrauenswürdige Stammzertifzierungstellen das Zertifikat dieser Zertifizierungstelle und damit wäre es nicht mehr valid?
Ich möchte dir ungern alles vorkauen. Mit welchen Informationen/Schlussfolgerungen kommst du zu deiner Vermutung? Aber es bleibt drinn hab ich gesehen.
So ist es. Und warum bleibt es drin? Wie macht man das, damit die erreichbar bleibt?
Das hängt davon ab, auf welche Protokolle und welcher Art der Sperrlistenprüfung (CRL und/oder OCSP) du nutzt. Das kann ich von hier aus nicht sehen. Was bedeutet in die Domäne integrieren? Reicht es den Server in die Domäne aufzunehmen oder muss
Das hängt in diesem Fall (in)direkt miteinander zusammen. Wenn du die AD CS in die bestehende Domäne aufnehmen möchtest, muss der Server natürlich auch Mitglied in der AD DS sein. Andersherum kann der Server Mitglied des AD DS sein und die AD CS Standalone betrieben werden. Bei Letzterem ist natürlich der Sinn davon zu hinterfragen. Es gibt da 1-2 Beispiele, wo dies sinnvoll sein kann.Ich hab mir das Zertifikat angesehen und auch im IIS des Terminalbrokers (ich hab mit meinem Vorgänger telefoniert, er hat es dort angefordert) wird es auch so angezeigt.
Klartext bitte.. sprich in den Details des Zertifikats zeigt der Zertifizierungspfad als auch die Sperrlisten-Verteilungspunkte auf eure vorhandene Zertifizierungstelle? Ja oder Nein.Ne es wurde ein Zertifikat für den Terminalserver gebraucht und dann wurde halt einfach eine schnell mit klick klick weiter installiert... Nicht mal die Webregistrierung wurde installiert.
Ja, das hat aber nichts mit dem Zertifikat zu tun. Zu dem Zeitpunkt war die AD CS bereits vorhanden und wohl betriebsbereit. Sprich damit sind vermutlich schon die ersten Fehler in der Konfiguration der AD CS in die Zertifikate durchgeschlagen.Gruß,
Dani
Zitat von @Dani:
Moin,
In irgendeinem Forum, Halbwissen... eher kein wissen sondern Glaube und der versetzt manchmal Berge ;)Moin,
Eine Domänenzertifizierungstelle muss doch auf den DC? Kann ich die auch einfach auf einen Member Server installieren?
Wo hast du sowas gelesen? Du wirfst mit gefährlichen Halbwissen um dich.Beim Franky steht, dass ein Member Server reicht.
Ja ich dachte wenn ich die Zertifizierungstelle deinstalliere, dann verschwindet aus den Vertrauenswürdige Stammzertifzierungstellen das Zertifikat dieser Zertifizierungstelle und damit wäre es nicht mehr valid?
Ich möchte dir ungern alles vorkauen. Mit welchen Informationen/Schlussfolgerungen kommst du zu deiner Vermutung? Aber es bleibt drinn hab ich gesehen.
So ist es. Und warum bleibt es drin? Ich weiß nicht, magst du es mir verraten?
--> Meine erste Vermutung ging dahin, weil es im ADSI-Editor unter "CN= Certification Authorities" noch drinnen war (Hier waren noch 3 weitere CAs die es schon lange nicht mehr gibt, allerdings sind in den Clients noch diese CA-Zertifikate unter "vertrauenswürdige Stammzertifizierungsstellen eingetragen)
--> Auf meinem Testserver habe ich die einfach mal gelöscht ;)
Jetzt sind die bei den Clients auch weg und nur noch die neue CA wird verteilt.
Auch bei den anderen Clients wurden die alten Zertifikate aus den vertrauenswürdigen Stammzertifizierungsstellen gelöscht.
Wie macht man das, damit die erreichbar bleibt?
Das hängt davon ab, auf welche Protokolle und welcher Art der Sperrlistenprüfung (CRL und/oder OCSP) du nutzt. Das kann ich von hier aus nicht sehen.Naja bisher benutze ich garkeine... Ich hab mir hier bei LinkedIn Learning etwas angesehen... Hier werden die Sperrlisten über eine Freigabe veröffentlich. Das gilt aber nur für zukünftige Zertifikate (was ja Sinn macht).
Daher ist mir nicht klar wie das funktionieren soll weil ja der Server wo die aktuelle CA läuft, gelöscht werden soll.
Was bedeutet in die Domäne integrieren? Reicht es den Server in die Domäne aufzunehmen oder muss
Das hängt in diesem Fall (in)direkt miteinander zusammen. Wenn du die AD CS in die bestehende Domäne aufnehmen möchtest, muss der Server natürlich auch Mitglied in der AD DS sein. Andersherum kann der Server Mitglied des AD DS sein und die AD CS Standalone betrieben werden. Bei Letzterem ist natürlich der Sinn davon zu hinterfragen. Es gibt da 1-2 Beispiele, wo dies sinnvoll sein kann.Ich hab mir das Zertifikat angesehen und auch im IIS des Terminalbrokers (ich hab mit meinem Vorgänger telefoniert, er hat es dort angefordert) wird es auch so angezeigt.
Klartext bitte.. sprich in den Details des Zertifikats zeigt der Zertifizierungspfad als auch die Sperrlisten-Verteilungspunkte auf eure vorhandene Zertifizierungstelle? Ja oder Nein.Ne es wurde ein Zertifikat für den Terminalserver gebraucht und dann wurde halt einfach eine schnell mit klick klick weiter installiert... Nicht mal die Webregistrierung wurde installiert.
Ja, das hat aber nichts mit dem Zertifikat zu tun. Zu dem Zeitpunkt war die AD CS bereits vorhanden und wohl betriebsbereit. Sprich damit sind vermutlich schon die ersten Fehler in der Konfiguration der AD CS in die Zertifikate durchgeschlagen.Weiß ich nicht welche Fehler du meinst. Man hat ein Zertifikat bekommen und damit gab es keine Fehlermeldung. Seitdem wurde das nie wieder benutzt...
Moin,
Daher ist mir nicht klar wie das funktionieren soll weil ja der Server wo die aktuelle CA läuft, gelöscht werden soll.
Darum arbeitet man im Bereich der Sperrlisten mit einem DNS Alias. Was in Kombination mit HTTP widerrum relativ simpel funktioniert. Bei CIFS/SMB und LDAP sind ein paar Tricks notwendig, damit dies funktioniert. Zugleich schafft man sich damit auch potenzielle Fehlerquellen.
Gruß,
Dani
In irgendeinem Forum, Halbwissen... eher kein wissen sondern Glaube und der versetzt manchmal Berge ;)
offizielle Quellen wie Microsoft Docs ist für dich tabu? Ich weiß nicht, magst du es mir verraten?
Du bist inzwischen ja selbst darauf gekommen. Hast du geraten bzw. einfach probiert oder Microsoft Docs bemüht? Naja bisher benutze ich garkeine...
Ich hab's in der Tat noch nie ausprobiert. Aber ich meine ohne Sperrliste kann keine Zertifizierungsstelle eingerichtet werden. Daher vermute ich mal du hast die Standardkonfiguration am Laufen.Hier werden die Sperrlisten über eine Freigabe veröffentlich. Das gilt aber nur für zukünftige Zertifikate (was ja Sinn macht).
CIFS/SMB Freigaben sind aus Sicht der Usability und Security nicht zu empfehlen. Oder hast du eine einzige Zertifizierungstelle im Internet gesehen, welche die genannten Protokolle verwendet? Ich bisher nicht. In der Regel wird auf HTTP zurückgegriffen. Da somit auch Use Cases, wo die Sperrlisten aus dem Internet erreichbar sein sollen/müssen, problemlos und sicher abbildbar sind. Veröffentliche mal CIFS/SMB oder LDAP im Internet...Daher ist mir nicht klar wie das funktionieren soll weil ja der Server wo die aktuelle CA läuft, gelöscht werden soll.
Darum arbeitet man im Bereich der Sperrlisten mit einem DNS Alias. Was in Kombination mit HTTP widerrum relativ simpel funktioniert. Bei CIFS/SMB und LDAP sind ein paar Tricks notwendig, damit dies funktioniert. Zugleich schafft man sich damit auch potenzielle Fehlerquellen.
Es ist komischerweise ein Webserver Zertifikat wird aber für die RDS-Computer benutzt...
Es ist ein Zertifikat, welches über die Vorlage Webserver, ausgestellt wurde. der Name der Vorlage hat nichts mit dem Verwendungszweck zu tun. Wichtig ist, dass die Vorlage als Typ Serverauthentifizierung konfiguriert wurde. Somit kann das Zertifikat für den Zweck auch erfolgreich genutzt werden.Gruß,
Dani
