Eigene CA in Ubuntu Trust Store aufnehmen

Eigene CA zum Trust Store von Ubuntu hinzufügen

Um eine eigene CA zum Trust Store von Ubuntu hinzuzufügen, kopieren Sie das Root-Zertifikat unter einem Namen mit der Endung .crt nach /usr/local/share/ca-certificates/ und führen Sie anschließend sudo update-ca-certificates aus. Eine CA (Certificate Authority) ist ein Schlüsselpaar, dessen Zertifikat andere Zertifikate signieren darf. Sobald der Rechner Ihrem Root-Zertifikat vertraut, wird jedes von diesem Root-Zertifikat signierte Zertifikat akzeptiert. Dadurch schlagen HTTPS-Verbindungen zwischen Ihren eigenen Diensten nicht mehr an der Zertifikatsprüfung fehl.

In dieser Anleitung erstellen Sie die gesamte Zertifikatskette offline mit openssl. Sie erzeugen einen Root-Schlüssel und ein Root-Zertifikat, stellen ein Leaf-Zertifikat für einen Server aus und installieren anschließend das Root-Zertifikat. Danach beobachten Sie, wie derselbe Prüfungsbefehl ein anderes Ergebnis liefert. Diese Reihenfolge ist entscheidend: Der Vergleich der Prüfung vor und nach der Installation zeigt, dass die Installation das Ergebnis geändert hat.

Ubuntu 24.04 enthält auf einem Standard-Image OpenSSL 3 und das Paket ca-certificates. Daher muss zunächst nichts installiert werden (Stand: August 2026).

Wann sollten Sie eine eigene CA betreiben?

Eine öffentliche CA wie Let's Encrypt benötigt einen Namen im öffentlichen DNS und einen Server, den sie erreichen kann. Interne Namen erfüllen diese Voraussetzung nicht. Eine Datenbank in einem privaten Netzwerk oder ein an einen Tunnel gebundenes Admin-Panel kann kein öffentliches Zertifikat erhalten. Es sollte auch nicht nur dafür dem Internet ausgesetzt werden.

Ein selbstsigniertes Zertifikat unter Ubuntu gilt genau für einen Host. Jeder Client muss diesem einzelnen Zertifikat vertrauen. Beim nächsten Host beginnt dieselbe Arbeit von vorn. Eine private CA verlagert diese Entscheidung auf eine höhere Ebene. Die Clients vertrauen der Root-CA einmal. Danach vertrauen sie jedem Zertifikat, das diese Root-CA signiert, einschließlich Zertifikaten für Hosts, die noch nicht existieren.

Der Aufwand ist real. Der Root-Schlüssel kann alles signieren, was die Einschränkungen zulassen. Wer ca.key lesen kann, kann Zertifikate für Ihre Rechner ausstellen, die diese akzeptieren. Schützen Sie ihn genauso sorgfältig wie einen privaten Schlüssel im Rahmen der SSH-Schlüsselverwaltung. Wenn ein Dienst einen öffentlichen DNS-Namen besitzt, überspringen Sie all das und verwenden Sie eine öffentliche CA: Certbot mit nginx und Let's Encrypt verursacht weniger Arbeit und erfordert keine Installation auf der Client-Seite.

CA-Schlüssel und Root-Zertifikat erstellen

Arbeiten Sie in einem Verzeichnis, auf das nur Ihr Benutzer zugreifen kann. Der Root-Schlüssel verlässt dieses Verzeichnis nie.

install -d -m 700 ~/ca
cd ~/ca
openssl genrsa -aes256 -out ca.key 4096
chmod 600 ca.key

-aes256 verschlüsselt den Schlüssel mit einer von Ihnen gewählten Passphrase. Jeder spätere Befehl, der mit diesem Schlüssel signiert, fragt danach. Lassen Sie -aes256 weg, liegt der Schlüssel unverschlüsselt auf der Festplatte. Dann reicht eine Sicherung oder ein zweites Administratorkonto aus, um jemandem die Möglichkeit zu geben, Zertifikate für Ihre vertrauenswürdigen Systeme auszustellen.

Erstellen Sie nun das Root-Zertifikat, das der CA-Schlüssel für sich selbst signiert.

