Wie man einen CSR für ein Code Signing-Zertifikat über MMC generiert

Das Zertifikate-Snap-In in der Microsoft Management Console (MMC) kann auf einem Windows-Rechner eine PKCS #10-Zertifikatsanforderung ohne zusätzliche Software erstellen. Diese Anleitung führt Bildschirm für Bildschirm durch diesen Assistenten für ein Code-Signing-Zertifikat und beginnt mit dem Teil, den ältere Anleitungen meist auslassen: Die Regeln für private Schlüssel bei Code Signing haben sich am 1. Juni 2023 geändert, und sie entscheiden darüber, ob eine MMC-Anforderung überhaupt verwendbar ist.

Lesen Sie diese Anforderung, bevor Sie den Assistenten öffnen. Der Rest der Anleitung setzt voraus, dass Sie wissen, welchen Weg Ihre Bestellung nimmt.

Code-Signing-Schlüssel müssen auf Hardware erzeugt werden

Gemäß den CA/Browser Forum Code Signing Baseline Requirements, die seit dem 1. Juni 2023 gelten, muss der private Schlüssel für jedes öffentlich vertrauenswürdige Code-Signing-Zertifikat in einem Hardware-Kryptomodul erzeugt, gespeichert und verwendet werden, das mindestens nach FIPS 140-2 Level 2, Common Criteria EAL 4+ oder einem gleichwertigen Standard zertifiziert ist. Dies gilt sowohl für Standardzertifikate (Organization Validation und Individual Validation) als auch für Extended Validation. Bei EV-Code-Signing war dies bereits so geregelt; die Änderung von 2023 hat dieselbe Regel auf die Standardprodukte ausgeweitet.

Die Anforderungen legen auch den Schlüssel selbst fest. RSA-Schlüssel müssen mindestens 3072 Bit haben, ECDSA-Schlüssel müssen NIST P-256, P-384 oder P-521 verwenden, und SHA-1 ist für Code-Signing-Zertifikate nicht zulässig.

Ebenso wichtig ist, dass die Zertifizierungsstelle nachweisen muss, dass sich der Schlüssel tatsächlich in Hardware befindet, wobei eine der in den Anforderungen aufgeführten Methoden verwendet wird. In der Praxis sind dies die Methoden, denen Sie begegnen werden:

• Die CA schickt Ihnen ein Hardware-Token, das bereits ein von der CA auf diesem Gerät erzeugtes Schlüsselpaar enthält.
• Sie gegenzeichnen die Anforderung mit einem Herstellerzertifikat, was genau das bedeutet, was man unter Key Attestation versteht: der Nachweis, dass der Schlüssel auf nicht exportierbare Weise innerhalb eines konformen Geräts erzeugt wurde.
• Sie verwenden eine Kombination aus Krypto-Bibliothek und Hardwaremodul, die von der CA vorgeschrieben wird.
• Sie legen ein IT-Audit, einen Bericht eines Cloud-Key-Protection-Dienstes oder eine Vereinbarung vor, die Sie über einen konformen Signierdienst unterzeichnen.

Keine dieser Bedingungen wird durch eine Anforderung erfüllt, die MMC gegen den Microsoft Software Key Storage Provider erstellt. Dieser Provider erzeugt den Schlüssel im Windows-Software-Speicher, sodass die resultierende Anforderung für ein öffentlich vertrauenswürdiges Code-Signing-Zertifikat abgelehnt wird, unabhängig davon, wie der Rest des Assistenten ausgefüllt wurde. Zertifizierungsstellen haben gleichzeitig auch die browserbasierte Schlüsselerzeugung und die herunterladbare .pfx-Auslieferung für diese Produkte eingestellt.

Wenn Ihr Ziel ein öffentlich vertrauenswürdiges Zertifikat ist, wird der Weg bereits bei der Bestellung festgelegt. Entweder erzeugt die CA den Schlüssel auf einem Token und schickt es Ihnen per Post, wobei Sie in diesem Fall keine CSR erstellen müssen, oder Sie erzeugen den Schlüssel auf Hardware, die Sie bereits besitzen, und reichen zusammen mit der Anforderung eine Attestierung ein. Die Anleitung zu Auslieferungsmethoden für Code-Signing-Zertifikate vergleicht die beiden Wege, und die geräteseitigen Schritte finden Sie hier:

