„Unbekannter Fehler = -2.147.414.007“ beim Erstellen eines Zertifikats mit dem Zertifikatsassistenten

Beim Erstellen eines Zertifikats über die Schlüsselbund-App erhalte ich „Unbekannter Fehler = -2.147.414.007“.

Unbekannter Fehler = -2.147.414.007

Schritte zum Wiederherstellen:

  1. Öffnen Sie die Anwendung „Schlüsselbundverwaltung“. Wählen Sie Zertifikatsassistent > Zertifikat erstellen im Anwendungsmenü (Schlüsselbundzugriff). Nur geänderte Parameter werden aufgelistet. Die restlichen Optionen werden mit Standardwerten beibehalten.

    Name des Zertifikats = gdbcert
    Identitätstyp = Selbstsignierter Stammzertifikatstyp
    = Code Signing

  2. Aktivieren Sie das Kontrollkästchen Standardeinstellungen überschreiben lassen und klicken Sie auf Weiter.

  3. Lassen Sie auf der nächsten Seite die Sicherheitsnummer auf 1 und setzen Sie den Gültigkeitszeitraum auf 3650.

  4. Klicken Sie dann erneut auf Weiter und fahren Sie fort, die nächsten sechs Bildschirme zu überspringen, bis Sie den mit dem Titel Geben Sie einen Speicherort für das Zertifikat an.

  5. Wählen Sie für die einzige Eigenschaft, Schlüsselbund, System aus der Dropdown-Liste aus. Klicken Sie zuletzt auf Erstellen, geben Sie Ihr Passwort ein, wenn Sie dazu aufgefordert werden, und klicken Sie auf Fertig.

Update: Ich kann Zertifikate für den Login-Schlüsselbund erstellen. Das Problem tritt nur auf, wenn ich versuche, Zertifikate für den Systemschlüsselbund zu erstellen.

Können Sie erreichen, was Sie tun müssen ? Haben Sie dies direkt Apple über Bugreporter oder deren Feedback-Seite gemeldet ?
Ich habe in Apple Support Foren gepostet . Und ja, ich konnte gdb zum Laufen bringen. Die Schritte sind im Abschnitt „Antworten“ aufgeführt.
Bitte melden Sie diesen reproduzierbaren Fehler direkt an Apple . Apple-Ingenieure lesen weder Support-Foren noch Ask Different. Das beste Mittel, Apple davon in Kenntnis zu setzen, ist die Bugreporter- Seite.
Ich habe den gleichen Fehler erhalten, aber als ich den Zertifikatsassistenten das zweite Mal ausgeführt und denselben Namen verwendet habe, wurde das Zertifikat sofort ohne weiteren Schritt für mich erstellt ...
Hey, das habe ich auch. Ich habe es überwunden, indem ich das Zertifikat in der Anmeldekette erstellt und in den Systemschlüsselbund verschoben habe - einfach per Drag & Drop.

Antworten (7)

Konnte das zum Laufen bringen. Der Zweck für die Erstellung eines Zertifikats bestand darin, gdb auf dem Mac mitzugestalten. Hier sind die Schritte dafür: -

  • Erstellen Sie ein Zertifikat mit allen oben genannten Parametern.
  • Anstatt den Schlüsselbund unter Standort System zu speichern, speichern Sie ihn unter Login.
  • Entsperren Sie dann den System-Schlüsselbund, indem Sie auf das Schlosssymbol in der oberen linken Ecke klicken und das Zertifikat von Login auf System ziehen.
  • Klicken Sie mit der rechten Maustaste auf das Zertifikat, klicken Sie auf „Informationen abrufen“ und stellen Sie unter „Vertrauen“ die Option „Immer vertrauen“ ein.
  • Taskgate im Terminal neu starten:killall taskgated
  • Root-Konto aktivieren:
    Öffnen Sie die Systemeinstellungen.
    Gehen Sie zu Benutzer & Gruppen > Entsperren.
    Anmeldeoptionen > „Beitreten“ (neben Network Account Server).
    Klicken Sie auf „Verzeichnisdienstprogramm öffnen“.
    Gehen Sie nach oben zu Bearbeiten > Root-Benutzer aktivieren.
  • Im Terminal codesign -fs gdbc /usr/local/bin/gdbausführen.
  • Deaktivieren Sie das Root-Konto erneut und Sie sollten bereit sein.