openssl req -x509 -new -key ca.key -sha256 -days 3650 \
  -subj "/O=Example Internal/CN=Example Internal Root CA" \
  -addext "basicConstraints=critical,CA:TRUE,pathlen:0" \
  -addext "keyUsage=critical,keyCertSign,cRLSign" \
  -addext "subjectKeyIdentifier=hash" \
  -addext "nameConstraints=critical,permitted;DNS:internal.example" \
  -out ca.crt

Ersetzen Sie internal.example durch das tatsächlich verwendete Namenssuffix. Lesen Sie den nächsten Abschnitt, bevor Sie diese letzte Erweiterung beibehalten.

Jede Erweiterung erfüllt eine Aufgabe.

• basicConstraints mit CA:TRUE macht daraus ein CA-Zertifikat. Ohne diese Erweiterung lehnt ein Client jedes Zertifikat ab, das mit diesem Schlüssel signiert wurde, selbst wenn die Signatur selbst korrekt ist.
• pathlen:0 gibt an, dass die CA Leaf-Zertifikate, aber keine weiteren untergeordneten CAs signieren darf.
• keyUsage beschränkt den Schlüssel auf das Signieren von Zertifikaten und Sperrlisten. Dadurch kann derselbe Schlüssel nicht versehentlich als TLS-Server-Schlüssel verwendet werden.
• subjectKeyIdentifier weist dem Root einen Bezeichner zu, auf den Leaf-Zertifikate zurückverweisen. So findet ein Client den richtigen Aussteller in einem Speicher mit mehreren hundert Zertifikaten.
• nameConstraints beschränkt die Namen, für die diese CA Zertifikate ausstellen darf.

Lesen Sie die erstellten Daten aus, statt anzunehmen, dass der Befehl genau das getan hat, was Sie beabsichtigt haben.

openssl x509 -noout -subject -issuer -serial -dates -in ca.crt
openssl x509 -noout -text -in ca.crt

Subject und issuer geben dieselbe Zeichenfolge aus, weil ein Root-Zertifikat sich selbst signiert. Die Seriennummer und die beiden Datumsangaben stammen aus der gerade erstellten Datei. Übernehmen Sie sie daher aus dieser Ausgabe und nicht aus einer Anleitung.

Begrenzen Sie, was Ihre CA signieren darf

Ein Root-Zertifikat im Systemstore wird für jeden Namen im Internet als vertrauenswürdig eingestuft, sofern Sie nichts anderes festlegen. Das ist eine große Berechtigung, die in einer einzigen Datei auf einem einzigen Server liegt. nameConstraints begrenzt diese Berechtigung. Mit permitted;DNS:internal.example im Root-Zertifikat wird eine Zertifikatskette dieser CA für einen Namen außerhalb von internal.example abgelehnt, obwohl die Signatur gültig ist.

Testen Sie das, anstatt dem Zertifikat einfach zu vertrauen.

openssl req -new -newkey rsa:2048 -nodes -keyout /tmp/outside.key -out /tmp/outside.csr \
  -subj "/CN=www.example.com"
openssl x509 -req -in /tmp/outside.csr -CA ca.crt -CAkey ca.key -CAcreateserial \
  -days 30 -sha256 \
  -extfile <(printf 'subjectAltName=DNS:www.example.com\n') -out /tmp/outside.crt
openssl verify -CAfile ca.crt /tmp/outside.crt
echo $?

Das Zertifikat wird ausgestellt, weil Ihre CA alles signiert, was Sie von ihr verlangen. Die Prüfung schlägt erst danach fehl: Der Exit-Status ist ungleich null, und OpenSSL nennt die verletzte Einschränkung. Darin liegt der Nutzen dieser Erweiterung. Selbst mit einem gestohlenen CA-Schlüssel kann kein funktionierendes Zertifikat für einen Namen außerhalb des Teilbaums erstellt werden. Löschen Sie die zurückgebliebenen Dateien mit rm /tmp/outside.*, wenn Sie fertig sind.