• YubiKey 5 FIPS: CSR-Erzeugung und Attestierung
• Luna Network Attached HSM v7.x: Anleitung zu CSR und Attestierung

Wo MMC weiterhin passt

Der Assistent ist nicht überflüssig. Es ist der von Ihnen darin gewählte Provider, der entscheidet, wo der Schlüssel entsteht, und es gibt drei Situationen, in denen er nach wie vor das richtige Werkzeug ist.

Eine Anforderung, die von einem Hardware-Provider unterstützt wird. Die Liste Cryptographic Service Provider im Assistenten zeigt jeden auf dem Rechner installierten Provider, nicht nur die Software-Provider von Microsoft. Sobald der Treiber eines Tokens oder der Smartcard-Minitreiber installiert ist, erscheint dessen Provider ebenfalls dort. Der Unterschied liegt darin, wo das Schlüsselpaar entsteht: Ein Software-Provider erzeugt es auf Ihrem Computer, während ein hardwarebasierter Provider, etwa ein Smartcard- oder Token-Provider, das Gerät anweist, das Paar zu erzeugen, woraufhin das Gerät den privaten Schlüssel hält und den Zugriff darauf kontrolliert. Wählen Sie einen Hardware-Provider, und MMC erstellt eine Anforderung für einen Schlüssel, der nie in Software existiert hat.

Zwei Vorbehalte, bevor Sie sich darauf verlassen. MMC erzeugt eine PKCS #10-Anforderung und nichts weiter, es erstellt also nicht die Key-Attestation-Datei, die die meisten Zertifizierungsstellen zusätzlich verlangen. Diese stammt aus den eigenen Tools des Geräts. Und die CA entscheidet, welche Verifizierungsmethode sie akzeptiert, wobei viele ein eigenes Dienstprogramm dafür vorschreiben. Fragen Sie Ihre CA, welchen Weg sie unterstützt, bevor Sie etwas erzeugen, denn ein mit dem falschen Werkzeug erstellter Schlüssel kann anschließend nicht mehr verschoben werden.

Eine interne oder unternehmenseigene CA. Die Baseline Requirements regeln öffentlich vertrauenswürdige Zertifikate. Ein Zertifikat, das von Ihrer eigenen Active Directory Certificate Services-CA für internes Signieren ausgestellt wird, fällt nicht in diesen Anwendungsbereich, sodass Ihre eigene Richtlinie entscheidet, wie der Schlüssel gespeichert wird, und ein Software-Provider ist dabei eine legitime Wahl. Bedenken Sie jedoch, was Sie damit erhalten: Auf diese Weise signierter Code wird nur auf Rechnern vertraut, die Ihrer internen Root bereits vertrauen, und überall sonst behandelt Windows den Herausgeber weiterhin als unbekannt.

Testsignierung und Vorbereitung. Eine Software-Anforderung eignet sich gut für ein Testzertifikat und um genau die Subject-Werte auszuarbeiten, die Sie später bei der Erzeugung der echten Anforderung gegen Ihre Hardware wiederverwenden.

Schritt 1: Das Zertifikate-Snap-In öffnen

Drücken Sie die Windows-Taste + R, geben Sie mmc ein und drücken Sie Enter. Sie können mmc auch in das Suchfeld der Taskleiste eingeben und es von dort aus öffnen. Bestätigen Sie die Aufforderung der Benutzerkontensteuerung. Ein leeres Fenster mit dem Titel Konsole1 öffnet sich.

Klicken Sie auf Datei, dann auf Snap-In hinzufügen/entfernen. Wählen Sie in der Liste Verfügbare Snap-Ins den Eintrag Zertifikate aus und klicken Sie auf Hinzufügen.

Windows fragt nun, welchen Zertifikatspeicher das Snap-In verwalten soll: Eigenes Benutzerkonto, Dienstkonto oder Computerkonto. Diese Wahl ist bei einem Code-Signing-Zertifikat wichtiger als bei einem Webserver-Zertifikat, da sie bestimmt, wo der Schlüssel liegt und in welchem Speicher Ihr Signiertool nachsieht:

