eigentlich bin ich davon ausgegangen, dass sich der UCS ein Zertifikat von der internen AD-CA selbst holen kann - weil das nicht geklappt hat, hab ich den “normalen” Weg für Linux Server gewählt und hab das ganze zuerst mit unserem internen Wildcard Zertifikat versucht. Das scheitert aber wohl schon daran, dass ich das Zertifikat unserer CA nicht “integriert” bekomme bzw. als Vertrauenswürdig deklarieren kann.
Der Proxmox-Server und auch die OMV die hier noch im Netzwerk herumdümpeln, haben das gleiche Zertifikat relativ problemlos akzeptiert.
Schlussendlich hab ich mich jetzt allerdings so oft im Kreis gedreht und die Zertifikate so oft hin und her Konvertiert, dass ich den Überblick verloren habe:
Läuft im Hintergrund ganz normal OpenSSL, was Zertifikate im D64-PEM erwatet?
Gibts für den UCS sscep?
Eine etwas genauere Beschreibung im Wiki (oder auch im Forum) wären tatsächlich Willkommen…
Edit: Irgendwo hab ich mich wohl verrant gehabt. Nach dem ich das Zertifikat der AD-CA noch mal exportiert und ordentlich auf den UCS Kopiert hab, hat ein “dpkg-reconfiguer ca-certificates” geholfen.
Ich meinte: Ja, wenn du einen UCS master hast, siehst du die UCS-eigene CA unter /etc/univention/ssl, das basiert auch alles auf OpenSSL und etwas wrapping
Meinst du generellen support für SCEP (Secure Certificate Enrollment Protocol) oder github.com/certnanny/sscep? Generell habe ich bei Linux einen relativ dünnen SCEP support vorgefunden. Dafür gibts exzellenten ACME-Support nur kann das die Windows CA nicht.
Ich denke dein use case ist relativ selten in der Univention-Welt, darum ist es nicht näher dokumentiert. Es wäre ohne gröberes auch nicht möglich, die UCS-CA als intermediate CA einer internen (offline) root CA zu haben, ich habe mich mal darum getan, aber ich habe es dann verworfen, ich hätte einiges verbiegen müssen.
Kurze Frage, du schreibst “ordentlich auf den UCS kopiert” - meinst du damit, dass du das CA-Zertifikat unter /etc/ssl/certs abgelegt hast? Viel Software unter Linux sucht sich dort die CA-Zertifikate, aber es gibt (wie auch auf Windows) genug Software, die eigene Cert-Stores hat, wie z.B. Java. dafür gibts das Paket ca-certificates-java.
Ja - ich hab die aber unter “etc/ssl” kopiert, das hat dann auch funktioniert.
So schön ACME-Support ist, das ist im Corporate-Umfeld aber sicherlich nicht der ideale Weg. Wir haben z.B. eine einzige Homepage die “öffentlich” ist, die restlichen 6 oder 7 sind intern und werden nur per VPN oder DA erreicht.
Ja - das hab ich auch festgestellt und auch sehr schnell wieder verworfen. Aber da wir dann noch ein paar andere Linux Server haben, die auch auf Debian basieren und denen ich unser Wildcard Domänenzertifikat schon verpasst hab, dachte ich das ist bei UCS auch kein Problem.
Jain - in /etc/ssl/certs hat das Script nichts gefunden. Dann hab ich es in den Mozilla CA-Store geworfen, wohin auch die ganzen Symlinks in /etc/ssl/certs zeigen - da hat es dann funktioniert.
Wenn ich ehrlich bin, hab ich den UCS aber wieder rausgeworfen. Damit die Nextcloud funktioniert, hätte ich noch mal einiges mehr an Arbeit reinstecken müssen, dann wäre es nur Version 16 gewesen die das Remote-Löschen von Daten noch nicht unterstützt und warum auch immer haben die trusted domains nicht gestimmt. Da hab ich Nextcloud per Script auf einem normalen Debian schneller und einfacher eingerichtet…
Der Ansatz von UCS ist absolut genial und erleichtert “einzel-Admins” wie mir das Leben. Leider fehlts im Detail an der Doku und das Zusammenspiel zwischen bestehender Microsoft Umgebung ist noch recht rudimentär, wie ich finde.
