Selbstsigniertes TLS-Zertifikat Ubuntu 24.04

Was Sie erstellen

Ein selbstsigniertes TLS-Zertifikat, das von modernen Browsern und Clients akzeptiert wird — mit korrekten subjectAltName, sicheren Key-Berechtigungen, eingebunden in nginx oder Apache — plus der Teil, den fast jede Anleitung überspringt: die korrekte Vertrauensstellung durch die Clients, anstatt Sicherheitswarnungen zu ignorieren und curl -k dauerhaft in Skripte zu schreiben. Am Ende steht eine private CA mit nur fünf Befehlen, die nützlich ist, wenn aus einem internen Dienst sechs werden.

Zuerst die Entscheidung, da ein selbstsigniertes Zertifikat viel seltener das richtige Werkzeug ist, als es oft verwendet wird. Wenn der Dienst über einen echten DNS-Namen aus dem öffentlichen Internet erreichbar ist, hören Sie hier auf zu lesen und nutzen Sie stattdessen ein kostenloses Let's Encrypt Zertifikat mit certbot auf nginx oder das Apache-Äquivalent. Es kostet nichts, erneuert sich selbst und jeder Browser auf der Welt vertraut ihm bereits. Ein selbstsigniertes Zertifikat auf einer öffentlichen Website gewöhnt Ihre Benutzer daran, Sicherheitswarnungen zu ignorieren, was eine schlechtere Gewohnheit ist als einfaches HTTP.

Selbstsigniert ist das richtige Werkzeug, wenn kein öffentliches Internet involviert ist: ein Admin-Panel, das an eine WireGuard-Tunnel-Adresse auf Ihrem VPS gebunden ist, ein Staging-System in einem privaten Netzwerk, Service-zu-Service-Verkehr zwischen Backends, ein Home-Lab-Gerät oder der Ersatz für das Platzhalter-Zertifikat, das Webmin für sich selbst auf Port 10000 generiert. Let's Encrypt kann für 10.8.0.1 oder git.internal.lan ohnehin keine Zertifikate ausstellen — keine öffentliche CA wird eine private IP oder eine erfundene TLD in ein Zertifikat aufnehmen. Für diese Namen sind Sie die CA.

Alles Folgende läuft auf einem frischen Ubuntu 24.04 System, das OpenSSL 3.0.x ausliefert (nutzen Sie openssl version zur Bestätigung). Nichts davon benötigt Internetzugang; alles funktioniert offline.

Warum der alte Einzeiler Zertifikate erzeugt, die Chrome ablehnt

Der Befehl, der in jedem Tutorial vor 2017 verwendet wird, sieht so aus:

# Do not run this — shown so you recognise it in old guides
openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
  -keyout selfsigned.key -out selfsigned.crt

Dieser Befehl stellt eine Reihe interaktiver Fragen, setzt Ihren Hostnamen in das Feld Common Name und erzeugt ein Zertifikat ohne subjectAltName-Erweiterung. Dieses Zertifikat ist unbrauchbar. Chrome liest den Common Name seit Version 58 im April 2017 nicht mehr aus — RFC 2818 hatte das CN-Matching bereits im Jahr 2000 als veraltet eingestuft — und Firefox, Safari, curl sowie Python verhalten sich identisch. Ein Zertifikat identifiziert den Server über die SAN-Erweiterung oder gar nicht. Der Browser gibt dies mit folgendem Wortlaut aus:

NET::ERR_CERT_COMMON_NAME_INVALID

This server could not prove that it is git.internal.lan; its security
certificate does not specify Subject Alternative Names.

Keine Anpassung des Trust-Stores behebt diesen Fehler, da das Zertifikat keine Identität enthält. Wenn Sie gerade NET::ERR_CERT_COMMON_NAME_INVALID sehen, besitzt Ihr Zertifikat kein SAN (oder ein falsches SAN) und Sie müssen ein neues erstellen. Die Lösung besteht glücklicherweise aus nur einem Befehl.

Ein von Browsern akzeptiertes Zertifikat erstellen: ein Befehl

OpenSSL hat in Version 1.1.1 das Flag -addext hinzugefügt. Dadurch entfällt die Verwendung von Konfigurationsdateien, die in älteren Anleitungen zur Injektion eines SAN erforderlich waren. Auf Ubuntu 24.04:

sudo openssl req -x509 -newkey rsa:4096 -sha256 -days 730 -noenc \
  -keyout /etc/ssl/private/git.internal.key \
  -out /etc/ssl/certs/git.internal.crt \
  -subj "/CN=git.internal.lan" \
  -addext "subjectAltName=DNS:git.internal.lan,IP:10.8.0.1"

Funktion der einzelnen Flags:

• -x509 erstellt direkt ein selbstsigniertes Zertifikat anstatt eines Signing Requests.
• -newkey rsa:4096 generiert im selben Schritt einen neuen Schlüssel. RSA 4096 ist mit Legacy-Clients kompatibel; wenn alle Clients modern sind, ist -newkey ec -pkeyopt ec_paramgen_curve:P-256 kleiner und schneller.
• -noenc ist die OpenSSL 3.x Schreibweise für das alte -nodes: kein Passphrase für den Schlüssel. Beide Schreibweisen funktionieren. Ein passwortgeschützter Schlüssel führt dazu, dass nginx bei jedem Bootvorgang auf eine Eingabe wartet; für einen Serverschlüssel ist diese Einstellung daher erforderlich.
• -days 730 — zwei Jahre; Details zu diesem Wert finden Sie im Abschnitt zur Gültigkeit.
• -subj beantwortet interaktive Fragen direkt im Befehl. Der CN ist nur noch kosmetisch, sollte aber dennoch auf den primären Namen gesetzt werden, da einige Tools ihn anzeigen.
• -addext "subjectAltName=..." ist das entscheidende Flag. Listen Sie jeden Namen und jede IP-Adresse auf, die Clients verwenden werden: DNS: Einträge für Hostnamen (Wildcards wie DNS:*.internal.lan sind zulässig), IP: Einträge für Adressen. Wenn ein Client auf https://10.8.0.1 zugreift, muss der IP:10.8.0.1 Eintrag vorhanden sein — ein SAN, der nur DNS-Einträge enthält, führt erneut zu NET::ERR_CERT_COMMON_NAME_INVALID.

Überprüfen Sie, ob das SAN korrekt gesetzt wurde, bevor Sie die Konfiguration abschließen:

openssl x509 -in /etc/ssl/certs/git.internal.crt -noout -ext subjectAltName

Korrekte Ausgabe:

X509v3 Subject Alternative Name:
    DNS:git.internal.lan, IP Address:10.8.0.1

Wird stattdessen No extensions in certificate ausgegeben, besitzt das Zertifikat kein SAN und Browser werden es ablehnen. In diesem Fall das Zertifikat neu generieren, anstatt fortzufahren.

Lock down the key

A private key readable by every user on the box is not a private key. On Ubuntu, /etc/ssl/private is already 710 root:ssl-cert, which keeps casual eyes out, but set the file itself explicitly:

sudo chown root:root /etc/ssl/private/git.internal.key
sudo chmod 600 /etc/ssl/private/git.internal.key

nginx and Apache both read certificates as root before dropping privileges, so root:root mode 600 works for them. If the key is for a service that runs as its own user and loads the key itself — a Node app, Gitea, a Python daemon — chown it to that service user instead, still mode 600. What you never do: mode 644, a copy in a git repository, or a copy in /tmp.

In nginx einbinden

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name git.internal.lan;

    ssl_certificate     /etc/ssl/certs/git.internal.crt;
    ssl_certificate_key /etc/ssl/private/git.internal.key;

    location / {
        proxy_pass http://127.0.0.1:3000;
    }
}

sudo nginx -t && sudo systemctl reload nginx

nginx -t muss syntax is ok und test is successful ausgeben, bevor der Reload eine Änderung bewirkt. Wenn stattdessen SSL_CTX_use_PrivateKey_file() failed ... key values mismatch ausgegeben wird, stammen das Zertifikat und der Key aus zwei verschiedenen Generierungsläufen — siehe Abschnitt Failure-modes.

Integration in Apache

sudo a2enmod ssl proxy proxy_http

ssl allein reicht hier nicht aus: Der folgende vhost verwendet ProxyPass. Ohne mod_proxy und mod_proxy_http schlägt der Konfigurationstest mit Invalid command 'ProxyPass', perhaps misspelled or defined by a module not included in the server configuration fehl. Speichern Sie den vhost als /etc/apache2/sites-available/git-internal.conf:

<VirtualHost *:443>
    ServerName git.internal.lan
    SSLEngine on
    SSLCertificateFile      /etc/ssl/certs/git.internal.crt
    SSLCertificateKeyFile   /etc/ssl/private/git.internal.key

    ProxyPass        / http://127.0.0.1:3000/
    ProxyPassReverse / http://127.0.0.1:3000/
</VirtualHost>

sudo a2ensite git-internal
sudo apache2ctl configtest && sudo systemctl reload apache2

configtest sollte Syntax OK antworten. Testen Sie dies nun von einem Client-Rechner aus:

curl -v https://git.internal.lan/

Sie erhalten eine Fehlermeldung:

curl: (60) SSL certificate problem: self-signed certificate

Dies ist kein Fehler. Das ist die korrekte TLS-Funktionsweise: curl kennt Ihr Zertifikat nicht und verweigert die Kommunikation mit einem Server, der nicht authentifiziert werden kann. Der nächste Abschnitt enthält die tatsächliche Lösung – und das ist nicht die Methode, die die Hälfte des Internets in diesem Moment verwendet.

Vertrauen der Clients sicherstellen — und zu vermeidende Anti-Patterns

Zuerst die falschen Lösungen, benannt nach ihrem Charakter. curl -k (oder --insecure) in einem Script eingebettet, verify=False in Python requests, NODE_TLS_REJECT_UNAUTHORIZED=0 in Node — keine dieser Methoden macht Ihr Zertifikat vertrauenswürdig. Sie deaktivieren die Zertifikatsprüfung, was bedeutet, dass der Client ohne Vorbehalt mit jedem Server kommuniziert, der ein beliebiges Zertifikat vorlegt, einschließlich eines Zertifikats, das ein Angreifer eingeschleust hat. Sie behalten den Overhead von TLS bei, verlieren aber die Authentifizierung, die eigentlich der Zweck war. Schlimmer noch, diese Flags verbreiten sich: Sie werden in einen cron job kopiert, dann in ein Deploy-Script, dann in den Produktionscode, bis niemand mehr weiß, welche Verbindungen temporär sein sollten. Wenn ein verify=False über die Debugging-Session hinaus bestehen bleibt, ist das Design fehlerhaft.

Die richtige Lösung besteht darin, jedem Client-Betriebssystem mitzuteilen, dass dieses Zertifikat ein vertrauenswürdiges Root-Zertifikat ist. Auf Ubuntu- und Debian-Clients:

sudo cp git.internal.crt /usr/local/share/ca-certificates/git.internal.crt
sudo update-ca-certificates

Die relevante Zeile in der Ausgabe (ein Running hooks in /etc/ca-certificates/update.d... Block folgt darauf):

Updating certificates in /etc/ssl/certs...
1 added, 0 removed; done.

Zwei Fallstricke verbergen sich in diesen Zeilen. Die Datei muss auf .crt enden — eine .pem Erweiterung wird stillschweigend ignoriert und Sie erhalten 0 added ohne Fehlermeldung. Zudem muss der Inhalt im PEM-Format vorliegen — die Datei beginnt mit -----BEGIN CERTIFICATE-----; konvertieren Sie eine DER-Binärdatei zuerst mit openssl x509 -inform der -in file.der -out file.crt. Das Hinzufügen des selbstsignierten Zertifikats selbst als Root funktioniert, da ein selbstsigniertes Zertifikat sein eigenes Root ist.

Danach vertrauen curl, wget, git, apt und alle anderen Anwendungen, die OpenSSL gegen den System-Bundle verwenden, dem Server ohne jegliche Flags. Einige Clients nutzen eigene Trust-Stores und erfordern eine individuelle Behandlung:

• Chrome/Chromium unter Linux liest eine NSS-Datenbank, nicht den System-Store: sudo apt install libnss3-tools, dann certutil -d sql:$HOME/.pki/nssdb -A -t "C,," -n "git.internal" -i git.internal.crt pro Benutzer.
• Firefox hat einen eigenen Store: Einstellungen → Datenschutz & Sicherheit → Zertifikate → Importieren, oder setzen Sie security.enterprise_roots.enabled auf true in about:config, damit der System-Store gelesen wird.
• Python requests nutzt ein eigenes CA-Bundle (certifi) und ignoriert den System-Store: übergeben Sie verify="/usr/local/share/ca-certificates/git.internal.crt" oder exportieren Sie REQUESTS_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt.
• Node.js: exportieren Sie NODE_EXTRA_CA_CERTS=/usr/local/share/ca-certificates/git.internal.crt.