• Eigenes Benutzerkonto legt den Schlüssel im persönlichen Speicher des angemeldeten Benutzers ab. Dies ist die übliche Wahl, wenn ein Entwickler interaktiv signiert, da Microsofts signtool standardmäßig den Eigenen Speicher des aktuellen Benutzers öffnet.
• Computerkonto legt den Schlüssel im Computerspeicher ab, was für einen Build-Server geeignet ist, auf dem das Signieren unter einem Dienstkonto läuft. Signiertools müssen angewiesen werden, dort nachzusehen: signtool verwendet für den Computerspeicher die Option /sm.

Wenn Sie Eigenes Benutzerkonto wählen, klicken Sie auf Fertigstellen. Wenn Sie Computerkonto wählen, klicken Sie auf Weiter, lassen Sie Lokaler Computer (der Computer, auf dem diese Konsole ausgeführt wird) ausgewählt und klicken Sie auf Fertigstellen. In beiden Fällen klicken Sie anschließend auf OK, um das Fenster Snap-Ins hinzufügen oder entfernen zu schließen.

Zwei Abkürzungen überspringen den Snap-In-Schritt vollständig, wenn Sie keine gespeicherte Konsole benötigen: certmgr.msc öffnet direkt die Zertifikatspeicher des aktuellen Benutzers, und certlm.msc öffnet die Speicher des lokalen Computers. Wenn Sie die Konsole manuell erstellt haben und erwarten, später zurückzukehren, verwenden Sie Datei und dann Speichern, um sie zu erhalten.

Schritt 2: Eine benutzerdefinierte Anforderung starten

Erweitern Sie im Konsolenstrukturbaum Zertifikate und klicken Sie mit der rechten Maustaste auf den Ordner Eigene Zertifikate (oder den darunter liegenden Ordner Zertifikate, falls der Speicher bereits Zertifikate enthält). Wählen Sie Alle Aufgaben, dann Erweiterte Vorgänge, dann Benutzerdefinierte Anforderung erstellen. Dieselben Befehle finden Sie auch im Menü Aktion, falls Sie diesen Weg bevorzugen.

Der Assistent Zertifikatregistrierung öffnet sich mit der Seite Bevor Sie beginnen. Klicken Sie auf Weiter.

Unter Zertifikatregistrierungsrichtlinie auswählen gehen Sie zur Überschrift Benutzerdefinierte Anforderung und wählen Ohne Registrierungsrichtlinie fortfahren, dann klicken Sie auf Weiter. Damit weisen Sie Windows an, eine eigenständige Anforderung für eine externe CA zu erstellen, anstatt sich gegen eine Active-Directory-Vorlage zu registrieren.

Die Seite Benutzerdefinierte Anforderung enthält drei Einstellungen:

• Vorlage. Wählen Sie (Keine Vorlage) CNG-Schlüssel. Dies verwendet einen Key Storage Provider, unter dem sich moderne Hardware-Provider registrieren. (Keine Vorlage) Legacy-Schlüssel verwendet die älteren CryptoAPI-Provider und wird nur benötigt, wenn ein bestimmtes Gerät oder eine bestimmte Anwendung dies erfordert.
• Standarderweiterungen unterdrücken. Lassen Sie diese Option deaktiviert, es sei denn, Sie beabsichtigen, nur die von Ihnen manuell festgelegten Erweiterungen zu senden.
• Anforderungsformat. Wählen Sie PKCS #10. Jede CA akzeptiert dieses Format. CMC ist für Anforderungen gedacht, die speziell an Systeme gerichtet sind, die es verlangen.

Klicken Sie auf Weiter. Auf der Seite Zertifikatinformationen sehen Sie eine einzelne Zeile mit der Bezeichnung Benutzerdefinierte Anforderung und dem Status Verfügbar. Klicken Sie auf den Pfeil Details rechts neben dieser Zeile, um sie zu erweitern, und klicken Sie dann auf die erscheinende Schaltfläche Eigenschaften. Der Dialog Zertifikateigenschaften öffnet sich mit vier Registerkarten: Allgemein, Antragsteller, Erweiterungen und Privater Schlüssel.

Schritt 3: Die Antragstellerdetails eingeben

Geben Sie auf der Registerkarte Allgemein einen Anzeigenamen und, falls gewünscht, eine Beschreibung ein. Beides sind lokale Bezeichnungen, die Ihnen helfen, das Zertifikat später im Speicher wiederzufinden. Keines von beiden ist Teil der Anforderung, und keines wird validiert.

