zunächst mal vielen Dank für die deine Arbeit und die Umsetzung des Skripts. Wenn ich das Skript richtig gelesen habe, werden durch dieses Skript alle Zertifikate, also auch die CA, neu generiert. Kannst du evtl. noch Schalter einbauen, mit denen man auswählen kann, welche Zertifikate (z.B. nur Serverzertifikat) erneuert werden sollen?
noch ein Thema: In den Zertifikatserweiterungen unter /etc/linuxmuster/ssl/server_cert_ext.cnf fehlt die Erweiterung der alternativen Namen (z.B. subjectAltName = IP:10.0.0.1, DNS:server.linuxmuster.lan, DNS:server).
Auch diese Datei wurde bei linuxmuster-renew-certs nicht neu geschrieben und wieder verwendet. Daher fehlen auch im neu generierten Zertifkat die Erweiterung der Alternaivnamen.
Ich fürchte, wenn man nur das Serverzertifikat erneuert, funktioniert die Authentifizierung und das Kerberoslogin der Firewall gegen den Server nicht mehr.
server.cert.bundle.pem kann ich auch erneuern lassen, Zertifikatserweiterungen baue ich noch ein.
Ich fürchte, wenn man nur das Serverzertifikat erneuert, funktioniert die Authentifizierung und das Kerberoslogin der Firewall gegen den Server nicht mehr.
ich wüsste nicht warum…die signierende CA (und das ist die gegen die die Firewall prüft „Kenne ich die CA, aus der dieses Zertifikat stammt und vertraue ich der? Ja, kenne ich schon.“) bleibt doch auch dann auf Firewall und Server gleich, wenn du nur die Zertifikate erneuerst. Die CA muss man nur dann ersetzen, wenn diese selbst abläuft oder in irgendeiner Form kompromitiert wurde.
Habe ich aus irgendwelchen Gründen die linuxmuster-CA auf meinen Clients eingespielt, z.B. wenn ich keine Warnmeldung beim Aufruf der Webseite der Schulkonsole haben will, muss ich jedesmal nach Durchlauf von linuxmuster-renew-certs auc die CA auf den Clients erneuen. Im Zweifel halt neues Image machen und da die neue CA einspielen.
Das wird insbesondere auch dann dumm, wenn ich den linuxmuster-Server auch als RADIUS-Server mit EAP-TLS-Auth (also zertifikatsbasierte Authentisierung) der Schulclients betreibe. Dann muss ich alle Geräte im MDM zurücksetzen, weil die Clients dann sagen „Meeep!! Die CA des Servers kenn ich aber nicht! Mit dem mag ich mich nicht verbinden!“ Heißt, du muss hier neue Client-Zertifikate machen, diese und das neue CA-Zert im MDM einspielen und die Geräte neu ausrollen.
Thema RADIUS: Ein weiterer Vorteil des Splittens wäre, dass man unterschiedliche Laufzeiten der Zertifikate haben könnte. Einige mobile Edgeräte (wieder die berühmten iPads) akzeptieren z.B. keine Server-Zertifikate deren Gültigkeit mehr als 730 Tage beträgt. Mit dem Schalter könnte man das dann selbst staffeln (CA 10 Jahre Gültig, Server- + Firewall-Zert 2 Jahre gültig). So könnte man über die gleiche CA Server- bzw. Firewall-Zertifikat viermal erneuern. Erst dann ist auch die CA tot und man muss alles neu machen.
Wenn du der Sache jetzt noch die Krone aufsetzen willst, passt du dein Skript so an, das aus der Devices.csv auch automatisch Client-Zertifikate generiert werden, die man bei Bedarf z.B. über die Schulkonsole als pfx exportieren kann (Obacht hierbei, der Export sollte im Legacy-Format vorgenommen werden. Per Default exportiert openssl die Zertifikate in einem Format, welches von einigen (leider auch wieder die berühmten ipads) mobilen Endgeräten nicht akzeptiert wird).
Meine Tests haben ergeben, dass wenn ich nur die Server-Zertifikate erneuere, die CA und die OPNsense Zertifikate unverändert lasse, ich einen SSL-Fehler auf der Firewall bekomme, wenn ich die Authentifzierung gegen den AD teste:
The following input errors were detected:
Authentication failed.
error: error:0A000086:SSL routines::certificate verify failed (unable to get local issuer certificate)
ldap_error: Can't contact LDAP server