Auf Windows-Clients: Doppelklicken Sie auf die .crt und installieren Sie diese unter Vertrauenswürdige Stammzertifikate; unter macOS: Fügen Sie das Zertifikat im Schlüsselbund der Schlüsselbundverwaltung hinzu und markieren Sie es als Immer vertrauen.

Ein Root-Zertifikat für viele Dienste: eine kleine private CA

Vertrauen auf Zertifikatsebene lässt sich nicht skalieren: sechs Dienste multipliziert mit vier Client-Maschinen ergibt vierundzwanzig Installationen, und jeder neue Dienst erhöht diesen Wert. Die Lösung ist eine private CA — Clients vertrauen einem Root-Zertifikat, und Sie signieren jedes Dienst-Zertifikat mit diesem.

Die benutzerfreundliche Option ist mkcert. Dieses Paket ist in den Ubuntu 24.04 Repositories enthalten und verwaltet die NSS-Stores (Chrome, Firefox), die von update-ca-certificates nicht unterstützt werden:

sudo apt install -y mkcert libnss3-tools
mkcert -install
mkcert git.internal.lan "*.internal.lan" 10.8.0.1

mkcert -install erstellt ein Root-Zertifikat und registriert es in jedem Trust-Store auf dieser Maschine; der dritte Befehl gibt git.internal.lan+2.pem und git.internal.lan+2-key.pem aus, welche direkt in die oben genannten nginx- oder Apache-Snippets eingefügt werden können. Das Design setzt eine Entwicklungsmaschine voraus — der Root-Key verbleibt auf der Maschine, auf der -install ausgeführt wurde. Daher ist es ideal für einen Dev-Laptop, aber ungeeignet für eine Server-Flotte.

Für Server erledigt Standard-OpenSSL die gesamte CA-Funktion mit fünf Befehlen:

openssl genrsa -out lab-ca.key 4096
openssl req -x509 -new -key lab-ca.key -sha256 -days 3650 \
  -out lab-ca.crt -subj "/CN=Lab Internal CA" \
  -addext "basicConstraints=critical,CA:TRUE,pathlen:0" \
  -addext "keyUsage=critical,keyCertSign,cRLSign"
openssl genrsa -out git.key 2048
openssl req -new -key git.key -out git.csr -subj "/CN=git.internal.lan" \
  -addext "subjectAltName=DNS:git.internal.lan,IP:10.8.0.1"
openssl x509 -req -in git.csr -CA lab-ca.crt -CAkey lab-ca.key \
  -CAcreateserial -days 730 -sha256 -copy_extensions copy -out git.crt

Die Falle liegt im letzten Befehl: openssl x509 -req entfernt standardmäßig alle Extensions aus dem CSR, einschließlich der von Ihnen hinzugefügten SANs. -copy_extensions copy (eine OpenSSL 3.x Option, daher unter 24.04 verfügbar) überträgt diese; lassen Sie die Option weg, enthält das signierte Zertifikat keine SANs und Chrome zeigt erneut NET::ERR_CERT_COMMON_NAME_INVALID an. Überprüfen Sie dies mit derselben openssl x509 -noout -ext subjectAltName Prüfung wie zuvor.

Verteilen Sie lab-ca.crt über die oben beschriebenen Trust-Store-Schritte an die Clients — nur einmal pro Maschine erforderlich. Schützen Sie lab-ca.key wie einen Schatz: nutzen Sie die Berechtigung 600 und bewahren Sie ihn idealerweise auf einer Maschine auf, die nicht zu den signierten Servern gehört, da jeder Besitzer damit Zertifikate für beliebige Namen erstellen kann, denen Ihre Clients vertrauen.

Ablauf und Rotation