Wechseln Sie zur Registerkarte Antragsteller. Hier wird die Identität zusammengestellt, die später als Softwarehersteller erscheint. Wählen Sie unter Antragstellername einen Eintrag aus der Dropdown-Liste Typ, geben Sie den entsprechenden Text in das Feld Wert ein und klicken Sie auf Hinzufügen >. Jeder Eintrag wandert in die Liste rechts, wo Windows ihn in Kurzform anzeigt (CN=, O=, OU=, L=, S=, C=). Wiederholen Sie dies für jeden der folgenden Punkte:

• Common Name (CN): der eingetragene Name Ihrer Organisation oder bei einem individuellen Zertifikat der vollständige rechtliche Name der Person. Dies ist die Identität, die Benutzer sehen, wenn Windows den Herausgeber benennt.
• Organization (O): der eingetragene Organisationsname, dem das Zertifikat gehört. Enthält der Name ein Symbol wie ein Kaufmanns-Und, schreiben Sie es aus oder lassen es weg, da solche Zeichen in diesem Feld nicht akzeptiert werden. Aus „AB & C Corporation“ wird „AB and C Corporation“ oder „ABC Corporation“.
• Organizational Unit (OU): die Abteilung, die die Registrierung durchführt, zum Beispiel IT. Optional.
• Locality (L): die Stadt, in der die Organisation registriert ist.
• State (S): das Bundesland oder die Provinz, vollständig ausgeschrieben. Verwenden Sie z. B. „Bayern“, nicht „BY“.
• Country (C): der zweistellige ISO-Ländercode des Ortes, an dem die Organisation registriert ist, zum Beispiel DE.

Geben Sie Angaben ein, die exakt mit Ihren rechtlichen Unterlagen übereinstimmen, denn die CA gleicht diese vor der Ausstellung mit öffentlichen und offiziellen Quellen ab. Eine Abweichung ist der häufigste Grund, warum eine Code-Signing-Bestellung ins Stocken gerät.

Lassen Sie das Feld Alternativer Name leer. Subject Alternative Names identifizieren Server anhand von Hostnamen, und ein Code-Signing-Zertifikat identifiziert einen Herausgeber und keine Maschine, weshalb es keine DNS-Einträge enthält.

Schritt 4: Provider, Schlüsselgröße und Hash auswählen

Öffnen Sie die Registerkarte Privater Schlüssel. Sie enthält mehrere ausklappbare Gruppen: Cryptographic Service Provider, Schlüsseloptionen, Hashalgorithmus auswählen, Signaturformat auswählen und Schlüsselberechtigungen. Klicken Sie auf eine Überschrift, um sie zu erweitern.

Erweitern Sie zunächst Cryptographic Service Provider, denn dies ist die Einstellung, um die es bei den Baseline Requirements geht. Die Liste zeigt jeden auf dem Rechner installierten Provider, jeweils mit einem Kontrollkästchen. Stellen Sie sicher, dass nur der Provider aktiviert ist, den Sie tatsächlich verwenden möchten:

• Wählen Sie für ein öffentlich vertrauenswürdiges Code-Signing-Zertifikat den Provider, der zu Ihrem Token oder HSM gehört. Dieser erscheint in der Liste erst, nachdem der Treiber oder Minitreiber des Geräts installiert wurde, also schließen Sie das Gerät zuerst an und installieren Sie dessen Software.
• RSA, Microsoft Software Key Storage Provider ist die Software-Option. Verwenden Sie diese nur für eine interne CA oder ein Testzertifikat.
• Die Liste enthält auch ECDSA-Einträge wie ECDSA_P256, Microsoft Software Key Storage Provider. Vergewissern Sie sich, dass Ihre CA ECDSA für Code Signing unterstützt, bevor Sie eine solche Option wählen, denn nicht jedes Produkt tut dies.

Erweitern Sie Schlüsseloptionen. Setzen Sie Schlüssellänge auf 3072 oder 4096. RSA 3072 ist die Untergrenze für Code Signing, und eine mit 2048 erstellte Anforderung wird abgelehnt. Bietet die Dropdown-Liste für den von Ihnen gewählten Provider keine 3072 an, verwenden Sie 4096.