Vor der Festlegung auf eine Einschränkung sollten Sie vier Punkte kennen. Sie ist als critical gekennzeichnet. Ein Client, der die Erweiterung nicht versteht, muss die Zertifikatskette daher ablehnen, statt sie zu ignorieren. Das ist die sichere Richtung, kann aber eine alte TLS-Bibliothek überraschen. Ein zulässiger Teilbaum für DNS-Namen schränkt IP-Adress-SANs nicht ein, weil ein Namenstyp ohne angegebenen Teilbaum uneingeschränkt bleibt. Fügen Sie daher permitted;IP:10.0.0.0/255.255.0.0 in derselben Erweiterung hinzu, wenn Ihre Zertifikate IP-Adressen enthalten. Der Teilbaum muss jeden Namen abdecken, den Sie jemals ausstellen werden, einschließlich kurzer Hostnamen. Ein Zertifikat für den unqualifizierten Namen app würde im obigen Beispiel daher abgelehnt. Außerdem ist die Einschränkung im Root-Zertifikat fest verankert. Wenn Sie Ihre Meinung ändern, benötigen Sie ein neues Root-Zertifikat und müssen es auf jedem Client neu installieren.

Ein Leaf-Zertifikat ausstellen, das von Ihrer CA signiert wurde

Ein Leaf-Zertifikat ist das Zertifikat, das ein Server Clients präsentiert. Erstellen Sie zunächst den eigenen Schlüssel und eine CSR (Certificate Signing Request). Sie enthält den öffentlichen Schlüssel und den angeforderten Namen. Der Leaf-Schlüssel signiert die CSR, um nachzuweisen, dass der Anforderer über den privaten Schlüssel verfügt.

openssl req -new -newkey rsa:2048 -nodes \
  -keyout app.key -out app.csr \
  -subj "/CN=app.internal.example"
chmod 600 app.key

Die relevanten Namen gehören in eine Erweiterungsdatei, nicht in die CSR. Clients gleichen den Hostnamen mit subjectAltName (SAN) ab und ignorieren den Common Name vollständig. Ein Zertifikat mit CN, aber ohne SAN, besteht daher bei jedem aktuellen Client die Hostnamenprüfung nicht, unabhängig davon, was im CN steht.

basicConstraints = CA:FALSE
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
subjectAltName = DNS:app.internal.example, DNS:api.internal.example
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always

Speichern Sie die Datei als app.ext und signieren Sie anschließend die Anfrage mit der CA.

openssl x509 -req -in app.csr -CA ca.crt -CAkey ca.key -CAcreateserial \
  -days 397 -sha256 -extfile app.ext -out app.crt

-CAcreateserial schreibt neben der CA die Datei ca.srl. Sie enthält die nächste Seriennummer, damit kein Zertifikat dieser CA dieselbe Seriennummer erhält wie ein anderes. Bewahren Sie diese Datei im CA-Verzeichnis auf. -days 397 ist eine Auswahl und keine Begrenzung des Tools. Kurze Gültigkeitsdauern sind hier wichtiger als bei einer öffentlichen CA, weil eine private CA über keine Infrastruktur für den Widerruf verfügt: Es gibt keine CRL und keinen OCSP-Responder, sofern Sie keinen einrichten. Ein offengelegter Leaf-Schlüssel bleibt daher bis zum Ablauf des Zertifikats verwendbar.

Prüfen Sie das Ergebnis, bevor Sie den Trust Store ändern.

openssl x509 -noout -subject -issuer -serial -dates -in app.crt
openssl x509 -noout -ext subjectAltName -in app.crt

In der Issuer-Zeile ist nun die CA statt des Leaf-Zertifikats selbst angegeben. Die SAN-Zeile enthält die Namen, für die dieses Zertifikat gültig ist. Ein Client gleicht den Hostnamen ausschließlich mit dieser Liste ab.

Mit einem expliziten -CAfile prüfen, bevor Sie etwas installieren

openssl verify -CAfile ca.crt app.crt
echo $?

Damit wird eine eng begrenzte Frage geprüft: Verweist app.crt auf das Zertifikat in ca.crt? Über die Vertrauenswürdigkeit dieses Rechners sagt das nichts aus, weil Sie OpenSSL das Root-Zertifikat über die Kommandozeile vorgegeben haben. Ein Fehler an dieser Stelle weist auf ein Problem mit den Zertifikaten selbst hin. Beheben Sie ihn, bevor Sie fortfahren.

