Ubuntu CA-Zertifikat hinzufügen - So geht's richtig!

Ein eigenes CA-Zertifikat in Ubuntu sauber zu hinterlegen ist einer dieser Schritte, die in der Praxis viel Frust sparen. Der praktische Kern von ubuntu add ca certificate ist schnell erklärt: Ein internes Stammzertifikat wird so in den Trust Store eingebunden, dass TLS-Verbindungen im System ohne Umwege geprüft werden können. In diesem Artikel zeige ich, wie du das Zertifikat korrekt vorbereitest, importierst und überprüfst, damit interne Dienste, Proxies und Verwaltungsoberflächen nicht an unnötigen Warnungen scheitern.

Wann du ein CA-Zertifikat in Ubuntu wirklich brauchst

Ich greife zu diesem Schritt immer dann, wenn ein Ubuntu-System Zertifikate aus einer internen oder firmeneigenen PKI akzeptieren soll. Das ist typisch bei Reverse Proxies im Intranet, internen APIs, LDAP- oder SMTP-Diensten mit TLS, privaten Paketquellen, Git-Servern, Monitoring-Endpoints oder Proxy-Umgebungen mit eigener Vertrauenskette. Ohne passenden CA-Eintrag sieht Ubuntu zwar ein gültiges Zertifikat, kann es aber nicht bis zu einer vertrauenswürdigen Stelle zurückverfolgen.

Wichtig ist die Unterscheidung: Ein CA-Zertifikat ist nicht dasselbe wie ein Serverzertifikat. Der Trust Store enthält das Vertrauen in eine ausstellende Instanz, nicht in einen einzelnen Host. In sauber aufgebauten Umgebungen importierst du daher die Root-CA oder ein gezielt dafür vorgesehenes Zwischenzertifikat, wenn eure PKI genau so konstruiert ist. Damit steht die Richtung fest, und als Nächstes lohnt sich ein Blick darauf, wie Ubuntu Vertrauen technisch überhaupt verwaltet.

So arbeitet der Trust Store unter Ubuntu

Ubuntu verwendet für systemweite Zertifikatsprüfungen einen zentralen Trust Store. Praktisch bedeutet das: Du legst das CA-Zertifikat in einem lokalen Verzeichnis ab, gibst ihm die richtige Endung und lässt danach die Vertrauenskette neu aufbauen. Die aktuelle Ubuntu-Dokumentation beschreibt genau diesen Ablauf und weist auch darauf hin, dass Anwendungen wie curl und wget davon direkt profitieren.

Für die Praxis sind drei Dinge entscheidend: Format, Ablageort und Aktualisierung. Das Zertifikat muss in PEM vorliegen, die Datei muss als .crt enden, und der Import wird über update-ca-certificates in die systemweite Sammlung übernommen. Genau deshalb scheitern viele Versuche nicht an der PKI selbst, sondern an einem scheinbar kleinen Detail wie dem falschen Dateiformat.

Der entscheidende Punkt ist also nicht nur „Zertifikat kopieren“, sondern das richtige Zertifikat im richtigen Format an der richtigen Stelle ablegen. Genau daraus ergibt sich der nächste Schritt, und der beginnt mit einer sauberen Vorbereitung.

So bereitest du das Zertifikat sauber vor

Bevor ich irgendetwas importiere, prüfe ich zuerst drei Dinge: Ist es wirklich die CA-Datei, ist sie im richtigen Format, und besteht die Kette aus genau den Zertifikaten, die ich im Trust Store sehen will? Wenn die Datei bereits mit BEGIN CERTIFICATE beginnt, ist sie normalerweise direkt nutzbar. Wenn nicht, liegt sie oft als DER-Datei vor und muss konvertiert werden.

Ein häufiger Fehler ist ein Sammelcontainer mit mehreren Zertifikaten in einer Datei. Für den lokalen CA-Import ist das unpraktisch, weil update-ca-certificates ein Zertifikat pro Datei erwartet. Ich halte die Ablage daher bewusst schlicht: eine CA pro Datei, eindeutiger Name, die Endung .crt und keine Mischung aus Root- und Serverzertifikat.

Wenn diese Vorbereitung stimmt, ist der eigentliche Import unspektakulär. Genau das ist gut so, denn bei Zertifikaten ist unspektakulär meistens gleichbedeutend mit zuverlässig.

So importierst du die CA Schritt für Schritt

Im Alltag reicht für den systemweiten Import meist eine kurze Abfolge von Befehlen. Ich formuliere sie bewusst so, dass sie auf einem aktuellen Ubuntu-System ohne Umwege funktionieren und sich leicht in ein internes Runbook übernehmen lassen.

sudo apt-get install -y ca-certificates
sudo cp local-ca.crt /usr/local/share/ca-certificates/
sudo update-ca-certificates