Die Laufzeiten von öffentlichen CA-Zertifikaten verkürzen sich — das CA/Browser Forum hat die maximale Dauer für neu ausgestellte, öffentlich vertrauenswürdige Zertifikate im März 2026 auf 200 Tage begrenzt (vorher 398 Tage). Im Jahr 2027 sinkt dieser Wert auf 100 Tage und bis März 2029 auf 47 Tage. Diese Regeln gelten jedoch nur für öffentlich vertrauenswürdige CAs. Ihre private CA unterliegt diesen Regeln nicht, und Browser erzwingen diese Einschränkungen nicht bei manuell installierten Root-Zertifikaten. Eine reale Einschränkung besteht jedoch: Apple-Plattformen lehnen jedes TLS-Serverzertifikat ab, das länger als 825 Tage gültig ist, unabhängig vom Aussteller. Wenn iPhones oder Macs eine Verbindung herstellen sollen, halten Sie die Leaf-Zertifikate auf maximal zwei Jahre. -days 730 erfüllt diese Anforderung überall; eine zehnjährige Root-CA mit zweijährigen Leaf-Zertifikaten ist eine sichere interne Konfiguration.

Langlaufende Zertifikate scheitern auf nur eine Weise: Sie laufen lautlos und gleichzeitig an einem Datum ab, das niemand geplant hat. Prüfen Sie Ihren Bestand:

openssl x509 -in /etc/ssl/certs/git.internal.crt -noout -enddate

Tragen Sie die Erneuerung in einen Kalender ein oder nutzen Sie cron für eine Erinnerung 30 Tage vor Ablauf — openssl x509 -checkend 2592000 -in cert.crt gibt einen Exit-Code ungleich Null aus, sobald der Ablauf innerhalb dieser Sekunden liegt. Falls Sie bereits Uptime Kuma zur Statusüberwachung nutzen, melden die HTTPS-Monitore das bevorstehende Zertifikatsablauf kostenlos.

Die Rotation mit einer privaten CA ist unkompliziert: Führen Sie die CSR-und-Signieren-Befehle erneut aus, tauschen Sie die Dateien aus und laden Sie den Webserver neu. Da sich die Root-CA nicht geändert hat, bemerken die Clients keine Änderung.

Fehlerursachen und die angezeigten Meldungen

NET::ERR_CERT_AUTHORITY_INVALID — der erwartete Zustand vor der Installation des Vertrauensstatus; kein Defekt am Zertifikat. Wenn dieser Fehler bestehen bleibt, nachdem Sie das Root-Zertifikat installiert haben: Unter Linux liest Chrome den NSS-Store anstelle des System-Stores (siehe Schritt certutil); oder die kopierte Datei endete nicht auf .crt und update-ca-certificates meldete 0 added; oder der Server präsentiert ein anderes Zertifikat als das vertrauenswürdige — vergleichen Sie die Fingerprints mit openssl s_client -connect git.internal.lan:443 </dev/null 2>/dev/null | openssl x509 -noout -fingerprint -sha256.

NET::ERR_CERT_COMMON_NAME_INVALID — das Zertifikat besitzt kein SAN, oder das SAN deckt den Namen in der Adresszeile nicht ab. Der klassische Fall: Das SAN listet DNS:git.internal.lan auf, aber der Benutzer hat https://10.8.0.1 aufgerufen. Änderungen am Trust-Store beheben dies nicht; stellen Sie das Zertifikat mit dem fehlenden Eintrag neu aus.

curl: (60) SSL certificate problem: self-signed certificate — curl vertraut dem Zertifikat nicht. Die Variante self-signed certificate in certificate chain bedeutet dasselbe für ein von Ihrer privaten CA signiertes Zertifikat. Einmalige Lösung: curl --cacert lab-ca.crt https://...; dauerhafte Lösung: der Trust-Store. Nicht -k.

unable to load certificate ... Expecting: TRUSTED CERTIFICATE (oder Expecting: CERTIFICATE REQUEST, oder no start line) — PEM-Konfusionsfehler. Sie haben OpenSSL den falschen Dateityp übergeben: einen Key oder CSR anstelle eines Zertifikats, oder ein DER-Binärformat anstelle von PEM. head -1 filename zeigt den tatsächlichen Dateityp an — ein Zertifikat beginnt mit -----BEGIN CERTIFICATE-----. Konvertieren Sie DER-Dateien mit openssl x509 -inform der -in file.der -out file.crt.