Fragen Sie nun den Rechner.

openssl verify app.crt
echo $?

Ohne -CAfile verwendet OpenSSL das integrierte Zertifikatsverzeichnis. openssl version -d gibt das Basisverzeichnis aus, das Ihr Build verwendet. Unter Ubuntu verweist das darin enthaltene Verzeichnis certs auf /etc/ssl/certs. Ihr Root-Zertifikat befindet sich dort noch nicht. Deshalb schlägt die Prüfung fehl: Die Zertifikatskette endet bei einem Aussteller, den der Zertifikatsspeicher nicht enthält, und es gibt keinen weiteren Speicherort, den OpenSSL prüfen kann. Beachten Sie den Exit-Status. Er ändert sich in zwei Schritten.

Ein echter Client eignet sich besser als openssl verify, weil er neben der Zertifikatskette auch den Hostnamen prüft. Stellen Sie das Zertifikat bereit und rufen Sie es ab.

openssl s_server -accept 8443 -cert app.crt -key app.key -www &
curl --resolve app.internal.example:8443:127.0.0.1 https://app.internal.example:8443/

--resolve stellt die Verbindung zu 127.0.0.1 her und fordert dabei weiterhin app.internal.example an. Dadurch stimmt der SAN überein, und als einzige offene Frage bleibt die Vertrauenswürdigkeit. curl schlägt fehl und gibt den Grund aus, warum die Zertifikatskette nicht geprüft werden konnte. Fügen Sie -v für weitere Details hinzu. Lassen Sie den Testserver weiterlaufen.

Installieren Sie das Root-Zertifikat in /usr/local/share/ca-certificates

sudo cp ca.crt /usr/local/share/ca-certificates/example-internal-root.crt
sudo chmod 644 /usr/local/share/ca-certificates/example-internal-root.crt
sudo update-ca-certificates

Die folgenden Details entscheiden darüber, ob dies überhaupt funktioniert:

• Der Dateiname muss auf .crt enden. Die update-ca-certificates-Handbuchseite besagt, dass Zertifikate mit der Erweiterung .crt unterhalb von /usr/local/share/ca-certificates eingebunden und implizit als vertrauenswürdig eingestuft werden. Eine Datei mit dem Namen root.pem oder root.cer wird übersprungen, ohne dass dies gemeldet wird.
• Der Inhalt muss im PEM-Format vorliegen. Dabei handelt es sich um den Base64-Block zwischen den Zeilen BEGIN CERTIFICATE und END CERTIFICATE. Eine DER-Datei, die in .crt umbenannt wurde, bleibt binär und wird nicht gelesen. Konvertieren Sie sie mit openssl x509 -inform DER -in ca.der -out ca.crt.
• Nur das Root-Zertifikat gehört hierher. Der private CA-Schlüssel und das Leaf-Zertifikat gehören nicht in einen Trust Store.

update-ca-certificates gibt aus, wie viele Zertifikate hinzugefügt und entfernt wurden. Wenn keine hinzugefügt wurden, liegt das an der Dateiendung oder am Dateiformat.

Bestätigen Sie die Änderung von der Systemseite aus, statt sich auf diese Meldung zu verlassen.

ls -l /etc/ssl/certs/$(openssl x509 -noout -subject_hash -in /usr/local/share/ca-certificates/example-internal-root.crt).0
grep -c 'BEGIN CERTIFICATE' /etc/ssl/certs/ca-certificates.crt

Der erste Befehl erstellt aus dem Subject-Hash Ihres Zertifikats einen Dateinamen und listet ihn auf. update-ca-certificates hat diesen symbolischen Link erstellt. Er verweist zurück auf die installierte Datei. Der zweite Befehl zählt die Zertifikate im Bundle aus einer einzelnen Datei. Führen Sie ihn auch vor der Installation aus. So können Sie beobachten, wie sich die Anzahl um eins erhöht.

Wenn Sie dieses Root-Zertifikat auf andere Rechner kopieren, prüfen Sie vor der Installation, ob die Kopie vollständig und unverändert angekommen ist. Bei einem Root-Zertifikat kann ein Fehler besonders schwerwiegende Folgen haben. Behandeln Sie es daher wie jeden anderen Download, den Sie vor der Verwendung mit einer Prüfsumme verifizieren würden.

