ketanest112
Goto Top

Windows CA: Template für Issuing CA neu angelegt

Hallöchen zusammen,

folgendes Szenario:
Es gibt eine AD-integrierte CA. Die Root-CA ist ebenfalls AD-joined wird allerdings nur einmal im Monat für Updates und CRL-Veröffentlichung hochgefahren. Des Weiteren haben wir 2 Issuing CAs, die wir mit einem personalisierten Template von "Untergeordnete Zertifizierungsstelle" erstellt haben. Nun gab es die Anforderung, dass nur die Root-CA berechtigt sein soll, Zertifikate für Sub-CAs signieren zu dürfen (standardmäßig darf das eine SubCA ja). Das Problem ist, dass ein Kollege das Template gelöscht und neu angelegt hat, mit einem anderen Namen. Nun wollten wir aufgrund von Zertifikatsablauf die Zertifikate der SubCAs erneuern, was aber leider aufgrund des Fehlers im Bild (Anhang) nicht funktioniert hat. Die ursprüngliche Vorlage hieß SubCA, die neue heißt jetzt SubCA-Custom (was auch gut so ist). Ich nehme mal an, dass durch ein Kopieren der Vorlage in den alten Namen, die Ausstellung wieder funktionieren würde. Gibt es die Möglichkeit, die von der SubCA benutzte Vorlage irgendwo anzupassen?

EDIT: Ja ich weiß, ich könnte den CSR in die Root CA importieren und dort signieren aber dafür haben wir die Root CA nicht Domain-integriert.

Danke schonmal!
VG
Ketanest
2022-08-10 11_16_32-rdp-manager

Content-ID: 3604281463

Url: https://administrator.de/forum/windows-ca-template-fuer-issuing-ca-neu-angelegt-3604281463.html

Ausgedruckt am: 22.12.2024 um 07:12 Uhr

Dani
Dani 13.08.2022 um 18:31:31 Uhr
Goto Top
Moin,
Ich nehme mal an, dass durch ein Kopieren der Vorlage in den alten Namen, die Ausstellung wieder funktionieren würde.
möglich... ich kann es gerade nicht nachstellen.

Gibt es die Möglichkeit, die von der SubCA benutzte Vorlage irgendwo anzupassen?
Du wirst das Zertifikat nicht erneueren können, weil die Vorlage/ID anders heißt. Von daher müsstest du das Zertifkat für die SubCAs nochmals neu ausstellen.

Die Root-CA ist ebenfalls AD-joined wird allerdings nur einmal im Monat für Updates und CRL-Veröffentlichung hochgefahren.
Wenn ihr eine solche große PKI habt, solltet ihr a) den Fehler mal korrgieren und ) die Architektur für Sperrlisten überdenken.


Gruß,
Dani
ketanest112
ketanest112 15.08.2022 aktualisiert um 08:34:13 Uhr
Goto Top
Zitat von @Dani:

Moin,
Ich nehme mal an, dass durch ein Kopieren der Vorlage in den alten Namen, die Ausstellung wieder funktionieren würde.
möglich... ich kann es gerade nicht nachstellen.

Gibt es die Möglichkeit, die von der SubCA benutzte Vorlage irgendwo anzupassen?
Du wirst das Zertifikat nicht erneueren können, weil die Vorlage/ID anders heißt. Von daher müsstest du das Zertifkat für die SubCAs nochmals neu ausstellen.
Ja, das wollte ich auch schon versuchen, die Vorlage so umzubenennen, dass sie so heißt wie die Alte bei der Ausstellung allerdings: Operation am offenen Herzen is in der Produktivumgebung ja immer etwas riskant. Ggf. stell ich das mal in einer Testumgebung nach. Zertifikat neu ausstellen für ne SubCA geht ja dann eigentlich nur durch Neueinrichtung oder?

Die Root-CA ist ebenfalls AD-joined wird allerdings nur einmal im Monat für Updates und CRL-Veröffentlichung hochgefahren.
Wenn ihr eine solche große PKI habt, solltet ihr a) den Fehler mal korrgieren und ) die Architektur für Sperrlisten überdenken.
a) Das versuche ich ja hiermit
b) Wieso? Wenn ich ein SubCA-Zertifkat sperren möchte fahr ich halt die offline CA hoch und sonst hab ich ja die SubCAs.


Gruß,
Dani
Gruß
Ketanest
Dani
Dani 15.08.2022, aktualisiert am 17.08.2022 um 15:28:17 Uhr
Goto Top
Moin,
Ggf. stell ich das mal in einer Testumgebung nach. Zertifikat neu ausstellen für ne SubCA geht ja dann eigentlich nur durch Neueinrichtung oder?
Neueinrichtung geht auf jeden Fall. Damit verbunden werden auf jeden Fall neue Sperrlisten und ggf. OCSPs notwendig. Je nachdem Design ist das (k) ein Beinbruch. Daher hat man in der Regel immer eine identische Spielwiese.

b) Wieso? Wenn ich ein SubCA-Zertifkat sperren möchte fahr ich halt die offline CA hoch und sonst hab ich ja die SubCAs.
Die Sperrliste der RootCA sollte immer prüfbar sein, auch wenn die VM ausgeschaltet ist. Des Weiteren nutzt ihr sicherlich OCSP. Wie soll dies bei ausgeschalteter VM funktionieren?


