Wie man auf macOS mit Keychain Access eine CSR für ein Code-Signing-Zertifikat generiert

Keychain Access ist immer noch auf jedem Mac vorhanden, und der Certificate Assistant erstellt weiterhin Zertifikatssignierungsanfragen. Ob diese Anfrage für Code-Signing überhaupt nutzbar ist, hängt vollständig davon ab, welches Zertifikat Sie bestellen. Für ein Apple Developer ID-Zertifikat, mit dem Sie Mac-Software außerhalb des Mac App Store verteilen können, ist Keychain Access das richtige Werkzeug, und die folgenden Schritte sind aktuell. Für ein kommerzielles Code-Signing-Zertifikat einer öffentlichen Certificate Authority, wie es zum Signieren von Windows-Programmen, Installern, Treibern und Java-Anwendungen verwendet wird, wird eine in Keychain Access erstellte Anfrage seit dem 1. Juni 2023 nicht mehr akzeptiert, da der private Schlüssel jetzt auf Hardware erzeugt werden muss.

Klären Sie zunächst, welches der beiden Zertifikate Sie benötigen, und folgen Sie dann dem passenden Abschnitt.

Welches Code-Signing-Zertifikat erhalten Sie eigentlich?

Beide Produkte werden Code-Signing-Zertifikate genannt und beide belegen, wer eine Software veröffentlicht hat, aber sie stammen von unterschiedlichen Ausstellern und unterliegen unterschiedlichen Regeln. Leser landen auf dieser Seite, weil Apple und die öffentlichen Certificate Authorities dieselben Begriffe für zwei unterschiedliche Dinge verwenden.

• Apple Developer ID-Zertifikat. Wird von Apple über die eigene Developer ID Certification Authority an Mitglieder des Apple Developer Program ausgestellt. Es signiert Mac-Apps, Plug-ins und Installationspakete, die Sie selbst verteilen, damit macOS Gatekeeper Sie als identifizierten Entwickler erkennt. Das Schlüsselpaar wird auf Ihrem Mac erzeugt und bleibt in Ihrem Anmeldeschlüsselbund, und Sie erstellen die Anfrage in Keychain Access.
• Öffentlich vertrauenswürdiges Code-Signing-Zertifikat. Wird von einer öffentlichen Certificate Authority wie Sectigo, DigiCert oder GlobalSign gekauft. Es signiert Windows-Programme, MSI-Installer, Treiber, PowerShell-Skripte und Java-Anwendungen. Es unterliegt den Code Signing Baseline Requirements des CA/Browser Forums, die vorschreiben, dass der private Schlüssel auf zertifizierter Hardware erzeugt wird und dort verbleibt, sodass es für Keychain Access nichts zu tun gibt.

Die kurze Entscheidungsregel: Wenn die Software, die Sie signieren, unter macOS läuft und Sie sie außerhalb des Mac App Store vertreiben, benötigen Sie ein Developer ID-Zertifikat. Wenn Sie etwas für Windows oder eine Java-Anwendung signieren, benötigen Sie ein kommerzielles Code-Signing-Zertifikat, selbst wenn Sie es auf einem Mac erstellen. Keines von beiden ist ein SSL/TLS-Zertifikat. Wenn Sie eigentlich HTTPS auf einem Mac-Server möchten, folgen Sie stattdessen der Anleitung CSR auf macOS-Servern erzeugen.

Der kommerzielle Weg: Warum die Keychain-Methode nicht mehr gilt

Seit dem 1. Juni 2023 verlangen die Code Signing Baseline Requirements des CA/Browser Forums, dass der private Schlüssel für jedes öffentlich vertrauenswürdige Code-Signing-Zertifikat, sowohl Standard (OV) als auch Extended Validation (EV), in einem Hardware-Kryptomodul erzeugt und gespeichert wird, das FIPS 140-2 Level 2, Common Criteria EAL4+ oder einen gleichwertigen Standard erfüllt, und dass er nicht exportierbar sein darf. EV-Code-Signing erforderte schon immer Hardware; die Änderung von 2023 hat dieselbe Regel auf Standardzertifikate ausgeweitet.

Ein von Certificate Assistant erstellter Schlüssel scheitert an diesem Test von vornherein, aus drei separaten Gründen:

• Der Schlüssel ist exportierbares Software-Schlüsselmaterial. Er wird in Ihren Anmeldeschlüsselbund geschrieben, und Sie können ihn auswählen und als .p12-Datei exportieren. Diese Portabilität ist für die Apple-Entwicklung praktisch und genau die Eigenschaft, die die Hardwareanforderung beseitigen soll.
• Die Schlüsselgröße passt nicht. Die Baseline Requirements setzen für Code-Signing ein Minimum von RSA 3072 Bit voraus, und das Menü Key Size von Certificate Assistant bietet keine Option für 3072 Bit.
• Die Anfrage enthält kaum Identitätsangaben. Certificate Assistant fragt nur nach einem Common Name und E-Mail-Adressen. Es gibt keine Möglichkeit, Organisation, Ort, Bundesland oder Land einzugeben, die eine Certificate Authority für ein organisationsvalidiertes Code-Signing-Zertifikat prüft.

Damit bleiben zwei gültige Wege, ein öffentlich vertrauenswürdiges Code-Signing-Zertifikat zu erhalten, und welchen Sie nutzen, wird bei der Bestellung festgelegt:

• Token plus Versand. Die Certificate Authority erzeugt das Schlüsselpaar und die Anfrage auf ihrer Seite auf einem zertifizierten USB-Token, lädt das ausgestellte Zertifikat darauf und schickt Ihnen das Token per Post. Es gibt keine CSR, die Sie erstellen oder irgendwo einfügen müssen. Siehe welche Zustellmethode für Code-Signing-Zertifikate zu wählen ist.
• Ihr eigenes Hardware-Token, HSM oder Cloud-HSM, mit Attestierung. Sie erzeugen den Schlüssel im Gerät, erstellen dort die Anfrage und reichen eine Attestierungsdatei ein, die belegt, dass der Schlüssel auf konformer Hardware erzeugt wurde und nicht exportiert werden kann. Folgen Sie der Anleitung YubiKey 5 FIPS CSR-Erzeugung und Attestierung oder Luna Network Attached HSM v7.x CSR und Attestierung, oder der Dokumentation Ihres HSM-Anbieters.

Eine weitere bereits in Kraft getretene Änderung: Das Ballot CSC-31 hat die maximale Gültigkeit öffentlich vertrauenswürdiger Code-Signing-Zertifikate von 39 Monaten auf 460 Tage für Zertifikate reduziert, die ab dem 1. März 2026 ausgestellt werden, sodass Verlängerungen nun etwa alle 15 Monate anstehen. Für den größeren Zusammenhang siehe wie man eine CSR für ein Code-Signing-Zertifikat erzeugt und die OpenSSL-Version derselben Anleitung.

Die CSR in Keychain Access für ein Apple Developer ID-Zertifikat erzeugen

Wenn Sie bereits eine .certSigningRequest-Datei gespeichert haben, springen Sie direkt zu deren Einreichung in Ihrem Entwicklerkonto.

Zwei Dinge sollten Sie vorher prüfen. Sie benötigen eine Mitgliedschaft im Apple Developer Program, und Apple verlangt die Rolle Account Holder, um ein Developer ID-Zertifikat zu erstellen. Zudem sind pro Team bis zu fünf Developer ID Application-Zertifikate und fünf Developer ID Installer-Zertifikate erlaubt. Das Portal fordert Sie bei jeder Zertifikatserstellung auf, eine Anfrage hochzuladen, führen Sie diesen Vorgang also pro Zertifikat einmal durch.

Schritt 1: Keychain Access öffnen und die Anfrage starten

Keychain Access befindet sich nicht mehr dort, wo die meisten Anleitungen behaupten. Bis macOS Sonoma lag es unter Programme > Dienstprogramme. Ab macOS Sequoia hat Apple es nach /System/Library/CoreServices/Applications/ verschoben, einen Systemordner, den der Finder beim Durchsuchen von Programme nicht anzeigt, sodass ein Blick unter Dienstprogramme nun ins Leere läuft. Die schnellsten Wege, es zu öffnen, sind Spotlight (drücken Sie Befehlstaste-Leertaste und geben Sie Keychain Access ein) oder ein einzelner Befehl im Terminal:

open "/System/Library/CoreServices/Applications/Keychain Access.app"

Wählen Sie bei geöffneter App in der Menüleiste Keychain Access > Certificate Assistant > Request a Certificate From a Certificate Authority.

Klicken Sie vorher auf einen leeren Bereich der Elementliste, damit nichts ausgewählt ist. Wenn ein Schlüssel oder Zertifikat markiert ist, ändert sich der Menüpunkt zu Request a Certificate From a Certificate Authority With gefolgt vom Namen dieses Elements, und die Anfrage wird dann um den vorhandenen Schlüssel herum aufgebaut, statt ein neues Paar zu erzeugen. Das ist nützlich, wenn Sie bewusst einen Schlüssel wiederverwenden möchten, und verwirrend, wenn nicht.

