9
Migration von Windows-AD-CS zur (AD-integrierten) Linux-PKI
Hallochen Gemeinde,
im gegebenen Active Directory hat Samba seit einiger Zeit die Führung (FSO-Master + 2.DC) übernommen. Ein verbliebenes Relikt ist ein Windows-DC, auf dem die interne Zertifizierungsstelle werkelt. Um den Windows-DC plattmachen zu können, muss zuerst die AD-CS-Rolle und somit die Zertifizierungsstelle entfernt werden. Künftig soll zudem von One-Tier-PKI auf eine Two-Tier-PKI gewechselt werden. Dass dabei die Root-CA auf einen Server/VM kommt, der nur diese Rolle spielt und nur im Bedarfsfall dafür hochgefahren wird sowie keine AD-Member ist, ist klar. Auch wird die Issue-CA wohl auf keinem der Samba-DC's installiert werden, sondern auf einem Memberserver.
Die Frage für mich ist, wie das als Best Practice unter Linux realisiert werden sollte. Im Internet steht bei Fragen der PKI erdrückend Windows im Vordergrund. Auch sind Beiträge zur Migration von Samba nach Windows zu finden; umgekehrt habe ich nicht wirklich etwas gefunden.
Die Wahl der Software für die CA-Aufgabe (Root / Issue) dürfte wohl OpenSSL sein, oder? Welche sinnvollen Alternativen gäbe es?
Weiters erscheint es mir sinnvoll, wenn die neue PKI-Struktur (Issue-CA) weiterhin ins Active Directory integriert ist. Was spräche dafür und was gegen eine solche Integration?
Können das Zertifikat und vielleicht sogar die Daten der bisherigen Root-CA importiert werden? Falls nein, müssten wohl zunächst alle ausgestellten Zertifikate ihr vorzeitiges Ende finden und die zugehörige Sperrliste propagiert werden, um die bisherige Root-CA entfernen zu können, oder? Ein gleitender Übergang wäre mir natürlich lieber: neue Zertifikate werden sukzessive mit der neuen Issue-CA ausgestellt. Aber wie ist das dann mit der Sperrliste zur bisherigen Root-CA?
Vielen Dank für Euren Input im Voraus und viele Grüße
HansDampf06
im gegebenen Active Directory hat Samba seit einiger Zeit die Führung (FSO-Master + 2.DC) übernommen. Ein verbliebenes Relikt ist ein Windows-DC, auf dem die interne Zertifizierungsstelle werkelt. Um den Windows-DC plattmachen zu können, muss zuerst die AD-CS-Rolle und somit die Zertifizierungsstelle entfernt werden. Künftig soll zudem von One-Tier-PKI auf eine Two-Tier-PKI gewechselt werden. Dass dabei die Root-CA auf einen Server/VM kommt, der nur diese Rolle spielt und nur im Bedarfsfall dafür hochgefahren wird sowie keine AD-Member ist, ist klar. Auch wird die Issue-CA wohl auf keinem der Samba-DC's installiert werden, sondern auf einem Memberserver.
Die Frage für mich ist, wie das als Best Practice unter Linux realisiert werden sollte. Im Internet steht bei Fragen der PKI erdrückend Windows im Vordergrund. Auch sind Beiträge zur Migration von Samba nach Windows zu finden; umgekehrt habe ich nicht wirklich etwas gefunden.
Die Wahl der Software für die CA-Aufgabe (Root / Issue) dürfte wohl OpenSSL sein, oder? Welche sinnvollen Alternativen gäbe es?
Weiters erscheint es mir sinnvoll, wenn die neue PKI-Struktur (Issue-CA) weiterhin ins Active Directory integriert ist. Was spräche dafür und was gegen eine solche Integration?
Können das Zertifikat und vielleicht sogar die Daten der bisherigen Root-CA importiert werden? Falls nein, müssten wohl zunächst alle ausgestellten Zertifikate ihr vorzeitiges Ende finden und die zugehörige Sperrliste propagiert werden, um die bisherige Root-CA entfernen zu können, oder? Ein gleitender Übergang wäre mir natürlich lieber: neue Zertifikate werden sukzessive mit der neuen Issue-CA ausgestellt. Aber wie ist das dann mit der Sperrliste zur bisherigen Root-CA?
Vielen Dank für Euren Input im Voraus und viele Grüße
HansDampf06
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: 3868040345
Url: https://administrator.de/contentid/3868040345
Ausgedruckt am: 21.11.2024 um 16:11 Uhr
9 Kommentare
Neuester Kommentar
Huhu,
wow, ich sag, dir je nachdem ob Ihr es ernst meint mit einer PKI oder nur Zertifikat aussstellen wollt, damit der Browser nicht meckert ;)
Alternativen:
Dogtag, wird verwendet wenn du RHEL Identity Management/freeIPA benutzt
https://www.dogtagpki.org/wiki/PKI_Main_Page
ejbca
https://www.ejbca.org/
Ob alle Deine Anforderungen damit erfüllt werden kann ich ausm Kopf nicht sagen...
Die "root" CA würde ich auch mit openssl erstellen, das ist nen file aufn USB-Key/HSM mit dem du regelmäßig CRL'S erstellen musst
Ich gehe davon aus, du hast das Environment geerbt und es ist historisch gewachsen ;)
Zuerst, sammel alle Anforderungen
CRL Distribution Points
Certificate Enrollment
permission/templates
Dann würd ich das Produkt nach den Anforderungen wählen
Am besten du schaust nach, wie die CA derzeit konfiguriert ist / wie die CA verwendet wird und versuchst das mit einer anderen Software nachzustellen
Update,
solltest du doch bei der Windows (issue) CA bleiben, gibt es ein nettes Plugin für certmonger, mit dem man Autoenrollment bei Linux Hosts hinbekommt
https://github.com/openSUSE/cepces
Wurde von mir schon erfolgreich getestet ;)
Vorteil, basiert Komplett auf Kerberos
wow, ich sag, dir je nachdem ob Ihr es ernst meint mit einer PKI oder nur Zertifikat aussstellen wollt, damit der Browser nicht meckert ;)
Alternativen:
Dogtag, wird verwendet wenn du RHEL Identity Management/freeIPA benutzt
https://www.dogtagpki.org/wiki/PKI_Main_Page
ejbca
https://www.ejbca.org/
Ob alle Deine Anforderungen damit erfüllt werden kann ich ausm Kopf nicht sagen...
Die "root" CA würde ich auch mit openssl erstellen, das ist nen file aufn USB-Key/HSM mit dem du regelmäßig CRL'S erstellen musst
Ich gehe davon aus, du hast das Environment geerbt und es ist historisch gewachsen ;)
Zuerst, sammel alle Anforderungen
CRL Distribution Points
Certificate Enrollment
permission/templates
Dann würd ich das Produkt nach den Anforderungen wählen
Am besten du schaust nach, wie die CA derzeit konfiguriert ist / wie die CA verwendet wird und versuchst das mit einer anderen Software nachzustellen
Update,
solltest du doch bei der Windows (issue) CA bleiben, gibt es ein nettes Plugin für certmonger, mit dem man Autoenrollment bei Linux Hosts hinbekommt
https://github.com/openSUSE/cepces
Wurde von mir schon erfolgreich getestet ;)
Vorteil, basiert Komplett auf Kerberos
Wir haben das Thema auch auf der Agende und sehen uns allein wegen dem Umfang der PKI sehr eingeengt.
Unser HR sucht unter anderen Studenten, die das Thema wie eine Simulation der Realität bei uns fahren. Leider ohne Erfolg, jeder Kandidat der den Umfang sieht, bekommt kalte Füße.
Was wir noch umfangreich testen wollen ist: https://www.openxpki.org/
Sieht erstmal ganz gut aus, leider keiner Zeit und 14 Tage allein im Büro um eine Bewertungsgrundlage zu erarbeiten.
Kollegen in Brasilien haben einen Windows Client begonnen zu bauen, der über einen ACME-Client-Fork
Zertifikate in die Windows PKI kippt. Leider finden wir auch niemand im Moment, der sich über einen Test dazu Gedanken machen kann.
Ich lese hier mal aufmerksam mit.
Unser HR sucht unter anderen Studenten, die das Thema wie eine Simulation der Realität bei uns fahren. Leider ohne Erfolg, jeder Kandidat der den Umfang sieht, bekommt kalte Füße.
Was wir noch umfangreich testen wollen ist: https://www.openxpki.org/
Sieht erstmal ganz gut aus, leider keiner Zeit und 14 Tage allein im Büro um eine Bewertungsgrundlage zu erarbeiten.
Kollegen in Brasilien haben einen Windows Client begonnen zu bauen, der über einen ACME-Client-Fork
Zertifikate in die Windows PKI kippt. Leider finden wir auch niemand im Moment, der sich über einen Test dazu Gedanken machen kann.
Ich lese hier mal aufmerksam mit.
1
Zitat von @dodo30:
... je nachdem ob Ihr es ernst meint mit einer PKI oder nur Zertifikat aussstellen wollt ...
Es ist in jedem Fall ernst gemeint. Die Ausstellung interner Zertifikate ist natürlich das Mindeste, wobei es dabei um die üblichen Erfordernisse innerhalb eines Active Directorys geht. Zudem soll es für künftige Entwicklungen und Erweiterungen offen sein ...... je nachdem ob Ihr es ernst meint mit einer PKI oder nur Zertifikat aussstellen wollt ...
... wenn du RHEL
Nein, hier sind Ubuntu (18.04 / 20.04) und Debian (11) im Einsatz, wobei höchstwahrscheinlich die Ubuntu-Kisten sukzessive auf Debian umgestellt werden, wenn die LTS-Periode abläuft, sofern es keinen früheren Anlass gibt.Alternativen:
Dogtag, ...
ejbca
Das schaue ich mir in jedem Fall genauer an, besten Dank für diese Hinweise.Dogtag, ...
ejbca
Die "root" CA würde ich auch mit openssl erstellen, das ist nen file aufn USB-Key/HSM mit dem du regelmäßig CRL'S erstellen musst.
Meine Überlegung ist Folgende:Ich lege für die Root-CA eine VM (kein AD-Member; am besten gleich unter QEMU/KVM, weil künftig auch Hyper-V verschwinden soll) an, die auf das Nötigste für die Root-CA begrenzt ist. Die virtuelle HDD (ca. 5GB dürften völlig ausreichend sein) für diese VM wird in einen VeraCrypt-Container gepackt, sodass die VM relativ leicht zugänglich ist, um sie zu starten. Ist die VM heruntergefahren, bietet der nicht gemountete VC-Container eine optimale Sicherheit vor Fremdzugriff. QEMU/KVM und VeraCrypt sind hier betriebserprobt.
Die Aufgabe der Issue-CA könnte ein vorhandener AD-Member-Server übernehmen, der ausschließlich administrativen Aufgaben dient und auf dem OpenSSL bereits installiert ist.
Ich gehe davon aus, ... es ist historisch gewachsen
So ist es. 
Zuerst, sammel alle Anforderungen
...
Dann würd ich das Produkt nach den Anforderungen wählen
Am besten du schaust nach, wie die CA derzeit konfiguriert ist / wie die CA verwendet wird und versuchst das mit einer anderen Software nachzustellen
Derzeit ist es eine Standardkonfiguration ohne Besonderheiten. Das ist gleichfalls historisch bedingt....
Dann würd ich das Produkt nach den Anforderungen wählen
Am besten du schaust nach, wie die CA derzeit konfiguriert ist / wie die CA verwendet wird und versuchst das mit einer anderen Software nachzustellen
solltest du doch bei der Windows (issue) CA bleiben,
Das schließe ich eher aus, weil künftig keine Windows-Server mehr eingesetzt werden sollen, sofern es dafür keine zwingenden Gründe gibt - vorerst sind solche nicht ersichtlich.gibt es ein nettes Plugin für certmonger, mit dem man Autoenrollment bei Linux Hosts hinbekommt
Gleichwohl ist das ein interessanter Hinweis, dem ich nachgehen werden. Vielleicht führt es mich ja zu neuen Erkenntnissen, die ein Überdenken des vorstehenden Punktes in den Raum stellen.Vorteil, basiert Komplett auf Kerberos
Aufgrund dessen, dass das Active Directory einen Windows-Ursprung hat, wird hier ohnehin auf Kerberos gesetzt, z.B. wegen SQL Server for Linux. Insoweit ist das ebenso betriebserprobt und deswegen soll sich daran nichts ändern.Hier liegt zugleich ein für mich ganz wichtiger Punkt: Die (historische) Windows-Prägung des Active Directory soll erhalten werden, um jederzeit bei (zwingendem) Bedarf die Option zu behalten, wieder einen Windows-DC aufnehmen zu können. Deswegen soll der aktuelle Windows-DC "lediglich" herabgestuft und eingemottet werden - sprich: die VM kann jederzeit gebootet werden.
Viele Grüße
HansDampf06
Zitat von @2423392070:
Wir haben das Thema auch auf der Agende und sehen uns allein wegen dem Umfang der PKI sehr eingeengt.
Unser HR sucht unter anderen Studenten, die das Thema wie eine Simulation der Realität bei uns fahren. Leider ohne Erfolg, jeder Kandidat der den Umfang sieht, bekommt kalte Füße.
Das dürfte die mageren Ergebnisse meiner Internetrecherche einigermaßen erklären.Wir haben das Thema auch auf der Agende und sehen uns allein wegen dem Umfang der PKI sehr eingeengt.
Unser HR sucht unter anderen Studenten, die das Thema wie eine Simulation der Realität bei uns fahren. Leider ohne Erfolg, jeder Kandidat der den Umfang sieht, bekommt kalte Füße.
Was wir noch umfangreich testen wollen ist: https://www.openxpki.org/
Sieht erstmal ganz gut aus, leider keiner Zeit und 14 Tage allein im Büro um eine Bewertungsgrundlage zu erarbeiten.
Danke für diesen tollen Hinweis. Darauf war ich noch nicht gestoßen. Aber es klingt außerordentlich interessant, weil unter anderem auch die perspektivisch verbleibenden drei Windows-Clients darüber bestens zu versorgen sein werden.Sieht erstmal ganz gut aus, leider keiner Zeit und 14 Tage allein im Büro um eine Bewertungsgrundlage zu erarbeiten.
In jedem Fall habe ich jetzt zusammen mit den Hinweisen von @dodo30 ausreichend Lesestoff ...
Kollegen in Brasilien haben ... begonnen zu bauen ... Leider finden wir auch niemand im Moment ... Ich lese hier mal aufmerksam mit.
Ehrlich gesagt habe ich nicht gedacht, dass ich mit diesem Thema auf ein solch schwieriges Terrain stoßen würde. Davon, dass eine PKI unter Linux und in einem Samba-AD weniger häufig anzutreffen ist, bin ich schon ausgegangen.Das ist wohl der Realität geschuldet: Auch wenn sich über Samba auch Linux-Installationen in ein Active Directory integrieren lassen und Linux-Server statistisch wohl deutlich häufiger als Windows-Server installiert werden, so dürfte es sich zumeist dennoch immer um eine Windows-Domäne handeln. Die Möglichkeit, ein originäres Samba-AD per OpenLDAP etc. aufzusetzen, scheint demgegenüber im produktiven Umfeld nur eine geringe Bedeutung zu haben. Das alles verwundert auch nicht, wenn die absolute Windows-Dominanz und zumeist auch Ausschließlichkeit bei der Hard-/Softwareunterstützung betrachtet wird, was gerade im produktiven Umfeld von existenzieller Bedeutung ist. Die Hürden unter Linux sind teilweise schon außerordentlich erheblich bis nicht überwindbar, wenn ich mir die hiesige sukzessive Umstellung nach Linux ansehe.
Viele Grüße
HansDampf06
PS: Zwei vorhandene Windows-Clients werden perspektivisch schon deshalb erhalten bleiben, weil die Realität keine andere Wahl lässt. Einerseits sind bestimmte Dinge herstellerseits leider nur unter Windows möglich, z.B. grundlegende Administration des vorhandenen Dokumentscanners mangels Treiberunterstützung unter Wine. Andererseits wird über die beiden Windows-Clients sichergestellt, dass die bisher mit Windows-Programmen (z.B. Office) erstellten produktiven Dateien im Zweifel uneingeschränkt zugriffsfähig bleiben. Der dritte Windows-Client wird von einer Person ausschließlich genutzt und dort ist ein Umstieg auf Linux aus einem Blumenstrauß von Gründen derzeit kein Thema.
Unsere Umgebung, von Simulation und Konstruktion, über die Produktion bis hin zur Softwarepflege beim Kunden, nach der Auslieferung, hat mit unzähligen Zertifikaten zu tun. Das Thema ist und den letzten zwei Dekaden massiv gewachsen.
Unsere PKI-Kette ist geschäftskritisch. Wir wollen nicht so enden, wie Bezahlkartenterminalanbieter.
Daher müssen tausende Mitarbeiter über Zertifikatvorlagen sich mit Zertifikaten ausstatten können. Die Administration muss noch unzählige individuelle Möglichkeiten haben.
Unsere Softwareentwicklung hat fast alle Zertifikatthemen als Tooling automatisiert und das auf Basis in Windows.
Wir Administratoren sind noch am flexibelsten. Unsere Coder sind eigentlich für immer in der MS-Welt. Unsere Lieferanten zum Beispiel, die könne teilweise die Zulieferprodukte mit unseren Zertifikaten versehen, die sie sich automatisch auf unseren Servern erstellen.
Webservices, die intern und aus dem öffentlichen Internet erreichbar sein müssen, auch für nicht AD-Member hat uns immer mehr Personal abverlangt.
Zertifikat-VPNs hat eine Abteilung in der IT nach und nach geschaffen und immer mehr Arbeit verursacht, die immer weniger automatisiert werden konnte.
Die IT Security Welle der letzten fünf bis zehn Jahre, die zum Großteil Marketing -Blabla ist, hat sich zu einer Pest entwickelt die schlimmer als Pickel am *rsch ist.
Solang man auf vielen oder fast allen Ebenen für sich alleine ist, ist das Thema relativ einfach zu beherrschen mit und ohne Microsoft.
Leider sind unsere Aufträge mittlerweile so dass eine Produktionslinie hunderte Lieferanten mitbringt. Unsere Zuliefererprodukte kommen aus aller Welt und ein fertiges Produkt von uns enthält hunderte Lieferanten am Ende des Tages. Alle wollen und müssen etwas mit Zertifikaten machen...
Dann hat das Thema ganz schnell einen Generalstab nötig und muss auch generalstabsmäßig gehandhabt werden sonst verliert man Stück für Stück die Kontrolle bzw beschäftigt immer mehr Kollegen damit.
Du kannst dir also mit deiner Idee nicht nur den Tag oder die Woche versauen.
Unsere PKI-Kette ist geschäftskritisch. Wir wollen nicht so enden, wie Bezahlkartenterminalanbieter.
Daher müssen tausende Mitarbeiter über Zertifikatvorlagen sich mit Zertifikaten ausstatten können. Die Administration muss noch unzählige individuelle Möglichkeiten haben.
Unsere Softwareentwicklung hat fast alle Zertifikatthemen als Tooling automatisiert und das auf Basis in Windows.
Wir Administratoren sind noch am flexibelsten. Unsere Coder sind eigentlich für immer in der MS-Welt. Unsere Lieferanten zum Beispiel, die könne teilweise die Zulieferprodukte mit unseren Zertifikaten versehen, die sie sich automatisch auf unseren Servern erstellen.
Webservices, die intern und aus dem öffentlichen Internet erreichbar sein müssen, auch für nicht AD-Member hat uns immer mehr Personal abverlangt.
Zertifikat-VPNs hat eine Abteilung in der IT nach und nach geschaffen und immer mehr Arbeit verursacht, die immer weniger automatisiert werden konnte.
Die IT Security Welle der letzten fünf bis zehn Jahre, die zum Großteil Marketing -Blabla ist, hat sich zu einer Pest entwickelt die schlimmer als Pickel am *rsch ist.
Solang man auf vielen oder fast allen Ebenen für sich alleine ist, ist das Thema relativ einfach zu beherrschen mit und ohne Microsoft.
Leider sind unsere Aufträge mittlerweile so dass eine Produktionslinie hunderte Lieferanten mitbringt. Unsere Zuliefererprodukte kommen aus aller Welt und ein fertiges Produkt von uns enthält hunderte Lieferanten am Ende des Tages. Alle wollen und müssen etwas mit Zertifikaten machen...
Dann hat das Thema ganz schnell einen Generalstab nötig und muss auch generalstabsmäßig gehandhabt werden sonst verliert man Stück für Stück die Kontrolle bzw beschäftigt immer mehr Kollegen damit.
Du kannst dir also mit deiner Idee nicht nur den Tag oder die Woche versauen.
Meine Überlegung ist Folgende:
Ich lege für die Root-CA eine VM (kein AD-Member; am besten gleich unter QEMU/KVM, weil künftig auch Hyper-V verschwinden soll) an, die auf das Nötigste für die Root-CA begrenzt ist. Die virtuelle HDD (ca. 5GB dürften völlig ausreichend sein) für diese VM wird in einen VeraCrypt-Container gepackt, sodass die VM relativ leicht zugänglich ist, um sie zu starten. Ist die VM heruntergefahren, bietet der nicht gemountete VC-Container eine optimale Sicherheit vor Fremdzugriff. QEMU/KVM und VeraCrypt sind hier betriebserprobt.
Die Aufgabe der Issue-CA könnte ein vorhandener AD-Member-Server übernehmen, der ausschließlich administrativen Aufgaben dient und auf dem OpenSSL bereits installiert ist.
Ich lege für die Root-CA eine VM (kein AD-Member; am besten gleich unter QEMU/KVM, weil künftig auch Hyper-V verschwinden soll) an, die auf das Nötigste für die Root-CA begrenzt ist. Die virtuelle HDD (ca. 5GB dürften völlig ausreichend sein) für diese VM wird in einen VeraCrypt-Container gepackt, sodass die VM relativ leicht zugänglich ist, um sie zu starten. Ist die VM heruntergefahren, bietet der nicht gemountete VC-Container eine optimale Sicherheit vor Fremdzugriff. QEMU/KVM und VeraCrypt sind hier betriebserprobt.
Die Aufgabe der Issue-CA könnte ein vorhandener AD-Member-Server übernehmen, der ausschließlich administrativen Aufgaben dient und auf dem OpenSSL bereits installiert ist.
Viele Grüße
HansDampf06
HansDampf06
Ich würde davon absehen, viel zu Komplex
Wenn Budget vorhanden, am besten ein HSM verwenden
wie z.b. sowas
https://www.yubico.com/de/product/yubihsm-2/
Zitat von @2423392070:
Solang man auf vielen oder fast allen Ebenen für sich alleine ist, ist das Thema relativ einfach zu beherrschen mit und ohne Microsoft.
Es ist diese Dimension. Die unzählige Einbeziehung von externen Fremden und dann auch noch geschäftskritisch steht derzeit und wohl auch perspektivisch nicht im Raum.Solang man auf vielen oder fast allen Ebenen für sich alleine ist, ist das Thema relativ einfach zu beherrschen mit und ohne Microsoft.
Dennoch wäre es mir lieb, eine Implementation zu wählen, die im Falle des Falls die Möglichkeit bietet, den gestiegenen Anforderungen relativ schnell und einfach gerecht werden zu können. Ansonsten bestünde die Gefahr, später von vorne Anfang zu müssen. Schließlich weiß heute niemand, wohin die "Wege des Herrn" morgen führen mögen.
Insoweit habe ich bereits einen ersten tieferen Blick auf EJBCA geworfen und muss feststellen, dass mich deren Internetauftritt außerordentlich gut anspricht. Hinzukommt die Plattformunabhängigkeit, was für die Zukunft einen sehr hohen Freiheitsgrad schafft - die Plattformunabhängigkeit ist für mich mittlerweile ein Key-Feature.
Du kannst dir also mit deiner Idee nicht nur den Tag oder die Woche versauen.
Da bin ich relativ gelassen, weil hier kein Umsetzungszwang besteht. Die Zeit, die es braucht, braucht es halt. Viel wichtiger ist, dass eine Entscheidung gut vorbereitet und die konkrete Umsetzung in den Details verstanden ist. Hierbei denke ich gewohnheitsmäßig in langfristigen Dimensionen, so dass mir Beständigkeit wichtiger ist als eine kurzfristige Realisation mit anschließendem Herumärgern.Wie ich gesehen habe, bietet die Dokumentation von EJBCA unter anderem Informationen für eine Migration. Hierbei merkt man durchaus, dass dieses Projekt gemäß seiner Eigendarstellung zu den am längsten am Markt tätigen CA-Software-Projekten gehört. Die Webseite strahlt jedenfalls jede Menge Kompetenz aus und vermittelt den Eindruck, ständig "hart am Wind" der aktuellen Entwicklungen "zu segeln". Also absolut interessant!
Ein erster Seitenblick auf die Webseite von OpenXPKI war hingegen nicht ganz so beeindruckend. Aber ich stehe ja erst am "Anfang" ...
Viele Grüße
HansDampf06
Zitat von @dodo30:
Ich würde davon absehen, viel zu Komplex
Wenn Budget vorhanden, am besten ein HSM verwenden
wie z.b. sowas
https://www.yubico.com/de/product/yubihsm-2/
Das schaue ich mir gewiss noch an.Ich würde davon absehen, viel zu Komplex
Wenn Budget vorhanden, am besten ein HSM verwenden
wie z.b. sowas
https://www.yubico.com/de/product/yubihsm-2/
Wenn sich eine Root-CA am Ende / im Kern in dem Root-Zertifikat und der zugehörigen Sperrliste erschöpft, erscheint die Frage der Root-CA-Servers eher nachrangig, sofern Root-Zertifikat und Sperrliste jederzeit sicher sind, und zwar auch im Kompromittierungsfall. Deswegen scheint OpenXPKI den Standpunkt zu haben, dass eine Root-CA nicht in deren Fokus steht.
Relevanter ist dann schon die Issue-CA. Ob meine vorläufige Überlegung dann noch Bestand haben wird, ist natürlich völlig offen. Jedenfalls habe ich bei EJBCA gesehen, dass sie HSM im Fokus haben, so dass ich mich damit fast zwangsläufig befassen werde. Sobald es dann konkreter wird, werden sich sukzessive die Folgefragen (u.a. Budget) stellen und zu beantworten sein.
Viele Grüße
HansDampf06
Ich denke, die RootCA ist das kleinste Problem bei dem Thema.
Stichwort: Azure Vault
Stichwort: Azure Vault
