25
Konfig-Oberfläche von Netzwerkgeräten mit vertrauenswürdigem Zertifikat?
Guten Morgen,
endlich wieder Freitag und daher Zeit, Anfängerfragen zu stellen
Ich greife auf die Konfigurationsoberflächen der Router, Switches etc. per https im Browser zu. Natürlich kommt hier die
übliche Warnung, das die Zertifikate der Geräte nicht vertrauenswürdig sind.
Alle Adressen der Geräte bzw. deren Konfig-Oberfläche liegen in meinen Management-VLAN 1 (172.16.1.0/24).
Dieses Netz hat keinerlei Zugriff ins Internet. Funktionierende Windows-Domäne ist natürlich vorhanden.
Wie löse ich am elegantesten, das der/die Browser der Domänen-Clients das Geräte-Zertifikat ohne Meckern akzeptieren?
Gruß NV
endlich wieder Freitag und daher Zeit, Anfängerfragen zu stellen
Ich greife auf die Konfigurationsoberflächen der Router, Switches etc. per https im Browser zu. Natürlich kommt hier die
übliche Warnung, das die Zertifikate der Geräte nicht vertrauenswürdig sind.
Alle Adressen der Geräte bzw. deren Konfig-Oberfläche liegen in meinen Management-VLAN 1 (172.16.1.0/24).
Dieses Netz hat keinerlei Zugriff ins Internet. Funktionierende Windows-Domäne ist natürlich vorhanden.
Wie löse ich am elegantesten, das der/die Browser der Domänen-Clients das Geräte-Zertifikat ohne Meckern akzeptieren?
Gruß NV
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 480858
Url: https://administrator.de/contentid/480858
Printed on: April 20, 2024 at 02:04 o'clock
25 Comments
Latest comment
Hi
eine eigene CA aufsetzen (offline CA und Online SubCA), allen CLients das SubCA Zertifikat als Trusted Root verteilen und dann den Netzwerkgeräten entsprechende eigene Zertifikate ausstellen und dort installieren.
eine eigene CA aufsetzen (offline CA und Online SubCA), allen CLients das SubCA Zertifikat als Trusted Root verteilen und dann den Netzwerkgeräten entsprechende eigene Zertifikate ausstellen und dort installieren.
Wie löse ich am elegantesten,
Einfach diesen Zertifikaten final vertrauen und das im Browser abnicken. Dann fragt oder meckert er nicht mehr.
Moin
... wobei ich mir die Frage stelle: Steht der Nutzen auch nur ansatzweise im Verhältnis zum Aufwand?
Gruß
eine eigene CA aufsetzen...
... wobei ich mir die Frage stelle: Steht der Nutzen auch nur ansatzweise im Verhältnis zum Aufwand?
Gruß
Es geht auch ohne CA. Sammle alle Zertifikate dieser Geräte ein und pushe sie per GPO auf Deine Rechner, von denen Du zugreifen willst.
Zitat von @NixVerstehen:
Wie löse ich am elegantesten, das der/die Browser der Domänen-Clients das Geräte-Zertifikat ohne Meckern akzeptieren?
Wie löse ich am elegantesten, das der/die Browser der Domänen-Clients das Geräte-Zertifikat ohne Meckern akzeptieren?
Verteil die Gerätezertifikate an die Browser als "vertrauenswürdig".
lks
Zitat von @Hubert.N:
Moin
... wobei ich mir die Frage stelle: Steht der Nutzen auch nur ansatzweise im Verhältnis zum Aufwand?
Moin
eine eigene CA aufsetzen...
... wobei ich mir die Frage stelle: Steht der Nutzen auch nur ansatzweise im Verhältnis zum Aufwand?
Ist mit einem Pi oder einem alten Laptop in 15 Minuten aufgesetzt und betriebsbereit.
So auf die Scnelle z.B: https://penturalabs.wordpress.com/2013/08/19/creating-your-own-certifica ...
lks
er fragt ja nach der elegantesten Lösung. Aus so einer CA zieht man langfristig schon viele Vorteile. WPA Enterprise, Userauthentifizierung, Codesigning usw.
Und ein wirklicher Aufwand ist das ja nun wirklich nicht.
Und ein wirklicher Aufwand ist das ja nun wirklich nicht.
Naja, kommt drauf an, wie man das organisiert.
Wenn man eine "ordentliche CA" machen will, gehört der Rechner mit der eigentlich vom Netz abgeklemmt und in den Safe und nur rausgeholt, wenn Zertifikate zu signieren sind. Und auch diese nur offline.
Das macht man, damit kein unbefugter die CA mißbrauchen kann, um damit sich falsche Ausweise auszustellen.
Kann ca. mit Personalausweis und Clubausweis für den Bibelleseclub vergleichen. Beim ersteren muß deutlich mehr Aufwand getrieben werden als bei letzterem. Bei Firmenausweisen liegt der Aufwand irgendwo dazwischen.
Genauso ist es mit den CAs.
Zu meiner Zeit bei einem ISP hatten wir da einen Laptop dafür abgestellt, der wirklich in den Safe reinkam und nur zu zweit aus dem Safe geholt wurde und anschließend gleich wieder reinkam.
lks
Zitat von @SeaStorm:
eine eigene CA aufsetzen (offline CA und Online SubCA), allen CLients das SubCA Zertifikat als Trusted Root verteilen und dann den Netzwerkgeräten entsprechende eigene Zertifikate ausstellen und dort installieren.
eine eigene CA aufsetzen (offline CA und Online SubCA), allen CLients das SubCA Zertifikat als Trusted Root verteilen und dann den Netzwerkgeräten entsprechende eigene Zertifikate ausstellen und dort installieren.
Ich kenne es eigentlich so, dass man das CA-Cert der OfflineCA verteilt statt das der SubCA. Wenn die SubCA kompromitiert wurde und du nur die SubCA verteilst, müsstest du das CA-Cert der SubCA an alle Clients neu verteilen. Wenn die SubCA kompromitiert wurde und das CA-Cert der OfflineCA an die Clients verteilt wurde, tauschst du einfach die SubCA aus und an den Clients musst du nichts ändern. Die kompromitierte SubCA kommt einfach auf die CRL und gut is.
Wo würdet Ihr den CA installieren? Auf dem DC? Eine eigene Server Lizenz dafür kaufen?
Hi,
danke an alle für so viele Input. Also zusammenfassend
1. Eigene CA bauen oder
2. Geräte-Zertifikate einzeln herunterladen und per GPO verteilen
3. Browser-Gemecker akzeptieren und je nach Brpwser Ausnahmeregel hinzufügen
@lks: Kann ich statt dem PI z.B. auch ein Ubuntu oder Debian als VM auf meinen Hyper-V Host verwenden oder gleich meine Ubuntu-Server-VM
(macht aktuell nur Monitoring mit Zabbix) als CA einrichten?
@tikayevent: Endziel ist eigentlich unser Gäste-WLAN auf ein Captiva-Portal umzustellen und die Login-Seite per https aufzurufen. Verwenden möchte ich dazu unseren Lancom 1781 VA mit Public Spot-Option und einem Lancom LW-500 AP, der nur für das Gäste-WLAN da ist. Aktuell läuft diese WLAN noch per WPA-PSK in einem separaten VLAN, das über zwei Switches bis zum Router durchgereicht ist und dort per FW-Regel nur ins Internet, aber in kein anderes Netz kann. Ich hoffe, "Dr. Lancom" sagt jetzt nicht, daß das nicht geht
@aqui: Final akzeptieren ist prinzipiell die einfachste Lösung, aber auf die Verwaltungsseite des zukünftigen Captiva-Portals soll mit separaten Nutzern (zwei meiner Kolleginnen) per https zugegriffen werden, die dann für Gäste WLAN-Voucher drucken können (z.B. mit Ablaufzeitpunkt).
Und den beiden Kolleginnen möchte ich natürlich nicht sagen, daß sie Zertifikatswarnungen einfach abnicken sollen.
@all: Ich dachte eben, wenn ich das Zertifikat-Gedöns wegen o.g. Thematik ohnehin anpacken muss, wollte ich es eben gleich für alle Geräte ordentlich machen.
Gruß NV
danke an alle für so viele Input. Also zusammenfassend
1. Eigene CA bauen oder
2. Geräte-Zertifikate einzeln herunterladen und per GPO verteilen
3. Browser-Gemecker akzeptieren und je nach Brpwser Ausnahmeregel hinzufügen
@lks: Kann ich statt dem PI z.B. auch ein Ubuntu oder Debian als VM auf meinen Hyper-V Host verwenden oder gleich meine Ubuntu-Server-VM
(macht aktuell nur Monitoring mit Zabbix) als CA einrichten?
@tikayevent: Endziel ist eigentlich unser Gäste-WLAN auf ein Captiva-Portal umzustellen und die Login-Seite per https aufzurufen. Verwenden möchte ich dazu unseren Lancom 1781 VA mit Public Spot-Option und einem Lancom LW-500 AP, der nur für das Gäste-WLAN da ist. Aktuell läuft diese WLAN noch per WPA-PSK in einem separaten VLAN, das über zwei Switches bis zum Router durchgereicht ist und dort per FW-Regel nur ins Internet, aber in kein anderes Netz kann. Ich hoffe, "Dr. Lancom" sagt jetzt nicht, daß das nicht geht
@aqui: Final akzeptieren ist prinzipiell die einfachste Lösung, aber auf die Verwaltungsseite des zukünftigen Captiva-Portals soll mit separaten Nutzern (zwei meiner Kolleginnen) per https zugegriffen werden, die dann für Gäste WLAN-Voucher drucken können (z.B. mit Ablaufzeitpunkt).
Und den beiden Kolleginnen möchte ich natürlich nicht sagen, daß sie Zertifikatswarnungen einfach abnicken sollen.
@all: Ich dachte eben, wenn ich das Zertifikat-Gedöns wegen o.g. Thematik ohnehin anpacken muss, wollte ich es eben gleich für alle Geräte ordentlich machen.
Gruß NV
Zitat von @NordicMike:
Wo würdet Ihr den CA installieren? Auf dem DC? Eine eigene Server Lizenz dafür kaufen?
Wo würdet Ihr den CA installieren? Auf dem DC? Eine eigene Server Lizenz dafür kaufen?
Auf einem raspberry Pi.
lks
Zitat von @NixVerstehen:
@lks: Kann ich statt dem PI z.B. auch ein Ubuntu oder Debian als VM auf meinen Hyper-V Host verwenden oder gleich meine Ubuntu-Server-VM
(macht aktuell nur Monitoring mit Zabbix) als CA einrichten?
@lks: Kann ich statt dem PI z.B. auch ein Ubuntu oder Debian als VM auf meinen Hyper-V Host verwenden oder gleich meine Ubuntu-Server-VM
(macht aktuell nur Monitoring mit Zabbix) als CA einrichten?
Jepp.
Aber wie schon oben geschrieben, ist es davon abhängig, wie sicher das ganze sein soll. Üblicherweise ist die CA auf einem offline-System und wird nur hervorgeholt, um subCAs, Server, o.ä zu signieren.
@all: Ich dachte eben, wenn ich das Zertifikat-Gedöns wegen o.g. Thematik ohnehin anpacken muss, wollte ich es eben gleich für alle Geräte ordentlich machen.
Sinnvoll.
lks
Zitat von @Lochkartenstanzer:
Jepp.
Aber wie schon oben geschrieben, ist es davon abhängig, wie sicher das ganze sein soll. Üblicherweise ist die CA auf einem offline-System und wird nur hervorgeholt, um subCAs, Server, o.ä zu signieren.
Zitat von @NixVerstehen:
@lks: Kann ich statt dem PI z.B. auch ein Ubuntu oder Debian als VM auf meinen Hyper-V Host verwenden oder gleich meine Ubuntu-Server-VM
(macht aktuell nur Monitoring mit Zabbix) als CA einrichten?
@lks: Kann ich statt dem PI z.B. auch ein Ubuntu oder Debian als VM auf meinen Hyper-V Host verwenden oder gleich meine Ubuntu-Server-VM
(macht aktuell nur Monitoring mit Zabbix) als CA einrichten?
Jepp.
Aber wie schon oben geschrieben, ist es davon abhängig, wie sicher das ganze sein soll. Üblicherweise ist die CA auf einem offline-System und wird nur hervorgeholt, um subCAs, Server, o.ä zu signieren.
Ok. Da muss ich mir vermutlich noch einige Basics zum Thema aneignen. Die CA muss also nicht dauerhaft online sein, sondern wird nur benötigt, wenn ich für ein Gerät ein Zertifikat erstellen möchte? Der Browser prüft nicht gegen die CA, ob das Zertifikat vertrauenswürdig ist, sondern nur, ob es in seiner Liste vertrauenswürdiger CAs vorhanden ist?
Also beim PI einfach Stecker raus, wenn nicht benötigt oder als VM-Lösung einfach die VM auf dem Host ausschalten, wenn die CA nicht gebraucht wird?
Gruß NV
Zitat von @NixVerstehen:
Ok. Da muss ich mir vermutlich noch einige Basics zum Thema aneignen. Die CA muss also nicht dauerhaft online sein, sondern wird nur benötigt, wenn ich für ein Gerät ein Zertifikat erstellen möchte? Der Browser prüft nicht gegen die CA, ob das Zertifikat vertrauenswürdig ist, sondern nur, ob es in seiner Liste vertrauenswürdiger CAs vorhanden ist?
Ok. Da muss ich mir vermutlich noch einige Basics zum Thema aneignen. Die CA muss also nicht dauerhaft online sein, sondern wird nur benötigt, wenn ich für ein Gerät ein Zertifikat erstellen möchte? Der Browser prüft nicht gegen die CA, ob das Zertifikat vertrauenswürdig ist, sondern nur, ob es in seiner Liste vertrauenswürdiger CAs vorhanden ist?
Genau das ist ja der Sinn von
Also beim PI einfach Stecker raus, wenn nicht benötigt oder als VM-Lösung einfach die VM auf dem Host ausschalten, wenn die CA nicht gebraucht wird?
genauso z.B.
lks
@all: Ich dachte eben, wenn ich das Zertifikat-Gedöns wegen o.g. Thematik ohnehin anpacken muss, wollte ich es eben gleich für alle Geräte ordentlich machen.
Guter Mann. So und nicht andersOk. Da muss ich mir vermutlich noch einige Basics zum Thema aneignen. Die CA muss also nicht dauerhaft online sein, sondern wird nur benötigt, wenn ich für ein Gerät ein Zertifikat erstellen möchte?
Jein.Eine ordentliche CA besteht aus der Ursprünglichen ROOT-CA. Diese stellt ein Zertifikat für eine WeitereSub-CA aus. Ausserdem stellt man eine CRL Zeit von 6 Monaten ein und veröffentlicht diese auf einen immer erreichbaren Pfad (und Gibt diesen Pfad auch im Root und Sub-CA Public Cert mit !) .
Damit geht die ROOT-CA dann offline und verschwindet für 6 Monate.
Mit dem Sub-CA Zertifikat wird eine neue, Zusätzliche Sub-CA erstellt. DIESE erstellt dann die Client und User-Zertifikate.
Diese bleibt aus diesem Grund auch Online, weil sie ja Zertifikate für Clients ausstellen soll. In einer Windows Domäne stellt man z.B für WPA Enterprise mit Zertifikatsauthentifizierung den Clients das Zertifikat automatisch aus.
Ausserdem stellt die Sub-CA regelmäßig eine CRL aus, also eine Liste an zurückgezogenen Zertifikaten, denen nicht mehr vertraut werden soll. Sonst bringt dir ein Zertifikat auch keine Sicherheit (zur Authentifizierung) wenn du es nicht Revoken kannst.
Und alle 6 Monate fährst du die ROOT-CA hoch und stellst eine neue CRL auf dieser aus, auf einen Pfad der für alle erreichbar ist.
Der Browser prüft nicht gegen die CA, ob das Zertifikat vertrauenswürdig ist, sondern nur, ob es in seiner Liste vertrauenswürdiger CAs vorhanden ist?
zum Thema Installation: Installiere das alles auf einer eigenständigen Maschine ohne andere Dienste. Und gleich gar nicht auf einen DC. Denn ein DC ist ein DC und BLEIBT ein DC! Root-CA evtl. auf einem Raspi oÄ und dann verschwinden lassen. Sichergehen das es ein Backup der SD Karte gibt
.Die SubCA dann auf eine eigene VM, die entsprechend zugenagelt wird.
Moin,
@tikayevent
@NordicMike
Die Sub-CA kommt je nach Archtitektur und Verwendung in die Domäne und wird aber ebenfalls auf eine Maschine installiert, die für nichts anderes genutzt wird. Da dort neben der Zertifizierungstelle noch weitere Services wie Webregistierung, OCSP, etc... dazu kommen. Da ist es nicht ausschließen, dass weitere Programme auf der Maschine mehr Probleme verursachen als man denkt.
@SeaStorm
@Lochkartenstanzer
Gruß,
Dani
@all: Ich dachte eben, wenn ich das Zertifikat-Gedöns wegen o.g. Thematik ohnehin anpacken muss, wollte ich es eben gleich für alle Geräte ordentlich machen.
Vorbildlich. Aber nichts überstürzten... lese in den nächsten einfach ein paar Blogartikel und Erfahrungsberichte zu dem Thema. Es gibt leider nicht all zu viele die bei dem Thema richtig gut sind. Anschließend mach dir ein paar Gedanken, was du haben willst/möchtest und wie es umsetzbar ist. Anschließend ein Testlab hochziehen und dort mit dem ganzen Konstrukt spielen, testen und prüfen. Denn hinther im Echtbetrieb etwas zu ändern, ist manchmal möglich, manachmal großer Aufwand oder gar nicht mehr möglich bzw. erst mit einer neuen SubCA.@tikayevent
Ich kenne es eigentlich so, dass man das CA-Cert der OfflineCA verteilt statt das der SubCA.
Es muss auch das Zertifikat der Sub-CA verteilt werden. Ansonsten ist die Kette unvollständig und der Browser wird meckern. Wenn die SubCA kompromitiert wurde und das CA-Cert der OfflineCA an die Clients verteilt wurde, tauschst du einfach die SubCA aus und an den Clients musst du nichts ändern.
So allgemein lässt sich das nicht sagen. Das hängt davon ab, welche Anwendungsfälle bei einem auftreten. Zumal die Pfade zur Sperrlisten, etc... nach wie vor erreichbar sein müssen und vorallem regelmäßig der Gültigskeitszeitraum aktualisert werden muss.@NordicMike
Wo würdet Ihr den CA installieren? Auf dem DC? Eine eigene Server Lizenz dafür kaufen?
Nie, nie nie! Die Root-CA gehört auf eine Maschine, welche Standalone ist. Keine Domäne, kein Internet, gar nichts.Die Sub-CA kommt je nach Archtitektur und Verwendung in die Domäne und wird aber ebenfalls auf eine Maschine installiert, die für nichts anderes genutzt wird. Da dort neben der Zertifizierungstelle noch weitere Services wie Webregistierung, OCSP, etc... dazu kommen. Da ist es nicht ausschließen, dass weitere Programme auf der Maschine mehr Probleme verursachen als man denkt.
@SeaStorm
Und ein wirklicher Aufwand ist das ja nun wirklich nicht.
Täusch dich da mal nicht... alleine für die Archtitektur, Nutzungsarten und entsprechende Vorlagen und deren Rechte kann man eine Diplomarbeit daraus machen. Wobei der Schwierigkeit eher beim sicheren, laufenden Betrieb liegt als bei einer Installation. Denn hinterher kurz mal was ändern ist meist mit großen Auswirkungen zu rechnen. Mit dem Sub-CA Zertifikat wird eine neue, Zusätzliche Sub-CA erstellt. DIESE erstellt dann die Client und User-Zertifikate.
Eine SubCA von einer SubCA macht man meines Wissens nach nur noch in sehr selten Fällen (z.B. Tochterunehmen, die eigenständig die SSL-Zertifikate verwalten) oder bei Trennung nach Funktionaltität (z.B. Serverauthentifizierung, Signierung, Verschlüsselung) und Betriebsteams.@Lochkartenstanzer
Aber wie schon oben geschrieben, ist es davon abhängig, wie sicher das ganze sein soll. Üblicherweise ist die CA auf einem offline-System und wird nur hervorgeholt, um subCAs, Server, o.ä zu signieren.
Bestes Beispiel ist die Aktualisierung der Sperrlisten der Root-CA. Diese haben grundsätzlich eine Gültigskeitszeitraum und müssen daher wiederkehrend alle x Monate / 1x Jahr erzeugt und kopiert werden.Gruß,
Dani
@SeaStorm
Wenn man die Sicherheit betrachtet und es genau nimmt, dann muss man halt ein paar Dinge beachten und umsetzen. Ist aber auch alles kein Hexenwerk. Maximale Tiefe an CAs einstellen, CRL Pfad redundant bereitstellen, Zugriffe auf die Templates streng limitieren usw. Aber dafür gibt's ja ein glück Bestpractices. Und ein wirklicher Aufwand ist das ja nun wirklich nicht.
Wobei der Schwierigkeit eher beim sicheren, laufenden Betrieb liegt als bei einer Installation. Denn hinterher kurz mal was ändern ist meist mit großen Auswirkungen zu rechnen. Mit dem Sub-CA Zertifikat wird eine neue, Zusätzliche Sub-CA erstellt. DIESE erstellt dann die Client und User-Zertifikate.
Eine SubCA von einer SubCA macht man meines Wissens nach nur noch in sehr selten Fällen (z.B. Tochterunehmen, die eigenständig die SSL-Zertifikate verwalten) oder bei Trennung nach Funktionaltität (z.B. Serverauthentifizierung, Signierung, Verschlüsselung) und Betriebsteams.
Dann sage ich mal artig vielen Dank für die Vorschläge und Tipps.
Ich werde am Wochenende mal einen meiner Pi's aus der Bastelkiste als CA reaktivieren und ggf. als SubCA zuhause eine VM aufziehen. Aber erstmal gibt es einiges zu lesen zu dem Thema...bildet ja bekanntlich
Allen ein schönes Wochenende.
Gruß NV
Ich werde am Wochenende mal einen meiner Pi's aus der Bastelkiste als CA reaktivieren und ggf. als SubCA zuhause eine VM aufziehen. Aber erstmal gibt es einiges zu lesen zu dem Thema...bildet ja bekanntlich
Allen ein schönes Wochenende.
Gruß NV
@SeaStorm
Gruß,
Dani
Ich spreche ja nur von einer SubCA unter der Root.
Dann hast du dich - für mich - nicht deutlich genug ausgedrückt. Maximale Tiefe an CAs einstellen, CRL Pfad redundant bereitstellen, Zugriffe auf die Templates streng limitieren usw. Aber dafür gibt's ja ein glück Bestpractices.
Das ist das Minimum der Basics. Weitere wären: Laufzeit von Zertifizierungstelle bzw. Nutzerzertifikaten, Schlüssellängen und Algorithmen, Speicherort von Sperrlisten und CA-Zertifikate sowie dessen Erreichbarkeit (intern und evtl. extern), Online Responder (Ja/Nein, Schlüsselarchivierung (Ja/Nein), Umgang mit privaten Schlüssel, Backup & Recovery und Notfallsignatur für Sperrlisten.Gruß,
Dani
Jetzt hat der TO oben geschrieben, dass er mit dem Zertifikat auch die Startseite des Gäste-WLAN bestücken will. Das Zertifikat vorher zu verteilen ist dann doch kaum möglich bzw unpraktisch. Wäre hier nicht ein Zertifikat besser, das die Browser bereits akzeptieren, also Letsencrypt?
Moin,
Stöhn....langsam! Erst fahren lernen, dann VW Käfer, Opel und Mercedes in dieser Reihenfolge.
Hab eben mal zuhause versucht, eine Quick-and-Dirty-Root-CA zu erstellen. Hab dazu ein CentOS auf einem Hyper-V Host installiert und darauf XCA von Christian Hohnstädt (Homepage) installiert. Hier dann mein erster Versuch:
Ich vermute mal, das ich nun auf etwa die gleiche Art die Sub-CA auf einer separaten Maschine erstelle und dort das Zertifikat der Root-CA importiere? Mit dem Zertifikat der Root-CA unterschreibe ich dann das Zertifikat der SUB-CA?
Gruß NV
Maximale Tiefe an CAs einstellen, CRL Pfad redundant bereitstellen, Zugriffe auf die Templates streng limitieren usw. Aber dafür gibt's ja ein glück Bestpractices.
Das ist das Minimum der Basics. Weitere wären: Laufzeit von Zertifizierungstelle bzw. Nutzerzertifikaten, Schlüssellängen und Algorithmen, Speicherort von Sperrlisten und CA-Zertifikate sowie dessen Erreichbarkeit (intern und evtl. extern), Online Responder (Ja/Nein, Schlüsselarchivierung (Ja/Nein), Umgang mit privaten Schlüssel, Backup & Recovery und Notfallsignatur für Sperrlisten.Stöhn....langsam!
Erst fahren lernen, dann VW Käfer, Opel und Mercedes in dieser Reihenfolge.Hab eben mal zuhause versucht, eine Quick-and-Dirty-Root-CA zu erstellen. Hab dazu ein CentOS auf einem Hyper-V Host installiert und darauf XCA von Christian Hohnstädt (Homepage) installiert. Hier dann mein erster Versuch:
Ich vermute mal, das ich nun auf etwa die gleiche Art die Sub-CA auf einer separaten Maschine erstelle und dort das Zertifikat der Root-CA importiere? Mit dem Zertifikat der Root-CA unterschreibe ich dann das Zertifikat der SUB-CA?
Gruß NV
Guten Morgen,
hier ein kleines Update. Ich habe mir mit dem Tool XCA von Christian Hohnstädt (Homepage) eine eigene kleine CA gebaut. Das Tool kann in einer Portable-Version lauffähig auf einen USB-Stick gezogen werden und benötigt unter Windows keine Installation. Also sozusagen eine "CA to go".
Ich bin in weiten Teilen der Anleitung von Stephan Klein auf klein-gedruckt.de gefolgt.
Root-CA und Sub-CA befinden sich aktuell auf demselben USB-Stick. Hier hatte ich noch keine Zeit, das ganze zu trennen. Die Datenbank ist durch ein ausreichendes Passwort geschützt. Die Passwörter für die privaten Schlüssel der Zertifikate für die Root-CA und Sub-CA habe ich ausgedruckt und natürlich nicht auf dem Stick gespeichert. Die Zertifikate der beiden CAs lagern auf einem separaten USB-Stick.
Die beiden Stammzertifikate habe ich als pkcs7 exportiert und per GPO an die Clients verteilt. Wenn ich für meine ca. 1 Dutzend Geräte nun ein Zertifikat benötige, erstelle ich auf dem Stick ein Geräte-Zertifikat, exportiere es und installiere es auf dem Gerät. Anschließend kommt der Stick wieder in den Tresor und die Passwörter der privaten Keys in die Schublade. Im Zertifikat habe ich die lokale Adresse https://SubCA/CRL/ eingetragen. Dort liegen dann die Rückruflisten auf unserem NAS.
Das Ganze funktioniert so weit eigentlich wunderbar. Der Edge und Internet Explorer akzeptieren das Zertifikat. Lediglich bei Firefox und Chrome (ist nur auf meinem Management-Rechner) meckern die Browser. Hier muss ich noch etwas Handarbeit anlegen.
Gruß NV
hier ein kleines Update. Ich habe mir mit dem Tool XCA von Christian Hohnstädt (Homepage) eine eigene kleine CA gebaut. Das Tool kann in einer Portable-Version lauffähig auf einen USB-Stick gezogen werden und benötigt unter Windows keine Installation. Also sozusagen eine "CA to go".
Ich bin in weiten Teilen der Anleitung von Stephan Klein auf klein-gedruckt.de gefolgt.
Root-CA und Sub-CA befinden sich aktuell auf demselben USB-Stick. Hier hatte ich noch keine Zeit, das ganze zu trennen. Die Datenbank ist durch ein ausreichendes Passwort geschützt. Die Passwörter für die privaten Schlüssel der Zertifikate für die Root-CA und Sub-CA habe ich ausgedruckt und natürlich nicht auf dem Stick gespeichert. Die Zertifikate der beiden CAs lagern auf einem separaten USB-Stick.
Die beiden Stammzertifikate habe ich als pkcs7 exportiert und per GPO an die Clients verteilt. Wenn ich für meine ca. 1 Dutzend Geräte nun ein Zertifikat benötige, erstelle ich auf dem Stick ein Geräte-Zertifikat, exportiere es und installiere es auf dem Gerät. Anschließend kommt der Stick wieder in den Tresor und die Passwörter der privaten Keys in die Schublade. Im Zertifikat habe ich die lokale Adresse https://SubCA/CRL/ eingetragen. Dort liegen dann die Rückruflisten auf unserem NAS.
Das Ganze funktioniert so weit eigentlich wunderbar. Der Edge und Internet Explorer akzeptieren das Zertifikat. Lediglich bei Firefox und Chrome (ist nur auf meinem Management-Rechner) meckern die Browser. Hier muss ich noch etwas Handarbeit anlegen.
Gruß NV
Guten Morgen,
wieder ein kleines Update zu meiner Baustelle "Eigene CA". Wie oben beschrieben, werden meine selbst erstellten Geräte-Zertifikate anstandslos von Edge und Internet Explorer akzeptiert. Firefox verwendet seinen eigenen Zertifikatspeicher und meckert deshalb.
Hier habe ich die Mozilla admx-templates installiert und eine entsprechende GPO erstellt. Die Templates gibt es
bei github. Aber auch wenn die Policy greift und Firefox den Windows-Zertifikatspeicher verwendet, erscheint trotzdem eine Warnung. Eigenartig!
Chrome verwendet wohl den Windows-Zertifikatspeicher, meckert aber trotzdem. Ziemlich zickig, aber hat wohl sicherheitstechnisch sicher seinen tieferen Sinn.
Die Lösung für beide Browser brachte mir dieser Artikel:
Heise - Chrome blockt Zertifikate mit CommonName
Also bin ich der Sache nachgegangen und habe auf meiner "CA to go" ein neues Geräte-Zertifikat für einen Drucker erstellt. Hierbei habe ich das Feld CommonName leer gelassen und zwei Felder als "Subject Alternative Name" mit dem FQDN und der IP des Gerätes angelegt.
Nachdem ich das neu erstellte Zertifikat in den Drucker importiert habe, fliegt das Ganze nun auch bei Firefox und Chrome.
Gruß NV
wieder ein kleines Update zu meiner Baustelle "Eigene CA". Wie oben beschrieben, werden meine selbst erstellten Geräte-Zertifikate anstandslos von Edge und Internet Explorer akzeptiert. Firefox verwendet seinen eigenen Zertifikatspeicher und meckert deshalb.
Hier habe ich die Mozilla admx-templates installiert und eine entsprechende GPO erstellt. Die Templates gibt es
bei github. Aber auch wenn die Policy greift und Firefox den Windows-Zertifikatspeicher verwendet, erscheint trotzdem eine Warnung. Eigenartig!
Chrome verwendet wohl den Windows-Zertifikatspeicher, meckert aber trotzdem. Ziemlich zickig, aber hat wohl sicherheitstechnisch sicher seinen tieferen Sinn.
Die Lösung für beide Browser brachte mir dieser Artikel:
Heise - Chrome blockt Zertifikate mit CommonName
Also bin ich der Sache nachgegangen und habe auf meiner "CA to go" ein neues Geräte-Zertifikat für einen Drucker erstellt. Hierbei habe ich das Feld CommonName leer gelassen und zwei Felder als "Subject Alternative Name" mit dem FQDN und der IP des Gerätes angelegt.
Nachdem ich das neu erstellte Zertifikat in den Drucker importiert habe, fliegt das Ganze nun auch bei Firefox und Chrome.
Gruß NV