Schritt 2: Das Fenster Certificate Information ausfüllen

Certificate Assistant öffnet sich mit einem Bereich namens Certificate Information. Er fragt nur sehr wenig ab:

• User Email Address: die E-Mail-Adresse Ihres Apple Developer-Kontos.
• Common Name: eine Bezeichnung für das Schlüsselpaar, zum Beispiel Developer ID Application Key. Das ist nicht der Name, der später im Zertifikat steht. Apple erstellt das Subject des ausgestellten Zertifikats aus Ihrem Team, in der Form Developer ID Application: Ihr Teamname (TEAMID), betrachten Sie dieses Feld also als eigene Referenz.
• CA Email Address: lassen Sie es leer. Es wird nur für die andere Zustelloption verwendet.
• Request is: wählen Sie Saved to disk, nicht Emailed to the CA. Apples Entwicklerportal nimmt eine hochgeladene Datei entgegen.

Wenn Sie auch die Schlüsselgröße oder den Algorithmus wählen möchten, aktivieren Sie hier Let me specify key pair information. Klicken Sie dann auf Continue.

Schritt 3: Bei Bedarf die Einstellungen des Schlüsselpaars wählen

Dieser Bereich erscheint nur, wenn Sie die Option in Schritt 2 aktiviert haben, und für ein Developer ID-Zertifikat können Sie ihn in der Regel überspringen. Die Standardwerte sind RSA mit 2048 Bit, was auch Apples eigene Anleitung verwendet. Bei ausgewähltem RSA bietet das Menü Key Size 2048, 4096 und 8192 Bit an. Das Menü Algorithm bietet RSA und ECC an, und der Wechsel zu ECC ersetzt diese Größen durch 256, 384 und 521 Bit. Lassen Sie den Algorithmus auf RSA, sofern der Dienst, bei dem Sie sich registrieren, nicht ausdrücklich einen Schlüssel mit elliptischer Kurve verlangt.

Frühere Versionen dieser Anleitung rieten Ihnen, an dieser Stelle mindestens 3072 Bit zu wählen. Dieser Wert ist das Minimum des CA/Browser Forums für kommerzielle Code-Signing-Zertifikate. Er gilt nicht für Developer ID und wird in diesem Menü auch nicht angeboten, es gibt also nichts auszuwählen. Klicken Sie auf Continue.

Schritt 4: Die Anfrage speichern und ihren Inhalt prüfen

Wählen Sie einen Speicherort für die Datei und klicken Sie auf Save. Sie erhalten eine Datei mit der Erweiterung .certSigningRequest, und Certificate Assistant legt zudem das zugehörige Schlüsselpaar in Ihrem Anmeldeschlüsselbund ab. Die Datei selbst ist gewöhnlicher PEM-Text, Sie können sie also in TextEdit öffnen und lesen, auch wenn der kodierte Block für sich genommen nicht viel aussagt.

Um die Angaben vor dem Hochladen zu überprüfen, dekodieren Sie die Anfrage im Terminal. Das funktioniert mit dem bereits auf macOS vorhandenen Befehl openssl, bei dem es sich eigentlich um LibreSSL statt um echtes OpenSSL handelt, sodass nichts installiert werden muss:

openssl req -noout -text -in CertificateSigningRequest.certSigningRequest

Prüfen Sie drei Dinge in der Ausgabe: Die Zeile Subject zeigt den von Ihnen eingegebenen Common Name und die E-Mail-Adresse, die Zeile zum öffentlichen Schlüssel meldet 2048 bit (oder die von Ihnen gewählte Größe), und der Signaturalgorithmus ist SHA-256. Wenn Sie das Terminal lieber nicht nutzen möchten, fügen Sie den Inhalt der Datei in unseren CSR-Decoder ein, um dieselben Felder zu lesen.

Schritt 5: Die Anfrage einreichen und das Zertifikat installieren

Melden Sie sich bei Ihrem Apple Developer-Konto an und öffnen Sie Certificates, Identifiers & Profiles. Klicken Sie in der Seitenleiste auf Certificates, dann auf die Schaltfläche zum Hinzufügen, und wählen Sie unter Software Developer ID. Wählen Sie den benötigten Typ:

• Developer ID Application signiert eine Mac-App, ein Plug-in oder ein Bundle.
• Developer ID Installer signiert ein Mac-Installationspaket, das Ihre signierte App enthält.