Danach baut Ubuntu den Trust Store neu auf und verknüpft das Zertifikat mit den Systempfaden. Wenn du mehrere eigene CAs verwaltest, lege jede Datei separat ab und achte darauf, dass die Namen eindeutig bleiben. Ich vermeide es bewusst, Zertifikate mitten im Betrieb umzubenennen, weil das spätere Nachvollziehen unnötig erschwert.

Für die Kontrolle direkt nach dem Import lohnt sich ein kurzer Blick in das Zertifikatsverzeichnis:

ls -l /etc/ssl/certs | grep local-ca

Wenn dort eine passende Verknüpfung erscheint, ist das ein gutes Zeichen. In einer sauberen Betriebsdokumentation halte ich zusätzlich fest, woher die CA stammt und welche Systeme sie benötigen. Das erspart später viel Sucharbeit, wenn ein Dienst plötzlich wieder auf Zertifikatsfehler läuft.

So prüfst du den Import ohne Rätselraten

Ich verlasse mich bei Zertifikaten nie nur auf die Meldung „erfolgreich ausgeführt“. Der bessere Test ist immer eine echte Verbindung zu dem Dienst, der die CA braucht. Wenn Ubuntu dem Zertifikat vertraut, sollte ein Aufruf mit curl oder ein TLS-Handshake ohne Warnung funktionieren.

curl -I https://interner-dienst.example
openssl s_client -connect interner-dienst.example:443 -servername interner-dienst.example

Zusätzlich kannst du direkt im Bundle nachsehen, ob das Zertifikat dort gelandet ist. Dafür reicht ein eindeutiger Fingerprint- oder Textausschnitt aus der CA-Datei. Wenn er im Bundle auftaucht, ist der systemweite Import in der Regel korrekt abgeschlossen.

grep -n "Dein eindeutiger Textausschnitt" /etc/ssl/certs/ca-certificates.crt

Wenn der Import technisch passt, aber eine einzelne Anwendung trotzdem meckert, liegt das Problem häufig nicht mehr bei Ubuntu selbst, sondern bei einem eigenen Zertifikatsspeicher der Anwendung. Genau dort entstehen die meisten Irrtümer im Betrieb.

Die häufigsten Stolperfallen im Alltag

Die meisten Probleme sind erstaunlich banal. Ich sehe sie in Projekten immer wieder, und fast immer kosten sie mehr Zeit als der eigentliche Import. Diese Tabelle fasst die typischen Fehler sauber zusammen:

Ein Detail, das oft übersehen wird: Snap-Anwendungen, darunter auch snap-verpackte Browser, übernehmen den System-Trust-Store nicht immer automatisch. Das ist kein Ubuntu-Fehler, sondern eine Folge der Sandbox. Deshalb prüfe ich bei Browsern und isolierten Tools immer separat, ob sie wirklich auf denselben Vertrauensspeicher zugreifen.

Wann ein systemweiter Import nicht reicht

Ein systemweiter Import ist sauber, aber nicht immer ausreichend. Manche Plattformen bringen ihren eigenen Trust Store mit, zum Beispiel Java-Anwendungen mit Keystore, bestimmte Container-Images, Browser-Sandboxen oder Werkzeuge, die ihre Zertifikate aus einer eigenen Bibliothek lesen. Dann musst du das CA-Zertifikat zusätzlich dort hinterlegen oder die Anwendung so konfigurieren, dass sie den System-Store verwendet.

Ich trenne deshalb im Betrieb sehr bewusst zwischen „Ubuntu vertraut der CA“ und „die konkrete Anwendung vertraut der CA“. Das ist nicht dasselbe. Ein Server kann im Betriebssystem korrekt eingerichtet sein und trotzdem in einer Java-App, einem Container oder einem isolierten Browser-Setup weiter scheitern. In solchen Fällen ist der nächste Schritt kein erneuter Systemimport, sondern die Analyse des jeweiligen Applikations-Stacks.

Damit der Trust Store später nicht wieder kippt

• Dokumentiere, welche Systeme die CA brauchen und wer sie verwaltet.
• Halte Root- und Zwischenzertifikate getrennt, damit du Ketten später sauber erneuern kannst.
• Prüfe nach Änderungen immer erneut mit einem echten TLS-Handshake statt nur mit einem Datei-Check.
• Plane für CA-Rotationen eine Überlappung ein, damit alte und neue Ketten kurzzeitig parallel funktionieren.
• Wenn du ein Zertifikat entfernst, nutze sudo update-ca-certificates --fresh, damit veraltete Einträge nicht hängen bleiben.

Genau so bleibt ein CA-Setup in Ubuntu überschaubar: klarer Ablageort, sauberes Format, kontrollierter Import und ein kurzer Funktionstest danach. Wenn du diese vier Punkte konsequent einhältst, wird aus einem anfälligen Zertifikatsproblem ein ganz normaler, gut wartbarer Administrationsschritt.