Lassen Sie in derselben Gruppe Privaten Schlüssel exportierbar machen deaktiviert. Dies ist die wichtigste Korrektur gegenüber älteren MMC-Anleitungen. Ein exportierbarer Schlüssel kann als .pfx-Datei vom Rechner kopiert werden, was genau das ist, was die Hardware-Anforderung verhindern soll, und der Attestierungsweg bescheinigt ausdrücklich, dass der Schlüssel auf nicht exportierbare Weise erzeugt wurde. Der einzige Fall, in dem Sie es aktivieren sollten, ist eine interne Signierumgebung, in der Sie das Zertifikat und den Schlüssel auf einen anderen Rechner verschieben müssen, und selbst dann schwächt dies den Schlüssel. Lassen Sie auch Archivierung des privaten Schlüssels zulassen deaktiviert. Starker Schutz für private Schlüssel ist optional und veranlasst Windows, bei jeder Verwendung des Schlüssels eine Aufforderung anzuzeigen, was für einen Signierschlüssel auf einer gemeinsam genutzten Arbeitsstation sinnvoll ist.

Erweitern Sie Hashalgorithmus auswählen und setzen Sie Hashalgorithmus auf sha256. SHA-1 ist für Code-Signing-Zertifikate nicht zulässig.

Ein Blick auf die Registerkarte Erweiterungen lohnt sich, wenn Sie sich bei einer internen CA registrieren. Erweitern Sie Schlüsselverwendung und fügen Sie Digitale Signatur hinzu, erweitern Sie dann Erweiterte Schlüsselverwendung (Anwendungsrichtlinien) und fügen Sie Codesignierung hinzu. Eine öffentliche CA erstellt das Zertifikat auf Grundlage des von Ihnen bestellten Produkts und nicht anhand der Erweiterungen in Ihrer Anforderung, sodass diese Registerkarte bei einer öffentlichen Bestellung nichts ändert. Eine interne CA berücksichtigt diese Angaben unter Umständen.

Klicken Sie auf OK, um Zertifikateigenschaften zu schließen, dann auf Weiter.

Schritt 5: Die Anforderung speichern

Der Assistent fragt: Wo möchten Sie die Offline-Anforderung speichern? Klicken Sie auf Durchsuchen, wählen Sie einen Ordner, den Sie verwalten, geben Sie der Datei einen Namen wie codesigning.req und bestätigen Sie. Navigieren Sie immer zu einem Ordner, anstatt nur einen Dateinamen einzugeben: Ohne Pfad landet die Anforderung in dem Ordner, aus dem die Konsole gerade ausgeführt wird, was selten der gewünschte Ort ist und schwer wiederzufinden.

Lassen Sie unter Dateiformat die Option Base64 ausgewählt. Das ist die Textform, die CAs in ein Registrierungsfeld einfügen. Binär schreibt rohes DER, was die meisten Bestellformulare ablehnen. Klicken Sie auf Fertigstellen.

Öffnen Sie die Datei in einem beliebigen Texteditor, zum Beispiel Notepad, und kopieren Sie den gesamten Block einschließlich der ersten und letzten Zeile:

-----BEGIN NEW CERTIFICATE REQUEST-----
MIIEbDCCA1QCAQAwZDELMAkGA1UEBhMCVVMx...
...base64 encoded request...
-----END NEW CERTIFICATE REQUEST-----

Windows-Registrierungstools schreiben normalerweise die oben gezeigte längere Formulierung, mit dem Wort NEW in den Markierungszeilen, während OpenSSL BEGIN CERTIFICATE REQUEST und END CERTIFICATE REQUEST schreibt. Verwendet Ihre Datei die kürzere Form, ist alles in Ordnung: Der Inhalt ist dieselbe PKCS #10-Anforderung, und Zertifizierungsstellen akzeptieren beide Formen. Kopieren Sie genau das, was Sie sehen, und schreiben Sie die Markierungszeilen nicht um.

Eine Sache, die der Assistent nicht erzeugt, ist eine private Schlüsseldatei, die Sie speichern oder kopieren könnten, und ältere Anleitungen, die Ihnen raten, die Dateien mit öffentlichem und privatem Schlüssel sicher aufzubewahren, beschreiben ein anderes Tool. MMC bewahrt den neuen privaten Schlüssel im Windows-Schlüsselspeicher auf, unter dem in Schritt 1 gewählten Konto, ausschließlich auf diesem Computer. Die ausstehende Anforderung erscheint im Snap-In normalerweise unter Zertifikatregistrierungsanforderungen. Daraus ergeben sich drei Konsequenzen:

• Löschen Sie die ausstehende Anforderung nicht, während Sie auf die Ausstellung warten. Durch das Löschen geht der Schlüssel verloren, und das ausgestellte Zertifikat wird dann unbrauchbar.
• Schließen Sie die Bestellung auf demselben Computer ab, im selben Kontenkontext. Eine im Benutzerspeicher erzeugte Anforderung kann nicht im Computerspeicher abgeschlossen werden, und umgekehrt.
• Bauen Sie den Rechner zwischen der Erzeugung der Anforderung und der Installation des Zertifikats nicht neu auf und spielen Sie kein neues Image ein.

Schritt 6: Die Anforderung vor dem Einreichen prüfen

Eine Anforderung kann nach ihrer Erstellung nicht mehr bearbeitet werden, prüfen Sie sie also jetzt, statt einen Tippfehler erst nach Beginn der Validierung zu entdecken. Windows kann sie ohne zusätzliche Software wieder auslesen. Öffnen Sie eine Eingabeaufforderung in dem Ordner mit der Datei und führen Sie aus:

certutil -dump codesigning.req

Ist OpenSSL installiert, liest dieser Befehl dieselbe Datei aus und prüft zusätzlich die Signatur der Anforderung:

openssl req -noout -text -verify -in codesigning.req

Prüfen Sie in der Ausgabe vier Dinge: dass der Antragsteller Land, Bundesland, Ort, Organisation und Common Name genau so auflistet, wie Sie es beabsichtigen; dass der öffentliche Schlüssel 3072 Bit oder mehr hat, oder eine zugelassene ECDSA-Kurve verwendet; dass der Signaturalgorithmus SHA-256 ist; und bei Verwendung des OpenSSL-Befehls, dass eine Zeile verify OK erscheint, die bestätigt, dass die Anforderung mit dem zugehörigen privaten Schlüssel signiert wurde. Sie können den Block auch in den CSR-Decoder einfügen, um ihn im Browser zu lesen.

Ist etwas fehlerhaft, erzeugen Sie eine neue Anforderung ab Schritt 2. Um zu sehen, welche Provider auf dem Rechner verfügbar sind, einschließlich installierter Hardware-Provider, führen Sie aus:

certutil -csplist

Schritt 7: Das ausgestellte Zertifikat auf demselben Rechner installieren

Reichen Sie den Base64-Block bei Ihrer Zertifikatbestellung ein, schließen Sie die von der CA verlangte Validierung ab und laden Sie das ausgestellte Zertifikat herunter, sobald es eintrifft. Da der private Schlüssel im Windows-Schlüsselspeicher verblieben ist, muss das Zertifikat wieder in denselben Speicher zurückgeführt werden, um nutzbar zu sein.

Klicken Sie im selben Snap-In mit der rechten Maustaste auf Eigene Zertifikate, wählen Sie Alle Aufgaben, dann Importieren, und verweisen Sie den Assistenten auf die Datei. Windows ordnet das Zertifikat dem Schlüssel zu, den es aus der Anforderung behalten hat, und der ausstehende Eintrag unter Zertifikatregistrierungsanforderungen verschwindet. Öffnen Sie das Zertifikat anschließend und prüfen Sie, ob auf der Registerkarte Allgemein vermerkt ist, dass Sie über einen privaten Schlüssel verfügen, der zu diesem Zertifikat gehört. Fehlt diese Zeile, hat die Zuordnung nicht funktioniert, und Sie können sie mit der Seriennummer des Zertifikats erneut verknüpfen:

certutil -repairstore My <serial-number>

Fügen Sie die Option -user hinzu, wenn das Zertifikat dem aktuellen Benutzer und nicht dem Computer gehört:

certutil -user -repairstore My <serial-number>

Von dort aus wählt Ihr Signiertool das Zertifikat aus dem Speicher aus. Denken Sie an den in Schritt 1 gewählten Speicher: signtool liest den Eigenen Speicher des aktuellen Benutzers, es sei denn, Sie übergeben /sm für den Computerspeicher.

Weitere Möglichkeiten, dieselbe Anforderung zu erstellen, werden in den Anleitungen CertReq, OpenSSL, Java Keystore und macOS Keychain Access behandelt. Möglicherweise interessieren Sie sich auch für die umfassenderen Code-Signing-Tutorials oder andere Möglichkeiten, um eine CSR zu erzeugen.

Häufig gestellte Fragen