Erneut anhand des Systemspeichers prüfen

openssl verify app.crt
echo $?
curl --resolve app.internal.example:8443:127.0.0.1 https://app.internal.example:8443/

Gleiche Befehle, gleiche Zertifikatsdateien, anderes Ergebnis. An app.crt hat sich nichts geändert, und der Server ist derselbe, den Sie zuvor gestartet haben. Der einzige Unterschied besteht darin, dass die Root-CA jetzt in dem Store liegt, den diese Clients verwenden. Dadurch kann die Kette vollständig validiert werden. Das ist der entscheidende Mechanismus: Bei der Prüfung sucht der Client nach einem Aussteller, dem er bereits vertraut. Durch die Installation einer CA gelangt dieser Aussteller an den Ort, den der Client durchsucht.

Beenden Sie den Testserver mit kill %1.

Warum /etc/ssl/certs nicht der richtige Ort für Ihre Datei ist

/etc/ssl/certs ist eine generierte Ausgabe. update-ca-certificates füllt das Verzeichnis mit symbolischen Links zu den eigentlichen Zertifikatsdateien und schreibt das zusammengeführte Bundle /etc/ssl/certs/ca-certificates.crt daneben.

Ein Zertifikat, das Sie manuell in dieses Verzeichnis kopieren, wird von keinem Dienst gefunden. Die Verzeichnissuche von OpenSSL öffnet nur Dateien, deren Namen aus dem Subject-Hash eines Zertifikats gebildet werden. Eine Datei namens myca.crt bleibt daher unsichtbar. curl unter Ubuntu liest die Bundle-Datei. Das Bundle wird aus den registrierten Quellen neu erstellt, sodass Ihre Kopie auch dort nicht enthalten ist. Wenn Sie update-ca-certificates --fresh ausführen, werden die symbolischen Links im Verzeichnis entfernt und neu erstellt. Dabei wird auch jeder manuell angelegte Link gelöscht.

Der andere Teil dieser Aufteilung ist /usr/share/ca-certificates. Diese Datei gehört zum Paket ca-certificates und ist in /etc/ca-certificates.conf aufgeführt. Bei Paketaktualisierungen wird sie überschrieben. /usr/local/share/ca-certificates ist für den lokalen Administrator reserviert. Ihre CA bleibt daher bei jedem Upgrade des Pakets erhalten, das den übrigen Bestand verwaltet.

Welche Programme den System-Truststore ignorieren

Die Installation des Root-Zertifikats behebt das Problem für jedes Programm, das OpenSSL verwendet oder /etc/ssl/certs liest. Dazu gehören curl, wget, git, Pythons Standardmodul ssl und Go-Programme, die unter Linux die Systemdateien lesen. Laufzeitumgebungen mit einer eigenen Zertifikatsliste sind davon nicht betroffen. Das ist die häufigste Ursache für Verwirrung nach einer erfolgreichen Installation.

• Node.js verwendet eine einkompilierte Liste. Verweisen Sie mit NODE_EXTRA_CA_CERTS=/usr/local/share/ca-certificates/example-internal-root.crt auf Ihr Root-Zertifikat. Setzen Sie die Variable in der Umgebung, bevor der Prozess startet, weil Node sie nur einmal beim Start liest. Aktuelle Node-Releases können außerdem den System-Truststore lesen. Führen Sie node --help | grep -i system-ca aus, um zu prüfen, ob Ihre Version diese Option unterstützt.
• Pythons Bibliothek requests verwendet das Bundle certifi. Setzen Sie REQUESTS_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt für diesen Prozess oder übergeben Sie verify="/etc/ssl/certs/ca-certificates.crt" an den Aufruf. pip akzeptiert aus demselben Grund --cert.
• Java liest einen Keystore. Unter Ubuntu installiert das Paket ca-certificates-java einen Hook unter /etc/ca-certificates/update.d/. Wenn dieses Paket vorhanden ist, aktualisiert update-ca-certificates daher auch den Java-Keystore. Ohne dieses Paket importieren Sie das Root-Zertifikat mit keytool -importcert.
• Firefox verwaltet seinen eigenen Truststore und liest /etc/ssl/certs nie. Importieren Sie das Zertifikat über die Zertifikatseinstellungen. Chromium unter Linux liest eine NSS-Datenbank pro Benutzer. Diese bearbeiten Sie mit certutil aus dem Paket libnss3-tools.
• Container haben ihr eigenes Dateisystem. Der Truststore des Hosts ist darin daher nicht verfügbar. Kopieren Sie das Root-Zertifikat in das Image und führen Sie während des Builds update-ca-certificates aus. Berücksichtigen Sie das, wenn Ihre Dienste unter Docker Compose auf einem VPS laufen.

