Generator für selbstsignierte Zertifikate

Ein Zertifikat und sein privater Schlüssel für einen internen Dienst, ohne sich eine openssl-Beschwörung merken zu müssen: Geben Sie den Common Name ein, listen Sie jeden Namen und jede IP auf, die das Zertifikat abdecken muss, wählen Sie Gültigkeit und Schlüsselgröße und laden Sie beide PEM-Dateien herunter. Schlüssel werden lokal in Ihrem Browser erzeugt und nie hochgeladen — diese Seite stellt überhaupt keine Netzwerkanfrage, und der Schlüssel existiert nur in Ihrem Tab, bis Sie ihn speichern.

Größere Schlüssel brauchen länger: 4096 Bit kann auf einer bescheidenen Maschine eine Weile dauern. Die Arbeit geschieht auf Ihrer Maschine, in diesem Tab — lassen Sie ihn offen und lassen Sie ihn fertig werden.

Wozu ein selbstsigniertes Zertifikat gut ist

Ein selbstsigniertes Zertifikat ist ein Zertifikat, dessen Issuer und Subject identisch sind: Es bürgt für sich selbst. Das klingt nach einem Fehler, und für das öffentliche Web ist es einer — der Browser eines Besuchers hat keinen Grund, dem Wort eines Fremden zu glauben. Aber ein großer Teil von TLS steht der Öffentlichkeit nie gegenüber: interne Dashboards, Labor- und Staging-Umgebungen, Dienste im Heimlabor, Verwaltungsoberflächen von Netzwerkgeräten und das Dienst-zu-Dienst-Gespräch innerhalb einer Organisation. Dort ist das Publikum Maschinen, die Sie kontrollieren, und die Vertrauensfrage hat eine andere Antwort: Sie installieren das Zertifikat (oder Ihre eigene kleine CA) einmal, absichtlich, in die Vertrauensspeicher, die Sie verwalten. Im Gegenzug erhalten Sie Verschlüsselung und Identität innerhalb Ihrer eigenen Mauern, ohne dass eine öffentliche CA je Ihre internen Hostnamen erfährt — Namen, die selbst eine Karte Ihrer Infrastruktur sind.

Das Erzeugungsritual war früher ein openssl-Befehl, den sich niemand merken konnte und den jeder kopierte, mit SANs, die über eine Konfigurationsdatei angeflanscht wurden, weil es die Option dafür in älteren Versionen nicht gab. Diese Seite existiert, damit die Form des Zertifikats stattdessen sichtbar ist: Die Namen sind eine Liste, die Sie lesen können, die Gültigkeit ist eine Anzahl von Tagen, die Sie in dem Wissen wählen, dass sie ablaufen wird, und die Schlüsselgröße ist eine Entscheidung statt eines Standardwerts, den Sie nie bemerkt haben. Was sie absichtlich nicht tut, ist, sich als CA auszugeben: Es gibt keine Kette, kein Intermediate, nichts zu widerrufen. Ein Dienst, ein Zertifikat, ein Ablaufdatum, das man im Blick behalten muss.

Clients dazu bringen, es zu akzeptieren

Das Zertifikat zu erzeugen ist die einfache Hälfte; Vertrauen ist die Bereitstellung. Auf einer Handvoll eigener Maschinen beendet das Hinzufügen des Zertifikats zum Vertrauensspeicher des Betriebssystems (oder des Browsers) die Warnungen endgültig, und Werkzeuge wie curl und git akzeptieren einen --cacert-Zeiger pro Befehl statt der gefährlichen Gewohnheit, die Verifizierung abzuschalten — das Flag -k trainiert alle darin, genau die Warnung zu ignorieren, die einen echten Angriff erwischen würde. Wenn das Publikum über eine Handvoll Maschinen hinauswächst, steigen Sie von einzelnen selbstsignierten Zertifikaten auf eine kleine private CA um: Signieren Sie Dienstzertifikate mit ihr, verteilen Sie nur das CA-Zertifikat, und die Rotation hört auf, eine Tour durch jeden Client zu sein. Und wenn sich ein Dienst doch als öffentlich herausstellt, ersetzen Sie das Zertifikat durch ein öffentlich vertrauenswürdiges — der SSL-Prüfer verifiziert, was ein Server tatsächlich vorzeigt, sobald er live ist, und das ist der Moment, in dem Selbstsigniert keine Wahl mehr ist.