Kredite:

Übrigens, was ist der Zweck, den Root-Benutzer zu aktivieren? Die Anweisungen hier besagen nicht, sich tatsächlich beim Root-Benutzer anzumelden. Außerdem enthielt die Antwort im anderen Thread diesen Root-Benutzerschritt nicht.
Ich habe das zum Laufen gebracht. Verwenden Sie das neueste High Sierra plus gdb 8.01, nicht 8.1, aufgrund des an anderer Stelle besprochenen Problems . Außerdem musste ich , wie in einem anderen Themasudo /usr/sbin/DevToolsSecurity --enable besprochen , tun, um eine Popup-Passwortabfrage zu verhindern, wenn ich gdb ausführe.
Das Ziehen funktionierte nicht – es fror mit dem Ziehcursor ein und die Schlüsselbund-App-GUI verzögerte sich. Am Ende habe ich mit der rechten Maustaste geklickt, kopiert, bin dann zu System gegangen und habe mit der rechten Maustaste geklickt und "2 Elemente eingefügt".
Als ich "killall taskgated" gemacht habe, bekam ich "Es wurden keine passenden Prozesse gefunden, die Ihnen gehören". "sudo killall taskgated" hat funktioniert.
@xdavidliu Ich arbeite gut für mich, wenn ich die Schritte "Root aktivieren" und "Root deaktivieren" übersprungen habe. Als ich Codesign ausführte, wurde ein Popup-Fenster angezeigt, in dem ich nach meinem Passwort gefragt wurde.
Exzellent. Ein kleiner Nit. In Bezug auf den Schritt: Führen Sie codesign -fs gdbc /usr/local/bin/gdb im Terminal aus, was auf das Flag folgt -fs ist der Name des Zertifikats. Es sollte gdbcert sein , um es mit den Daten des SO abzugleichen, die als Teil der Abfrage angegeben wurden.
Funktioniert bei mir immer noch nicht. Ich verwende Gdb 8.3. Ich gebe auf.
Durch Ausführen aller Schritte in Abschnitt 1 von sourceware.org/gdb/wiki/PermissionsDarwin wurde das Problem für mich unter macOS Catalina (Version 10.15.4) für GDB 9.1 behoben.
Ich habe gdbmit installiert brew install gdb. Warum ist es notwendig, diese Zertifizierung erneut zu erstellen? Ich bin mir nicht sicher, ob ich aus dem richtigen Grund tue. Ich versuche nur, einen Weg zu finden, die callAnweisungen auf (gdb) disassembleden Namen zu verweisen c like functions.
Sie können Directory Utilitydirekt mit Spotlight oder Alfred öffnen.

Mein Workaround war ein bisschen anders. Ich habe die Option "Lassen Sie mich Schlüsselpaarinformationen angeben" aktiviert und bin mit dem gegangen, was standardmäßig ausgewählt war. Die Schlüsselgröße war 2048 Bit und der Algorithmus war RSA. Dadurch schien ich den "Unbekannten Fehler = -2.147.414.007" umgehen zu können.

Ich glaube nicht, dass das richtig ist: Es gibt keine Option mit dem Namen "Lassen Sie mich Schlüsselpaarinformationen angeben". Die einzige ähnliche Option ist "Standardwerte überschreiben lassen", und jeder, der auf dieses Problem stößt, wählt diese Option bereits aus.
Ich bin mir nicht sicher, welches OSX Sie verwenden, aber ich sehe die Option für High Sierra.
Der Wechsel zu RSA 4096 schien diesen Fehler zu vermeiden. Aber ich kann das Betriebssystem immer noch nicht dazu bringen, das Codesign von GDB zu akzeptieren.

Ich habe diesen Fehler auf einem meiner Benutzercomputer erhalten, nachdem er gegen meine Vorschläge auf Mojave aktualisiert hatte.

Das Endergebnis für die Zertifikatsausgabe war, dass mein Benutzer keine Verbindung zu unserem Mitarbeiter-WLAN herstellen konnte.