Klicken Sie auf Continue, dann auf Choose File, wählen Sie Ihre .certSigningRequest-Datei aus, klicken Sie erneut auf Continue und dann auf Download. Apple liefert eine Zertifikatsdatei mit der Erweiterung .cer. Doppelklicken Sie darauf, um sie zu installieren, sie erscheint dann in Keychain Access unter My Certificates, gepaart mit dem in Schritt 4 erzeugten privaten Schlüssel.

Das Signieren mit dem Zertifikat ist nur die halbe Miete dessen, was macOS prüft. Gatekeeper erwartet, dass Software, die außerhalb des Mac App Store heruntergeladen wird, mit einem Developer ID-Zertifikat signiert und von Apple notariell beglaubigt (notarized) wurde, reichen Sie den signierten Build also vor der Verteilung zur Notarisierung ein. Die Notarisierung ersetzt die Signatur nicht, sie kommt zusätzlich zu ihr hinzu.

Den privaten Schlüssel finden und sichern

Das Zertifikat ist ohne den von Certificate Assistant erzeugten privaten Schlüssel wertlos, und dieser Schlüssel existiert genau an einem Ort, bis Sie ihn kopieren. Um ihn zu finden, öffnen Sie Keychain Access, wählen Sie den Schlüsselbund Anmeldung (login), dann die Kategorie Schlüssel, und suchen Sie nach dem Common Name, den Sie in Schritt 2 eingegeben haben. Sie sehen unter diesem Namen zwei Einträge, einen öffentlichen und einen privaten Schlüssel. Beachten Sie, dass der öffentliche Schlüssel nicht Ihre CSR ist: Die CSR ist die .certSigningRequest-Datei, die Sie auf der Festplatte gespeichert haben.

Sobald die .cer-Datei installiert ist, schauen Sie stattdessen unter My Certificates nach. Dort erscheinen das Zertifikat und sein privater Schlüssel als ein einzelner Eintrag, das ist die Signieridentität, die codesign, Xcode und Ihre Build-Skripte verwenden. Um diese Identität auf einen anderen Mac oder einen Build-Server zu übertragen, klicken Sie mit der rechten Maustaste auf den Eintrag und wählen Exportieren, wodurch eine durch ein von Ihnen festgelegtes Passwort geschützte .p12-Datei erzeugt wird. Bewahren Sie diese Datei so auf, wie Sie jeden Signierschlüssel aufbewahren würden, denn jeder, der sie und das Passwort besitzt, kann Software unter Ihrem Namen signieren.

Sichern Sie sie, bevor Sie sie brauchen. Developer ID-Zertifikate sind fünf Jahre gültig und können nicht verlängert werden: Wenn eines abläuft, erstellen Sie ein Ersatzzertifikat. Wenn Sie den privaten Schlüssel verlieren, kann das Zertifikat nie wieder verwendet werden, und Sie müssen ein neues erstellen, was einen Ihrer fünf Developer ID Application- oder fünf Developer ID Installer-Plätze verbraucht. Widerstehen Sie dem Drang, das nicht mehr nutzbare Zertifikat aus Aufräumgründen zu widerrufen. Apple stellt ausdrücklich klar, dass eine mit einem widerrufenen Developer ID-Zertifikat signierte App sich nicht installieren lässt und bei einem Nutzer, der sie bereits hat, nicht startet, ein Widerruf würde also jede bereits verbreitete Kopie beschädigen. Widerrufen Sie nur, wenn der Schlüssel tatsächlich gestohlen wurde, und rechnen Sie dann mit diesem Schaden.

Ein Hinweis für alle, die wegen eines kommerziellen Zertifikats hierhergekommen sind: Wenn Sie bereits ein Schlüsselpaar in Keychain Access für eine Bestellung bei einer öffentlichen Certificate Authority erzeugt haben, kann es nicht verwendet werden, und keine CA wird es akzeptieren. Es passiert nichts, wenn Sie es bestehen lassen, aber es gibt wenig Grund, exportierbares Signierschlüsselmaterial in einem Schlüsselbund liegen zu lassen. Wählen Sie sowohl den öffentlichen als auch den privaten Schlüssel unter Schlüssel aus und löschen Sie sie, bestellen Sie stattdessen über ein Token oder ein HSM.

Häufig gestellte Fragen

Für weiterführende Informationen siehe unsere Code-Signing-Anleitungen, die weiteren Möglichkeiten zum Erzeugen einer CSR und wie man eine EXE-Datei mit einem Code-Signing-Zertifikat signiert.