Selbstsigniertes Zertifikat unter Ubuntu 24.04 erstellen

Was Sie erstellen

Ein selbstsigniertes TLS-Zertifikat, das moderne Browser und Clients tatsächlich akzeptieren, mit korrektem subjectAltName, sicheren Dateiberechtigungen und Einbindung in nginx oder Apache. Dazu kommt der Teil, den fast jede Anleitung auslässt: Ihre Clients vertrauen dem Zertifikat ordnungsgemäß, statt Warnungen dauerhaft wegzuklicken und curl -k für immer fest in Skripte einzutragen. Am Ende steht eine private CA mit fünf Befehlen für den Fall, dass aus einem internen Dienst sechs werden.

Zuerst die grundsätzliche Entscheidung: Ein selbstsigniertes Zertifikat ist deutlich seltener das richtige Werkzeug, als es verwendet wird. Wenn der Dienst unter einem echten DNS-Namen aus dem öffentlichen Internet erreichbar ist, lesen Sie nicht weiter. Richten Sie stattdessen ein kostenloses Let's-Encrypt-Zertifikat mit certbot unter nginx oder die entsprechende Variante für Apache ein. Das kostet nichts, erneuert sich automatisch, und jeder Browser weltweit vertraut dem Zertifikat bereits. Ein selbstsigniertes Zertifikat auf einer öffentlichen Website bringt Ihre Benutzer dazu, Sicherheitswarnungen wegzuklicken. Das ist eine schlechtere Gewohnheit als unverschlüsseltes HTTP.

Ein selbstsigniertes Zertifikat ist die richtige Wahl, wenn das öffentliche Internet keine Rolle spielt: für ein Administrationspanel, das an eine WireGuard-Tunneladresse auf Ihrem VPS gebunden ist, einen Staging-Server in einem privaten Netzwerk, den Datenverkehr zwischen Backend-Diensten, ein Gerät im Heimlabor oder als Ersatz für das Platzhalterzertifikat, das Webmin selbst für Port 10000 erzeugt. Let's Encrypt kann für 10.8.0.1 oder git.internal.lan ohnehin keine Zertifikate ausstellen. Keine öffentliche CA nimmt eine private IP-Adresse oder eine erfundene TLD in ein Zertifikat auf. Für diese Namen sind Sie die CA.

Alle folgenden Schritte werden auf einem frisch installierten Ubuntu-24.04-System ausgeführt. Dieses enthält OpenSSL 3.0.x (openssl version zur Bestätigung). Dafür ist kein Internetzugang erforderlich. Die Schritte funktionieren vollständig in einer isolierten Umgebung.

Warum der alte Einzeiler Zertifikate erzeugt, die Chrome ablehnt

Der Befehl, den jedes Tutorial von vor 2017 vorgibt, 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

Er stellt eine Reihe interaktiver Fragen, trägt Ihren Hostnamen in das Feld Common Name ein und erzeugt ein Zertifikat ohne subjectAltName-Erweiterung. Dieses Zertifikat ist damit unbrauchbar. Chrome liest das Feld Common Name seit Version 58 im April 2017 nicht mehr aus. RFC 2818 hatte die Abgleichung über CN bereits im Jahr 2000 als veraltet gekennzeichnet. Firefox, Safari, curl und Python verhalten sich genauso. Ein Zertifikat identifiziert seinen Server entweder über die SAN-Erweiterung oder gar nicht. Der Browser weist Sie mit genau diesem Wortlaut darauf hin:

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 Änderung am Trust Store behebt diesen Fehler, weil das Zertifikat tatsächlich keinen Namen enthält. Wenn Sie gerade NET::ERR_CERT_COMMON_NAME_INVALID sehen, hat Ihr Zertifikat keine SAN-Erweiterung oder die falsche SAN-Erweiterung. Sie müssen ein neues Zertifikat erstellen. Glücklicherweise genügt dafür ein Befehl.

Ein von Browsern akzeptiertes Zertifikat erstellen: ein Befehl

OpenSSL unterstützt das Flag -addext seit Version 1.1.1. Daher sind die Konfigurationsdatei-Umwege älterer Anleitungen zum Einfügen eines SAN nicht mehr erforderlich. Unter 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"

Aufgabe der einzelnen Flags:

• -x509 erzeugt direkt ein selbstsigniertes Zertifikat statt einer Zertifikatsanforderung.
• -newkey rsa:4096 erzeugt im selben Schritt einen neuen Schlüssel. RSA 4096 bereitet auch älteren Clients keine Probleme. Wenn ausschließlich moderne Clients eine Verbindung herstellen, ist -newkey ec -pkeyopt ec_paramgen_curve:P-256 kleiner und schneller.
• -noenc ist die Schreibweise in OpenSSL 3.x für das frühere -nodes: Der Schlüssel erhält keine Passphrase. Beide Schreibweisen funktionieren. Bei einem Schlüssel mit Passphrase wartet nginx bei jedem Start auf eine Eingabe. Für einen Serverschlüssel ist diese Option daher erforderlich.
• -days 730 legt eine Gültigkeit von zwei Jahren fest. Weitere Informationen zu diesem Wert finden Sie im Abschnitt zum Ablaufdatum.
• -subj beantwortet die interaktiven Fragen inline. Der CN ist inzwischen nur noch kosmetisch relevant. Setzen Sie ihn trotzdem auf den primären Namen, da einige Tools ihn anzeigen.
• -addext "subjectAltName=..." ist das entscheidende Flag. Listen Sie jeden Namen und jede IP-Adresse auf, die Clients eingeben werden: DNS:-Einträge für Hostnamen, einschließlich Wildcards wie DNS:*.internal.lan, und IP:-Einträge für Adressen. Wenn jemand https://10.8.0.1 im Browser aufrufen soll, muss der Eintrag IP:10.8.0.1 vorhanden sein. Mit einem ausschließlich auf DNS basierenden SAN erhalten Sie andernfalls erneut NET::ERR_CERT_COMMON_NAME_INVALID.

Prüfen Sie, ob das SAN tatsächlich übernommen wurde, bevor Sie weitere Konfigurationen vornehmen:

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

Wenn stattdessen No extensions in certificate ausgegeben wird, enthält das Zertifikat kein SAN. Browser lehnen es ab. Erzeugen Sie das Zertifikat dann neu, 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 integrieren

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 wirksam wird. Gibt es stattdessen SSL_CTX_use_PrivateKey_file() failed ... key values mismatch aus, stammen Zertifikat und Schlüssel aus zwei verschiedenen Erzeugungsläufen. Siehe den Abschnitt zu den Fehlerbildern.

Apache damit verbinden

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 auf Syntax OK antworten. Testen Sie nun von einem Client-Rechner aus:

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

Dabei wird ein Fehler angezeigt:

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

Das ist kein Fehler in der Konfiguration. So funktioniert TLS: curl kennt Ihr Zertifikat nicht und verweigert die Verbindung zu einem Server, den es nicht authentifizieren kann. Der nächste Abschnitt beschreibt die eigentliche Lösung. Sie entspricht nicht der Vorgehensweise, die viele Anleitungen derzeit empfehlen.

Vertrauen auf Clients herstellen und zu vermeidende Anti-Patterns

Zuerst die falschen Korrekturen, klar benannt. curl -k (oder --insecure) fest in ein Skript eingebaut, verify=False in Python requests und NODE_TLS_REJECT_UNAUTHORIZED=0 in Node: Keine dieser Maßnahmen sorgt dafür, dass Ihr Zertifikat als vertrauenswürdig gilt. Sie schalten die Zertifikatsprüfung aus. Dadurch kommuniziert der Client bereitwillig mit jedem Server, der irgendein Zertifikat präsentiert, auch mit einem Zertifikat, das ein Angreifer in den Verbindungsweg eingeschleust hat. Der zusätzliche Aufwand von TLS bleibt bestehen, aber die Authentifizierung, der TLS eigentlich dient, geht verloren. Noch problematischer ist, dass sich diese Flags verbreiten: Sie werden in einen Cronjob kopiert, anschließend in ein Deploy-Skript und schließlich in Produktivcode, bis niemand mehr weiß, welche Verbindungen ursprünglich nur vorübergehend so konfiguriert werden sollten. Wenn ein verify=False die Debugging-Sitzung überlebt, durch die es entstanden ist, ist der Entwurf falsch.

Die richtige Lösung besteht darin, dem Betriebssystem jedes Clients beizubringen, dass dieses Zertifikat eine vertrauenswürdige Root-Zertifizierungsstelle 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 (darauf folgt ein Running hooks in /etc/ca-certificates/update.d...-Block) lautet:

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