Verwandte Werkzeuge: Lesen Sie beliebige Zertifikate mit dem SSL-Zertifikatsparser wieder ein oder prüfen Sie mit dem SSL-Prüfer, was ein Live-Server vorzeigt.

Weiterführende Lektüre: eine Zuverlässigkeitsroutine — warum interne Zertifikate und ihre Ablaufdaten auf dieselbe Planungsseite gehören wie Rotationen und Backups.

Die Zertifikatserzeugung nutzt node-forge, verwendet unter der BSD-3-Clause-Lizenz und nur geladen, wenn Sie auf Erzeugen drücken. Kein Teil dieses Werkzeugs stellt eine Netzwerkanfrage.

Häufige Fragen

Wo sollte ich ein selbstsigniertes Zertifikat verwenden?

Bei Dingen, mit denen nur Sie und Ihre eigenen Systeme sprechen: interne Dashboards, Labor- und Staging-Umgebungen, Dienste im Heimlabor, Verwaltungsseiten von Geräten und als Platzhalter, der einem Server das Starten erlaubt, bevor ein echtes Zertifikat ausgestellt ist. Die Regel ist die Reichweite: Wenn der Browser eines Fremden es je sehen wird, braucht es stattdessen ein öffentlich vertrauenswürdiges Zertifikat — die gibt es kostenlos bei Let’s Encrypt.

Warum warnen Browser vor selbstsignierten Zertifikaten?

Weil „selbstsigniert“ bedeutet, dass der Einzige, der für das Zertifikat bürgt, es selbst ist. Die Verschlüsselung funktioniert — die Verbindung ist privat —, aber nichts beweist, dass der Server der ist, für den er sich ausgibt, und das ist die Hälfte von TLS, die normalerweise eine Zertifizierungsstelle liefert. Browser warnen daher, bis das Zertifikat (oder eine CA, die Sie kontrollieren) in den Vertrauensspeicher der Maschinen aufgenommen wird, die es verwenden.

Warum erscheint der Common Name auch in der SAN-Liste?

Moderne Browser ignorieren das Feld Common Name vollständig und prüfen stattdessen die Liste der Subject Alternative Names. Ein Zertifikat, dessen Hauptname nicht in seiner eigenen SAN-Liste steht, scheitert an genau dem Namen, für den es gemacht wurde — der häufigste Fehler bei Selbstsignierung —, also fügt diese Seite den Common Name immer zu den SANs hinzu.

Reichen 2048 Bit RSA, oder sollte ich 4096 wählen?

2048 Bit RSA ist die aktuelle Basis und für interne Dienste in Ordnung; es ist das, was die meisten öffentlichen Zertifikate noch verwenden. 4096 Bit kaufen Spielraum gegen künftige Kryptoanalyse um den Preis langsamerer Erzeugung und etwas langsamerer Handshakes. Es ergibt Sinn für eine langlebige interne CA oder einen Dienst, den Sie nicht leicht neu ausstellen können. Die Erzeugung geschieht in jedem Fall auf Ihrer eigenen Maschine — 4096 Bit kann eine Weile dauern, und der Tab arbeitet, er ist nicht eingefroren.

Ist es sicher, einen privaten Schlüssel in einer Webseite zu erzeugen?

Auf dieser Seite ja, wegen der Art, wie sie gebaut ist: Das Schlüsselpaar wird lokal in Ihrem Browser mit der Bibliothek node-forge erzeugt, die Seite stellt überhaupt keine Netzwerkanfrage, und nichts, was Sie erzeugen, wird hochgeladen, protokolliert oder gespeichert. Die allgemeine Gewohnheit lohnt sich trotzdem: Erzeugen Sie Schlüssel nur auf Seiten (und Maschinen), denen Sie vertrauen, und behandeln Sie die Datei des privaten Schlüssels ab dem Moment, in dem sie existiert, als Geheimnis.