Gruß,
Dani
ketanest112
ketanest112 15.08.2022, aktualisiert am 17.08.2022 um 15:29:14 Uhr
Goto Top
Zitat von @Dani:

Moin,
Ggf. stell ich das mal in einer Testumgebung nach. Zertifikat neu ausstellen für ne SubCA geht ja dann eigentlich nur durch Neueinrichtung oder?
Neueinrichtung geht auf jeden Fall. Damit verbunden werden auf jeden Fall neue Sperrlisten und ggf. OCSPs notwendig. Je nachdem Design ist das (k) ein Beinbruch. Daher hat man in der Regel immer eine identische Spielwiese.

Joar ich probiere mal. Die "kaputte" SubCA (ja ich weiß eigentlich ist sie technisch nicht kaputt) muss halt bis zum Ende ihres Zertifikats weiterlaufen, falls ich mal ein Zertifikat sperren muss. Dann wirds wohl eine neue SubCA geben mit neuem Template
b) Wieso? Wenn ich ein SubCA-Zertifkat sperren möchte fahr ich halt die offline CA hoch und sonst hab ich ja die SubCAs.
Die Sperrliste der RootCA sollte immer prüfbar sein, auch wenn die VM ausgeschaltet ist. Des Weiteren nutzt ihr sicherlich OCSP. Wie soll dies bei ausgeschalteter VM funktionieren?
Prüfbar ist sie, die CRL der Root-CA wird übers AD veröffentlicht. OCSP ist aktuell noch nicht im Einsatz kommt aber. Dann werden wir die CRL der Root CA zusätzlich zum AD auf einer der SubCAs veröffentlichen, die nen OCSP kriegen wird.


Gruß,
Dani
Gruß
Ketanest
Dani
Dani 17.08.2022 um 15:32:56 Uhr
Goto Top
Moin,
Joar ich probiere mal. Die "kaputte" SubCA (ja ich weiß eigentlich ist sie technisch nicht kaputt) muss halt bis zum Ende ihres Zertifikats weiterlaufen, falls ich mal ein Zertifikat sperren muss.
das eine hat doch mit dem anderen nichts zu tun. Du kannst problemlos das Zertifikat tauschen und trotzdem können ausgestellte Zertifikate weiterhin gesperrt werden.

Prüfbar ist sie, die CRL der Root-CA wird übers AD veröffentlicht.
Ich würde niemals CRLs üer LDAP veröffentlichen. Bedeutet nämlich du hast immer Metadaten im AD, die dort eigentlicht nichts zu suchen haben. Auch die Löcher in der Firewall auf Port 389/tcp stellen heutzutage ein Angriffsvektor dar. Möchte gar nicht dran denken, wenn die CRLs über das Internet erreichbar sein muss. Abgesehen davon, dass ein Umzug der CRL/OCSP noch komplzierter wird als es schon ist.


Gruß,
Dani
ketanest112
ketanest112 17.08.2022 um 19:53:24 Uhr
Goto Top
Zitat von @Dani:

Moin,
Joar ich probiere mal. Die "kaputte" SubCA (ja ich weiß eigentlich ist sie technisch nicht kaputt) muss halt bis zum Ende ihres Zertifikats weiterlaufen, falls ich mal ein Zertifikat sperren muss.
das eine hat doch mit dem anderen nichts zu tun. Du kannst problemlos das Zertifikat tauschen und trotzdem können ausgestellte Zertifikate weiterhin gesperrt werden.
Ah stimmt, Denkfehler.

Prüfbar ist sie, die CRL der Root-CA wird übers AD veröffentlicht.
Ich würde niemals CRLs üer LDAP veröffentlichen. Bedeutet nämlich du hast immer Metadaten im AD, die dort eigentlicht nichts zu suchen haben. Auch die Löcher in der Firewall auf Port 389/tcp stellen heutzutage ein Angriffsvektor dar. Möchte gar nicht dran denken, wenn die CRLs über das Internet erreichbar sein muss. Abgesehen davon, dass ein Umzug der CRL/OCSP noch komplzierter wird als es schon ist.
LDAP ist abgeschaltet, läuft alles über 636/tcp LDAPs. Übers Internet müssen die CRLs nicht erreichbar sein. Wieso sollte ein Umzug der CRL/OCSP kompiziert sein?


Gruß,
Dani
Gruß
Ketanest
Dani
Dani 31.08.2022 um 11:01:21 Uhr
Goto Top
Moin,
LDAP ist abgeschaltet, läuft alles über 636/tcp LDAPs.
Sicher? Was steht denn in der Konfiguration? Verwendest du dafür ein Zertifikat von deiner PKI?

Wieso sollte ein Umzug der CRL/OCSP kompiziert sein?
wenn du zum Zeitpunkt X OCSP/CRL doch im Internet verfügbar machen musst, hast du in dem Fall alle Standard URLs aktiviert. D.h. du solltest sicherstellen, dass sowohl im LAN als auch über das Internet die verschiedenen erreichbar sind. Das ist mit LDAP/LADPs schier unmöglich bzw. das Sicherheitsrisiko zu groß.


Gruß,
Dani