Wenn ein Programm das Zertifikat nach einer sauberen Installation weiterhin ablehnt, ermitteln Sie zuerst, welche Dateien es öffnet. Ändern Sie vorher nichts anderes. strace -f -e trace=openat <command> 2>&1 | grep -i cert ist dafür ein grobes, aber direktes Werkzeug und beantwortet die Frage in einem Durchlauf.

Die CA langfristig nutzbar halten

Ein Leaf-Zertifikat neu auszustellen bedeutet, den CSR-Schritt und den Signaturschritt mit derselben Datei app.ext erneut auszuführen. Clients müssen nichts tun, weil sich die vertrauenswürdige Root nicht geändert hat. Bewahren Sie ca.srl und jede Datei .ext im CA-Verzeichnis auf. Dann wiederholen Sie beim nächsten Ausstellen einen funktionierenden Befehl, statt ihn aus dem Gedächtnis rekonstruieren zu müssen.

Sichern Sie ca.key und ca.crt weiterhin verschlüsselt an einem Ort außerhalb des Rechners. Wenn Sie den Schlüssel verlieren, können Sie nichts Neues ausstellen. Sie müssen eine zweite CA erstellen und deren Root überall installieren, wo die erste Root installiert war. Führen Sie eine schriftliche Liste aller Rechner und Anwendungsspeicher, die die Root erhalten haben. Nur mit dieser Liste sind Rotation und Entfernung überhaupt möglich.

Wenn sich die Root ihrem Ablaufdatum nähert, erstellen Sie frühzeitig einen Ersatz und installieren Sie beide Roots parallel. Zwei Roots im Speicher sind unproblematisch. Ein Client akzeptiert beide. Stellen Sie die Leaf-Zertifikate neu gegen die neue Root aus. Entfernen Sie die alte Root anschließend, sobald nichts mehr von ihr abhängt.

CA aus dem Trust Store entfernen

sudo rm /usr/local/share/ca-certificates/example-internal-root.crt
sudo update-ca-certificates --fresh

--fresh entfernt die Symlinks in /etc/ssl/certs und erstellt sie aus den noch vorhandenen Quellen neu. Dadurch verschwinden das gelöschte Root-Zertifikat und der zugehörige Bundle-Eintrag gemeinsam aus dem Verzeichnis. Weisen Sie die Entfernung auf dieselbe Weise nach wie zuvor die Installation.

openssl verify app.crt
echo $?
grep -c 'BEGIN CERTIFICATE' /etc/ssl/certs/ca-certificates.crt
ls -l /etc/ssl/certs/$(openssl x509 -noout -subject_hash -in ~/ca/ca.crt).0

Die Überprüfung schlägt erneut fehl, die Anzahl der Zertifikate entspricht wieder dem Ausgangswert, und der Hash-Symlink ist nicht mehr vorhanden.

Dieser Befehl ändert ausschließlich den System-Store. Machen Sie die Installation an den anderen Stellen manuell rückgängig: Leeren Sie NODE_EXTRA_CA_CERTS, löschen Sie den Alias aus jedem Java-Keystore, entfernen Sie das Root-Zertifikat aus jedem Browserprofil und erstellen Sie jedes Container-Image neu, in das es eingebettet wurde. Durch das Entfernen des Root-Zertifikats werden die von ihm signierten Zertifikate ebenfalls nicht ungültig. Sie bleiben auf jedem Rechner gültig, der dem Root-Zertifikat weiterhin vertraut. Genau deshalb muss für eine private CA schriftlich festgehalten werden, wo das Root-Zertifikat installiert wurde. Eine CA, die Sie nicht vollständig zurückziehen können, stellt eine dauerhafte Sicherheitslücke dar. Testen Sie die Entfernung daher am Tag der Einrichtung auf einem Rechner, solange die Liste noch kurz ist.

