Private CA zum System-Truststore hinzufügen: RHEL-Familie und Debian/Ubuntu

Ziel

Ein privates oder internes CA-Zertifikat soll systemweit als vertrauenswürdig gelten, und zwar für OpenSSL, curl und weitere Bibliotheken, die den Truststore des Betriebssystems lesen. Das Vorgehen gilt für Linux der RHEL-Familie ebenso wie für die Debian-Familie.

Voraussetzungen

Root-Rechte; das CA-Zertifikat im PEM-Format (Anchors der RHEL-Familie akzeptieren auch DER); das Paket ca-certificates ist installiert (Debian/Ubuntu) bzw. das Paket ca-certificates, das update-ca-trust bereitstellt (RHEL, Fedora und Derivate wie Rocky/Alma, ab RHEL 7).

Schritte

RHEL-Familie:

1. Das CA-Zertifikat (PEM oder DER; Dateiname und Endung spielen hier keine Rolle) nach /etc/pki/ca-trust/source/anchors/ kopieren. Nicht in das übergeordnete Verzeichnis /etc/pki/ca-trust/source/ legen: Einfache Zertifikate werden dort als nicht vertrauenswürdig behandelt.
2. update-ca-trust extract als root ausführen (update-ca-trust ohne Argumente bewirkt dasselbe). Der Befehl liest das Anchors-Verzeichnis sowie die Standardvorgaben des Herstellers und erzeugt die zusammengeführten Dateien unter /etc/pki/ca-trust/extracted/ neu (PEM-Bundles, einen Java-Keystore); NSS-basierte Anwendungen lesen dieselben Quellen über das Modul p11-kit-trust.
3. Nicht interaktiv: Der Befehl stellt keine Rückfragen und eignet sich daher für unbeaufsichtigte Provisionierungsskripte.

Debian/Ubuntu:

1. Das CA-Zertifikat nach /usr/local/share/ca-certificates/ kopieren (Unterverzeichnisse sind erlaubt). Die Datei muss auf .crt enden und muss im PEM-Format (BEGIN CERTIFICATE) vorliegen: update-ca-certificates berücksichtigt dort nur .crt-Dateien, und eine in .crt umbenannte DER-Datei wird kein brauchbarer Bundle-Eintrag. Zuvor mit openssl x509 -inform der konvertieren.
2. update-ca-certificates als root ausführen. Der Befehl aktualisiert die Hash-Links in /etc/ssl/certs, erzeugt /etc/ssl/certs/ca-certificates.crt neu und führt anschliessend die Hooks in /etc/ca-certificates/update.d/ aus.
3. Bei unbeaufsichtigten Installationen hat DEBIAN_FRONTEND=noninteractive hier keine Wirkung, da das Werkzeug selbst nicht interaktiv ist; es ist nur für den umgebenden Schritt apt-get install ca-certificates relevant, falls das Paket fehlt.

Erwartetes Ergebnis

openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt mycert.pem (Debian) bzw. openssl verify -CAfile /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem mycert.pem (RHEL-Familie; ältere Releases stellen es auch unter dem Legacy-Pfad /etc/pki/tls/certs/ca-bundle.crt bereit) meldet OK für ein Zertifikat, das auf die neue CA zurückgeht. In der RHEL-Familie bestätigt trust list | grep -i "<CA common name>" (p11-kit), dass der Anchor registriert wurde; unter Debian/Ubuntu gibt es den Befehl trust nur, wenn das Paket p11-kit installiert ist.

Grenzen und Prüfbasis

Eine .pem-Datei im falschen Verzeichnis oder eine Debian-Datei ohne die Endung .crt wird von beiden Werkzeugen ohne Fehlermeldung ignoriert; es bleibt lediglich eine Zertifikatskette, die sich weiterhin nicht verifizieren lässt. Von der Distribution paketiertes OpenJDK liest in der Regel einen Keystore, der aus demselben Store erzeugt wird (/etc/pki/java/cacerts in der RHEL-Familie; /etc/ssl/certs/java/cacerts über den Hook ca-certificates-java unter Debian/Ubuntu). Ein aus einem Tarball entpacktes Hersteller-JDK und ein per pip installiertes certifi führen dagegen eigene Stores. Prozesse, die das Bundle bereits geladen haben, behalten den alten Stand bis zum Neustart. Zum Entfernen einer CA die Datei aus dem Anchors-Verzeichnis bzw. aus /usr/local/share/ca-certificates löschen und denselben Befehl erneut ausführen (unter Debian baut update-ca-certificates --fresh die Links von Grund auf neu auf, falls ein veralteter Link bestehen bleibt).