In diesen Zeilen verbergen sich zwei typische Fehlerquellen. Die Datei muss mit .crt enden. Eine Erweiterung .pem wird stillschweigend ignoriert, und Sie erhalten 0 added ohne Fehlermeldung. Außerdem muss der Inhalt im PEM-Format vorliegen; die Datei beginnt mit -----BEGIN CERTIFICATE-----. Konvertieren Sie eine DER-Binärdatei vorher mit openssl x509 -inform der -in file.der -out file.crt. Das Hinzufügen des selbstsignierten Zertifikats selbst als Root funktioniert, weil ein selbstsigniertes Zertifikat seine eigene Root-Zertifizierungsstelle ist.

Danach vertrauen curl, wget, git, apt und alle anderen Programme, die OpenSSL mit dem systemweiten Zertifikatsspeicher verwenden, dem Server ohne zusätzliche Flags. Einige Clients bringen eigene Trust Stores mit und müssen einzeln konfiguriert werden:

• Chrome/Chromium unter Linux verwendet eine NSS-Datenbank und nicht den systemweiten Zertifikatsspeicher: sudo apt install libnss3-tools, danach je Benutzer certutil -d sql:$HOME/.pki/nssdb -A -t "C,," -n "git.internal" -i git.internal.crt.
• Firefox verfügt über einen eigenen Zertifikatsspeicher: Einstellungen → Datenschutz & Sicherheit → Zertifikate → Importieren. Alternativ setzen Sie security.enterprise_roots.enabled in about:config auf true, damit Firefox den systemweiten Zertifikatsspeicher verwendet.
• Python requests bringt ein eigenes CA-Bundle (certifi) mit und ignoriert den systemweiten Zertifikatsspeicher: Ü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.

Öffnen Sie auf Windows-Clients .crt per Doppelklick und installieren Sie es unter Vertrauenswürdige Stammzertifizierungsstellen. Fügen Sie es unter macOS in der Schlüsselbundverwaltung zum System-Schlüsselbund hinzu und markieren Sie es als Immer vertrauen.

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

Das Vertrauen pro Zertifikat skaliert sofort nicht mehr: Sechs Dienste auf vier Client-Rechnern erfordern 24 Vertrauensinstallationen, und jeder neue Dienst erhöht den Aufwand. Die Lösung ist eine private CA. Die Clients vertrauen einer Root-CA, und Sie signieren das Zertifikat jedes Dienstes damit.

Die komfortable Option ist mkcert. Sie ist in den Ubuntu-24.04-Repositorys enthalten und verwaltet die NSS-Speicher von Chrome und Firefox, die update-ca-certificates nicht berücksichtigt:

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

mkcert -install erstellt eine Root-CA und registriert sie in jedem Truststore dieses Rechners. Der dritte Befehl erzeugt git.internal.lan+2.pem und git.internal.lan+2-key.pem, die Sie direkt in die obigen nginx- oder Apache-Snippets übernehmen können. Das Design setzt einen Entwicklungsrechner voraus. Der Root-Schlüssel liegt auf dem Rechner, auf dem -install ausgeführt wurde. Für einen Entwicklungs-Laptop ist das ideal, für eine Serverflotte jedoch ungeeignet.

Für Server erledigt OpenSSL die gesamte CA-Erstellung 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 Erweiterungen aus der CSR, einschließlich des SAN, das Sie sorgfältig hinzugefügt haben. -copy_extensions copy ist eine Option von OpenSSL 3.x und funktioniert daher auf 24.04. Sie übernimmt die Erweiterungen. Lassen Sie die Option weg, enthält das signierte Zertifikat keinen SAN, und Chrome zeigt wieder NET::ERR_CERT_COMMON_NAME_INVALID an. Prüfen Sie das mit derselben openssl x509 -noout -ext subjectAltName-Prüfung wie zuvor.

Verteilen Sie lab-ca.crt über die oben beschriebenen Truststore-Schritte an die Clients, einmalig pro Rechner. Schützen Sie lab-ca.key entsprechend streng: mit Modus 600 und idealerweise auf einem Rechner, der nicht zu den Servern gehört, für die die CA Zertifikate signiert. Wer diesen Schlüssel besitzt, kann ein Zertifikat für jeden Namen ausstellen, dem Ihre Clients vertrauen.

Ablauf und Rotation