Ich habe die Anweisungen von Danis vom 15.12.17 befolgt, aber die Terminalbefehle funktionierten nicht und mein Unternehmen verwendet ein Zertifikat von einem CA-Server, daher waren die Details etwas anders. Ich habe jedoch den Root-Benutzer aktiviert.

Schließlich habe ich unser Mitarbeiter-WLAN aus den Netzwerkeinstellungen gelöscht, dem Mitarbeiter-WLAN manuell wieder beigetreten und die Sicherheitseinstellungen wieder auf EAP-TLS geändert, das richtige Zertifikat ausgewählt und eine Verbindung hergestellt.

Ich wünschte, ich hätte meine Schritte dafür besser aufgezeichnet, aber ich gehe davon aus, dass Apple einen Teil seiner Netzwerksicherheit aktualisiert hat, und es waren die WLAN-Verbindungseinstellungen, die tatsächlich den Trick gemacht haben.

Haftungsausschluss: Die Schlüsselbundverwaltung verhält sich selten wie erwartet.

Zugegeben, die folgende Antwort ist eine Problemumgehung, da sie sowohl eine CSR als auch einen neuen Satz zugehöriger Schlüssel erstellt.

  1. Starten Sie die Schlüsselbundverwaltung, entsperren Sie sie, wählen Sie Anmelden (aber wählen Sie nichts anderes aus)

    Schlüsselbundzugriff entsperrt

  2. Im Menü Schlüsselbundverwaltung Zertifikatsassistent ▶
    ︎ Zertifikat von einer Zertifizierungsstelle anfordern...

    Fordern Sie ein Zertifikat von einer Zertifizierungsstelle an

  3. Wählen Sie die E-Mail-Adresse aus, die sowohl dem CSR als auch dem Schlüsselpaar zugeordnet werden soll.

    • Das Schlüsselpaar wird in der Schlüsselbundverwaltung nach dem Common Name benannt
    • Aktivieren Sie Lassen Sie mich die Schlüsselpaarinformationen angeben (was Sie in einem nachfolgenden Dialog tun werden)
      Lassen Sie mich die Schlüsselpaarinformationen angeben

  4. Speichern Sie die Zertifikatsignierungsanforderung

    CSR speichern

  5. Geben Sie die Schlüsselgröße und den Algorithmus RSA 2048 Bits an

    RSA 2048-Bit

  6. Überprüfen Sie Ihren neuen Schlüsselsatz in der Schlüsselbundverwaltung. Beachten Sie, dass der Anmeldebereich jetzt ein neues Paar enthält ...

    Neues Schlüsselpaar

...und dass beim Erstellen des Zertifikats mit dem Zertifikatsassistenten der „Unbekannte Fehler = -2.147.414.007“ nicht aufgetreten ist.

Für MacOS Big Sur kann ich bestätigen, dass der folgende Kommentar von honey_badger zu der Frage funktioniert. Ich bin mir auch ziemlich sicher, dass das Handbuch andere macOS-Versionen vor und nach Mojave abdeckt. Hier sein Kommentar:

Durch Ausführen aller Schritte in Abschnitt 1 von GDB-Berechtigungen löste Darwin das Problem für mich unter macOS Catalina (Version 10.15.4) für GDB 9.1.

security dump-trust-settings -dgibt "SecTrustSettingsCopyCertificates: No Trust Settings were found" aus

Das ist was ich mache:

Uncheck the Let me override defaults checkbox

und dann funktioniert es gut.

Ich verwende High Sierra 10.13.6 (17G7024).

Bevor Sie ein Zertifikat erstellen, sollten Sie die Sperre von System aufheben. In diesem Fall erhalten Sie diesen Fehler nicht.

Diese Antwort funktioniert überhaupt nicht. Ich habe gerade vor einer Minute auf High Sierra bestätigt. Sie erhalten immer noch den gleichen Fehler.
„Unbekannter Fehler = -2.147.414.007“ beim Erstellen eines Zertifikats mit dem Zertifikatsassistenten
AntwortenHierDatenschutz-Bestimmungen1y, 0v