FAQ

Wo lege ich ein CA-Zertifikat unter Ubuntu ab?

In /usr/local/share/ca-certificates/, mit einem Dateinamen, der auf .crt endet, und mit PEM-Inhalt. Führen Sie anschließend sudo update-ca-certificates aus. Dieses Verzeichnis ist für den lokalen Administrator reserviert. Paketaktualisierungen lassen es daher unverändert. /usr/share/ca-certificates gehört zum Paket ca-certificates. /etc/ssl/certs wird aus beiden Verzeichnissen erzeugt. Eine Datei in einem dieser Verzeichnisse wird daher überschrieben oder ignoriert.

Warum lehnt curl das Zertifikat nach update-ca-certificates weiterhin ab?

Arbeiten Sie die möglichen Ursachen in dieser Reihenfolge durch. Die Datei endet möglicherweise nicht auf .crt oder liegt als DER statt als PEM vor. In diesem Fall hat update-ca-certificates sie übersprungen und nichts hinzugefügt. Das Zertifikat enthält möglicherweise kein subjectAltName, das zum Hostnamen passt. Das ist ein Hostnamenfehler und kein Vertrauensfehler. Prüfen Sie dies mit openssl x509 -noout -ext subjectAltName -in app.crt. Der Server sendet möglicherweise nur das Leaf-Zertifikat, obwohl zusätzlich ein Zwischenzertifikat erforderlich ist. curl verwendet möglicherweise ein anderes Bundle, das durch CURL_CA_BUNDLE oder --cacert festgelegt wird. Ein Dienst mit langer Laufzeit muss außerdem neu gestartet werden, da die meisten Programme den Trust Store nur beim Start einlesen.

Deckt der systemweite Trust Store Firefox, Chrome, Node und Java ab?

Nein. curl, wget, git, das standardmäßige ssl-Modul von Python und Go-Programme lesen die Systemdateien. Sie funktionieren daher, sobald update-ca-certificates ausgeführt wurde. Firefox verwendet einen eigenen Store. Chromium unter Linux verwendet eine benutzerspezifische NSS-Datenbank. Diese wird mit certutil aus dem Paket libnss3-tools bearbeitet. Node.js benötigt NODE_EXTRA_CA_CERTS, das auf Ihre Root-Datei verweist. Java liest einen Keystore. update-ca-certificates aktualisiert ihn nur, wenn das Paket ca-certificates-java installiert ist. Pythons requests verwendet certifi und benötigt REQUESTS_CA_BUNDLE.

Wie entferne ich eine CA aus dem Trust Store von Ubuntu?

Löschen Sie die Datei aus /usr/local/share/ca-certificates/ und führen Sie sudo update-ca-certificates --fresh aus. Die Option --fresh entfernt die Symlinks in /etc/ssl/certs und erstellt sie neu. Dadurch wird das Zertifikat gleichzeitig aus den Hash-Symlinks und dem Bundle ca-certificates.crt entfernt. Bestätigen Sie dies, indem Sie openssl verify für ein von dieser CA signiertes Zertifikat ausführen und den Exit-Status prüfen. Wiederholen Sie die Entfernung anschließend in jedem anderen Store, in den Sie das Zertifikat eingefügt haben. Dieser Befehl ändert keinen dieser anderen Stores.

Kann ich für eine öffentliche Website eine private CA statt Let's Encrypt verwenden?

Nein. Der Browser eines Besuchers kennt Ihre Root nicht. Daher zeigt er eine ganzseitige Warnung an. Sie können Ihre Root nicht auf Rechnern installieren, die Sie nicht kontrollieren. Eine private CA ist für Namen vorgesehen, die nur von Ihren eigenen Rechnern aufgelöst werden, sowie für von Ihnen verwaltete Clients. Für Websites, die von beliebigen Besuchern aufgerufen werden, benötigen Sie ein Zertifikat einer öffentlichen CA.