Die Gültigkeitsdauer öffentlich vertrauenswürdiger CA-Zertifikate wird immer kürzer. Das CA/Browser Forum hat die Gültigkeit neu ausgestellter, öffentlich vertrauenswürdiger Zertifikate im März 2026 auf 200 Tage begrenzt, gegenüber zuvor 398 Tagen. 2027 sinkt das Limit auf 100 Tage und bis März 2029 auf 47 Tage. Diese Regeln gelten jedoch für öffentlich vertrauenswürdige CAs. Ihre private CA ist daran nicht gebunden, und Browser setzen diese Fristen für manuell installierte Root-Zertifikate nicht durch. Eine praktische Einschränkung gilt dennoch: Apple-Plattformen lehnen jedes TLS-Serverzertifikat mit einer Gültigkeit von mehr als 825 Tagen ab, unabhängig vom Aussteller. Wenn iPhones oder Macs eine Verbindung herstellen, sollten Sie Leaf-Zertifikate daher auf höchstens zwei Jahre begrenzen. -days 730 erfüllt diese Vorgabe überall. Eine zehnjährige Root-CA mit zweijährigen Leaf-Zertifikaten ist eine geeignete interne Struktur.

Langfristig gültige Zertifikate fallen auf genau eine Weise aus: stillschweigend und gleichzeitig an einem Datum, an dessen Festlegung sich niemand mehr erinnert. Prüfen Sie Ihre Zertifikate:

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

Tragen Sie die Erneuerung in einen tatsächlichen Kalender ein, oder lassen Sie sich 30 Tage vorher von cron erinnern. openssl x509 -checkend 2592000 -in cert.crt liefert einen Exit-Status ungleich null, sobald der Ablauf innerhalb dieser Anzahl von Sekunden liegt. Wenn Sie bereits Uptime Kuma zur Statusüberwachung einsetzen, weisen dessen HTTPS-Monitore kostenlos auf einen bevorstehenden Zertifikatsablauf hin.

Die Rotation mit einer privaten CA ist angenehm unspektakulär: Führen Sie die CSR- und Signierbefehle erneut aus, tauschen Sie die Dateien aus und laden Sie den Webserver neu. Die Root-CA hat sich nicht geändert. Daher bemerkt kein Client den Austausch.

Fehlerbilder und die angezeigten Meldungen

NET::ERR_CERT_AUTHORITY_INVALID ist der erwartete Zustand, bevor Sie eine Vertrauensstellung installieren. Es handelt sich nicht um einen Fehler im Zertifikat. Wenn der Zustand nach der Installation der Root-CA bestehen bleibt: Unter Linux verwendet Chrome den NSS-Speicher statt des Systemspeichers (siehe Schritt certutil); oder die kopierte Datei endete nicht mit .crt und update-ca-certificates meldete 0 added; oder der Server präsentiert ein anderes Zertifikat als das, dem Sie vertraut haben. Vergleichen Sie die Fingerabdrücke 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 bedeutet, dass das Zertifikat keinen SAN enthält oder der SAN den Namen in der Adressleiste nicht abdeckt. Der typische Fall: Im SAN steht DNS:git.internal.lan, der Benutzer hat aber https://10.8.0.1 aufgerufen. Änderungen am Vertrauensspeicher können diesen Fehler nicht beheben. Stellen Sie das Zertifikat mit dem fehlenden Eintrag neu aus.

curl: (60) SSL certificate problem: self-signed certificate bedeutet, dass curl dem Zertifikat nicht vertraut. Die Variante self-signed certificate in certificate chain hat dieselbe Bedeutung für ein von Ihrer privaten CA signiertes Zertifikat. Einmalige Lösung: curl --cacert lab-ca.crt https://.... Dauerhafte Lösung: der Vertrauensspeicher. Verwenden Sie nicht -k.

unable to load certificate ... Expecting: TRUSTED CERTIFICATE (oder Expecting: CERTIFICATE REQUEST oder no start line) weist auf eine PEM-Verwechslung hin. Sie haben OpenSSL den falschen Dateityp übergeben: einen Schlüssel oder eine CSR, obwohl ein Zertifikat erwartet wurde, oder eine DER-Binärdatei, obwohl PEM erwartet wurde. head -1 filename zeigt, welchen Typ die Datei tatsächlich hat. Ein Zertifikat beginnt mit -----BEGIN CERTIFICATE-----. Für DER konvertieren Sie die Datei mit openssl x509 -inform der -in file.der -out file.crt.