nginx: [emerg] SSL_CTX_use_PrivateKey_file(...) failed (SSL: error ... key values mismatch) — das Zertifikat und der Key gehören nicht zusammen. Dies geschieht meist, wenn der Befehl zur Generierung zweimal ausgeführt wurde und die Dateien vertauscht wurden. Prüfen Sie dies mit openssl x509 -in git.internal.crt -noout -pubkey | sha256sum im Vergleich zu openssl pkey -in git.internal.key -pubout | sha256sum; übereinstimmende Hashes bedeuten, dass es sich um ein passendes Paar handelt. Wenn sie abweichen, generieren Sie beide Dateien gemeinsam neu.

FAQ

Warum zeigt Chrome weiterhin "Nicht sicher" an, obwohl ich ein selbstsigniertes Zertifikat erstellt habe?

Wenn der Fehler NET::ERR_CERT_AUTHORITY_INVALID auftritt, ist das Zertifikat korrekt — Chrome hat lediglich noch keinen Grund, ihm zu vertrauen. Installieren Sie das Zertifikat (oder Ihre private CA-Root) im Trust Store des Clients. Beachten Sie, dass Chrome unter Linux die NSS-Datenbank über certutil nutzt und nicht den System-Trust-Store. Wenn der Fehler NET::ERR_CERT_COMMON_NAME_INVALID auftritt, fehlt dem Zertifikat ein Subject Alternative Name, der zur URL passt. Das Zertifikat muss dann mit -addext "subjectAltName=..." neu ausgestellt werden.

Wie kann ich curl dazu bringen, ein selbstsigniertes Zertifikat ohne -k zu vertrauen?

Kopieren Sie das Zertifikat (PEM-Format, Erweiterung .crt) nach /usr/local/share/ca-certificates/ und führen Sie sudo update-ca-certificates aus — die Ausgabe muss 1 added lauten. Danach verifiziert curl das Zertifikat wie jedes öffentliche Zertifikat. Für eine einmalige Anfrage ohne Systemänderungen verifiziert curl --cacert /path/to/cert.crt nur gegen diese Datei; -k deaktiviert die Verifizierung vollständig und sollte nicht in Skripten verwendet werden.

Wie lange kann ein selbstsigniertes Zertifikat gültig sein?

Technisch gesehen so lange wie gewünscht — die Limits des CA/Browser Forums (aktuell 200 Tage, ab 2029 47 Tage) gelten nur für öffentlich vertrauenswürdige CAs, nicht für private Vertrauensstellungen. Begrenzen Sie Server-Zertifikate in der Praxis auf 825 Tage, da Apple-Geräte alles mit einer längeren Laufzeit ablehnen, unabhängig vom Aussteller. Eine zehnjährige private Root-CA mit zweijährigen (-days 730) Leaf-Zertifikaten ist eine sinnvolle Standardkonfiguration; planen Sie die Erneuerung im Kalender ein, da ein abgelaufenes internes Zertifikat Dienste ohne Vorwarnung lahmlegt.

Sollte ich ein selbstsigniertes Zertifikat oder Let's Encrypt verwenden?

Wenn der Dienst einen öffentlichen DNS-Namen hat und aus dem Internet erreichbar ist, nutzen Sie immer Let's Encrypt — es ist kostenlos, automatisiert und von jedem Client bereits vertraut. Selbstsignierte Zertifikate (oder eine private CA) sind für Szenarien gedacht, für die Let's Encrypt keine Zertifikate ausstellen kann: private IPs, rein interne Hostnamen wie .lan, Air-Gapped-Netzwerke und Dienste, die absichtlich hinter einem VPN verborgen werden. Die Entscheidung basiert auf der Erreichbarkeit und Benennung, nicht auf der kryptografischen Stärke — die Verschlüsselung ist identisch.

Warum wird mein Zertifikat abgelehnt, obwohl ich es nach /usr/local/share/ca-certificates hinzugefügt habe?

Prüfen Sie drei Punkte. Die Datei muss auf .crt enden — eine .pem-Erweiterung wird ignoriert und update-ca-certificates meldet 0 added. Der Inhalt muss PEM-Text sein, der mit -----BEGIN CERTIFICATE----- beginnt, nicht DER-Binärformat. Und die Anwendung muss tatsächlich den System-Trust-Store nutzen — Chrome unter Linux, Firefox, Python requests, Node.js und Java nutzen jeweils eigene Trust-Stores und benötigen das Zertifikat separat.