nginx: [emerg] SSL_CTX_use_PrivateKey_file(...) failed (SSL: error ... key values mismatch) bedeutet, dass Zertifikat und Schlüssel nicht zusammengehören. Ursache ist meist, dass der Generierungsbefehl zweimal ausgeführt wurde und die Dateien vertauscht wurden. Prüfen Sie openssl x509 -in git.internal.crt -noout -pubkey | sha256sum im Vergleich zu openssl pkey -in git.internal.key -pubout | sha256sum. Übereinstimmende Hashes bedeuten, dass das Paar zusammenpasst. Wenn sie abweichen, erzeugen Sie beide Dateien gemeinsam neu.

FAQ

Warum zeigt Chrome weiterhin „Nicht sicher“ an, nachdem ich ein selbstsigniertes Zertifikat erstellt habe?

Wenn der Fehler NET::ERR_CERT_AUTHORITY_INVALID lautet, ist das Zertifikat in Ordnung. Chrome hat bisher lediglich keinen Grund, ihm zu vertrauen. Installieren Sie es oder die Root-CA Ihrer privaten CA im Truststore des Clients. Beachten Sie außerdem, dass Chrome unter Linux über certutil die NSS-Datenbank verwendet und nicht den System-Truststore. Wenn der Fehler NET::ERR_CERT_COMMON_NAME_INVALID lautet, fehlt dem Zertifikat ein Subject Alternative Name, der zur URL passt. Das Zertifikat muss mit -addext "subjectAltName=..." neu ausgestellt werden.

Wie kann ich curl dazu bringen, einem selbstsignierten Zertifikat ohne -k zu vertrauen?

Kopieren Sie das Zertifikat im PEM-Format mit der Erweiterung .crt nach /usr/local/share/ca-certificates/ und führen Sie sudo update-ca-certificates aus. Die Ausgabe muss 1 added enthalten. Danach prüft curl das Zertifikat wie jedes öffentlich vertrauenswürdige Zertifikat. Für eine einzelne Anfrage, ohne das System zu ändern, prüft curl --cacert /path/to/cert.crt ausschließlich anhand dieser Datei. -k deaktiviert die Prüfung vollständig und gehört in kein Skript.

Wie lange kann ein selbstsigniertes Zertifikat gültig sein?

Technisch können Sie eine beliebige Gültigkeitsdauer festlegen. Die Beschränkungen des CA/Browser Forum, derzeit 200 Tage und bis 2029 47 Tage, gelten für öffentlich vertrauenswürdige CAs und nicht für private Vertrauensstellungen. In der Praxis sollten Sie Serverzertifikate auf 825 Tage begrenzen, weil Apple-Geräte unabhängig vom Aussteller längere Laufzeiten ablehnen. Eine private Root-CA mit einer Gültigkeit von zehn Jahren und zweijährigen Leaf-Zertifikaten (-days 730) ist ein sinnvoller Standard. Planen Sie die Erneuerung trotzdem ein, weil ein abgelaufenes internes Zertifikat an einem Datum, an das sich niemand erinnert, unbemerkt alle Dienste außer Betrieb setzen kann.

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

Wenn der Dienst über einen öffentlichen DNS-Namen verfügt und aus dem Internet erreichbar ist, verwenden Sie immer Let's Encrypt: Die Zertifikate sind kostenlos, werden automatisch ausgestellt und von jedem Client bereits vertraut. Selbstsignierte Zertifikate oder eine private CA sind für Fälle vorgesehen, in denen Let's Encrypt keine Zertifikate ausstellen kann: private IP-Adressen, ausschließlich interne Hostnamen wie .lan, vom Internet getrennte Netzwerke und Dienste, die bewusst hinter einem VPN verborgen sind. Die Entscheidung hängt von Erreichbarkeit und Namensgebung ab, nicht von der kryptografischen Stärke. Die Kryptografie ist identisch.

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

Prüfen Sie drei Punkte. Der Dateiname muss mit .crt enden. Eine Erweiterung .pem wird stillschweigend übersprungen, und update-ca-certificates meldet 0 added. Der Inhalt muss PEM-Text sein und mit -----BEGIN CERTIFICATE----- beginnen, nicht eine DER-Binärdatei. Außerdem muss die Anwendung tatsächlich den System-Truststore verwenden. Chrome unter Linux, Firefox, Python requests, Node.js und Java verwalten jeweils einen eigenen Truststore. Das Zertifikat muss dort separat hinzugefügt werden.