Developer ID Certification Authority läuft am 1. Februar 2027 ab

Apple hat am 1. Oktober 2026 angekündigt, dass die ursprüngliche Developer ID Certification Authority am 1. Februar 2027 abläuft und dass Installer-Pakete, die mit einem von ihr ausgestellten Zertifikat signiert sind, ab diesem Datum „will no longer install“ (sich nicht mehr installieren lassen). Notarisierte Apps bleiben verschont: „Previously signed and notarized Mac software (with a secure timestamp) will keep working.“ (Bereits signierte und notarisierte Mac-Software mit sicherem Zeitstempel funktioniert weiter.)¹ Die Nachfolgerin G2 stellt seit dem 27. Januar 2022 Zertifikate aus, doch Apple bot Teams mit alten Xcode-Versionen weiterhin die ursprüngliche Zertifizierungsstelle an, sodass ein Team von jeder der beiden ein Zertifikat besitzen kann.²³ Apples Prüfkriterium ist die Organizational Unit im Ausstellernamen des Zertifikats, nicht das Ablaufdatum.

Im Folgenden zeige ich die Befehle, die diese Angabe aus einem Schlüsselbund, einem Paket und einer App auslesen; was sie für die 66 Developer-ID-Apps und vier Installer auf meinem eigenen Mac ausgeben, wo 49 Apps und alle vier Installer an der auslaufenden Zertifizierungsstelle hängen; einen Satz in Apples Mitteilung, zu dem die Zertifikate, die ich prüfen kann, nicht passen; und die Reihenfolge, in der ich neu signieren würde.⁴

TL;DR

• Das Datum. Das Zertifikat der ursprünglichen Zertifizierungsstelle endet am 1. Februar 2027 um 22:12:15 UTC, auf die Sekunde fünfzehn Jahre nach seinem Beginn. Apple: „Certificates issued by this authority will stop working on that date.“ (Von dieser Stelle ausgestellte Zertifikate funktionieren ab diesem Tag nicht mehr.)¹⁴
• Pakete hören auf, notarisierte Apps nicht. „.pkg files signed with an affected certificate will no longer install“ (mit einem betroffenen Zertifikat signierte .pkg-Dateien lassen sich nicht mehr installieren), während notarisierte Software mit sicherem Zeitstempel „will keep working“ (weiter funktioniert).¹
• Lesen Sie den Aussteller. Die Organizational Unit des Ausstellers lautet „Apple Certification Authority“ bei einem Zertifikat der ursprünglichen Zertifizierungsstelle und „G2“ bei einem der aktuellen. Das Ablaufdatum, so Apple, „doesn’t prove which authority issued a certificate“ (beweist nicht, welche Stelle ein Zertifikat ausgestellt hat).²
• Die Stichprobe eines Macs. Alle vier mit Developer ID signierten Installer in meinem Downloads-Ordner hängen an der ursprünglichen Zertifizierungsstelle; der jüngste wurde am 29. Dezember 2025 signiert. Von 66 Developer-ID-Apps in meinem Programme-Ordner hängen 49 an ihr und 17 an G2.⁴
• Ein abgelaufenes Zertifikat hat Software mit Zeitstempel bislang nicht gestoppt. Sechs der 49 Apps sind mit Zertifikaten signiert, die zwischen 2022 und Mai 2026 abgelaufen sind, ein Installer mit einem Zertifikat, das 2017 ablief. Gatekeeper akzeptiert heute alle sieben. Laut Apples Mitteilung ist damit für Pakete Schluss, sobald die Zertifizierungsstelle selbst abläuft.¹⁴
• Eine Unstimmigkeit. Apple schreibt, G2-Zertifikate „expire annually“ (laufen jährlich ab). Alle 12 G2-Zertifikate meiner installierten Apps und mein eigenes vom Mai 2026 gelten fünf Jahre. Keine der beiden Seiten sagt, seit wann einjährige Laufzeiten gelten.¹²⁴

Was hat Apple angekündigt?

Die Mitteilung ist kurz. Sie beginnt so: „The original Developer ID Certification Authority (Sub-CA) expires on February 1, 2027. Certificates issued by this authority will stop working on that date.“ (Die ursprüngliche Developer ID Certification Authority, eine Sub-CA, läuft am 1. Februar 2027 ab. Von ihr ausgestellte Zertifikate funktionieren ab diesem Tag nicht mehr.)¹ Es folgen drei Schritte: prüfen, ob Sie betroffen sind, ein neues Zertifikat erstellen und neu signieren. Der dritte Schritt hängt davon ab, was Sie verteilen:

• Installer-Pakete. „Starting February 1, 2027, .pkg files signed with an affected certificate will no longer install. Re-sign all packages with your new certificate before this date.“ (Ab dem 1. Februar 2027 lassen sich mit einem betroffenen Zertifikat signierte .pkg-Dateien nicht mehr installieren. Signieren Sie alle Pakete vor diesem Datum mit Ihrem neuen Zertifikat neu.)
• Mac-Apps. „Previously signed and notarized Mac software (with a secure timestamp) will keep working“ (bereits signierte und notarisierte Mac-Software mit sicherem Zeitstempel funktioniert weiter), ohne dass etwas zu tun ist, und „For future updates, sign with your new certificate and include a secure timestamp for notarization.“ (Signieren Sie künftige Updates mit Ihrem neuen Zertifikat und fügen Sie für die Notarisierung einen sicheren Zeitstempel hinzu.)¹

Die Hilfeseite, auf die die Mitteilung verweist, beschreibt die Folgen für das Signieren: „After that date, certificates issued from the original authority can no longer be used for signing and must be replaced with certificates from the current Developer ID Certification Authority (G2).“ (Nach diesem Datum können Zertifikate der ursprünglichen Stelle nicht mehr zum Signieren verwendet werden und müssen durch Zertifikate der aktuellen Developer ID Certification Authority, also G2, ersetzt werden.) Außerdem nennt sie „Required role: Account Holder.“ (Erforderliche Rolle: Account Holder.)²

Die Trennung zwischen Apps und Paketen entspricht weitgehend Apples bisherigen Hinweisen zu abgelaufenen Zertifikaten. Für Apps sagt Apples Hilfeseite zu Developer ID: „As long as your Developer ID certificate was valid when you compiled your app, then users can download and run your app, even after the expiration date of the certificate.“ (Solange Ihr Developer-ID-Zertifikat beim Kompilieren der App gültig war, können Benutzer Ihre App laden und ausführen, auch nach dem Ablaufdatum des Zertifikats.) Für Installer widersprechen sich Apples Seiten, und zwar sogar selbst. Dieselbe Hilfeseite sagt: „Your installer package will only launch if your Developer ID Installer certificate is valid.“ (Ihr Installer-Paket startet nur, wenn Ihr Developer-ID-Installer-Zertifikat gültig ist.) Der Eintrag zu Developer ID Installer in der Zertifikatsübersicht zieht in beide Richtungen: Benutzer „can still install packages that were signed with this certificate as long as the package includes a trusted timestamp“ (können mit diesem Zertifikat signierte Pakete weiterhin installieren, sofern das Paket einen vertrauenswürdigen Zeitstempel enthält), doch zwei Sätze später heißt es, „new installations won’t be possible until you have re-signed your installer package with a valid Developer ID Installer certificate“ (neue Installationen sind erst wieder möglich, wenn Sie Ihr Installer-Paket mit einem gültigen Developer-ID-Installer-Zertifikat neu signiert haben).⁵ Die Mitteilung vom 1. Oktober gewährt Paketen keine Ausnahme für Zeitstempel.

Die Mitteilung spricht nur vom Installieren. Sie sagt nicht, was mit Software geschieht, die bereits aus einem betroffenen Paket installiert wurde, und auch nicht, ob per Geräteverwaltung verteilte oder mit dem Befehl installer ausgeführte Installationen genauso behandelt werden wie ein Paket, das ein Benutzer öffnet. Signierte Disk-Images erwähnt sie ebenfalls nicht. Zum ersten Punkt sagt der Eintrag der Übersicht zu einem abgelaufenen Installer-Zertifikat: „Previously installed apps will continue to run.“ (Bereits installierte Apps laufen weiter.)¹⁵

Warum gibt es zwei Zertifizierungsstellen?

Ein Zertifikat kann die Stelle, die es ausgestellt hat, nicht überdauern. Apples Support-Seite von 2022 formuliert das als Regel: „Certificates cannot be issued with a validity period that extends past the intermediate certificate’s expiration date.“ (Zertifikate können nicht mit einer Gültigkeit ausgestellt werden, die über das Ablaufdatum des Zwischenzertifikats hinausreicht.)³ Jedes Developer-ID-Zertifikat aus der Zeit vor 2022, das ich finden kann, gilt fünf Jahre; ab Februar 2022 konnte die ursprüngliche Zertifizierungsstelle mit ihren verbleibenden fünf Jahren also kein Zertifikat mit voller Laufzeit mehr ausstellen. Apples Antwort war eine zweite Zertifizierungsstelle: „Starting January 27, 2022, the digital certificates you use to sign your software and installer packages on macOS will be issued from the new Developer ID intermediate certificate that expires on September 16, 2031.“ (Ab dem 27. Januar 2022 werden die digitalen Zertifikate, mit denen Sie Software und Installer-Pakete unter macOS signieren, vom neuen Developer-ID-Zwischenzertifikat ausgestellt, das am 16. September 2031 abläuft.) (Das Zertifikat selbst endet am 17. September 2031 um 00:00:00 GMT, nach pazifischer Zeit also noch am 16. September.)³⁴

Die ursprüngliche Stelle blieb im Angebot. Für Teams, die „running Xcode 11.4 or earlier“ (Xcode 11.4 oder älter verwenden), schrieb Apple: „the Apple Developer website will continue to offer Developer ID certificates associated with the original intermediate certificate. Newly issued certificates from this intermediate certificate will be valid for less than five years“ (die Apple-Developer-Website bietet weiterhin Developer-ID-Zertifikate an, die mit dem ursprünglichen Zwischenzertifikat verknüpft sind; neu ausgestellte Zertifikate dieses Zwischenzertifikats gelten weniger als fünf Jahre), eine Option, die „will be available for at least one year, starting January 27, 2022“ (ab dem 27. Januar 2022 mindestens ein Jahr lang verfügbar ist).³

Die Zertifikate auf meinem Mac zeigen beide Hälften dieser Geschichte. Die 49 Apps, die an der ursprünglichen Zertifizierungsstelle hängen, tragen 27 verschiedene Signaturzertifikate. Die fünf vor Februar 2022 ausgestellten gelten jeweils fünf Jahre. Die 22 ab dem 8. Februar 2022 ausgestellten enden alle in derselben Sekunde, am 1. Februar 2027 um 22:12:15 UTC, der letzten Sekunde der Zertifizierungsstelle selbst; das jüngste davon wurde am 15. Januar 2026 ausgestellt. Fast vier Jahre nach dem Start von G2 stellte die ursprüngliche Zertifizierungsstelle also noch Zertifikate aus, jedes kürzer als das vorige.⁴

Wie erkenne ich, welche Zertifizierungsstelle mein Zertifikat ausgestellt hat?

Apples Hilfeseite beginnt im Entwicklerportal: „Any certificates expiring on or before February 1, 2027, are likely affected. However, the expiration date alone doesn’t prove which authority issued a certificate.“ (Alle Zertifikate, die am oder vor dem 1. Februar 2027 ablaufen, sind wahrscheinlich betroffen. Das Ablaufdatum allein beweist allerdings nicht, welche Stelle ein Zertifikat ausgestellt hat.) Die Begründung: „A team can hold a certificate from each authority with identical names, such as the same Developer ID Installer entry twice, differing only in expiration date.“ (Ein Team kann von jeder Stelle ein Zertifikat mit identischem Namen besitzen, etwa zweimal denselben Eintrag Developer ID Installer, die sich nur im Ablaufdatum unterscheiden.) Apples Prüfung findet in Keychain Access statt: Zertifikat auswählen, „expand the Issuer Name field, and review the Organizational Unit field“ (das Feld für den Ausstellernamen aufklappen und das Feld Organizational Unit, also die Organisationseinheit, prüfen). „Apple Certification Authority“ bedeutet „The certificate was issued from the previous Sub-CA. Replace this certificate.“ (Das Zertifikat stammt von der vorherigen Sub-CA. Ersetzen Sie es.) „G2“ bedeutet „The certificate was issued from the current Sub-CA. No action needed.“ (Das Zertifikat stammt von der aktuellen Sub-CA. Kein Handlungsbedarf.) Die Seite fügt eine Warnung hinzu: „Check your own certificate, not the Developer ID Certification Authority entry in your keychain. That entry is the authority itself, and it’s issued by Apple Root CA, whose Organizational Unit is also Apple Certification Authority.“ (Prüfen Sie Ihr eigenes Zertifikat, nicht den Eintrag Developer ID Certification Authority in Ihrem Schlüsselbund. Dieser Eintrag ist die Zertifizierungsstelle selbst; sie wird von Apple Root CA ausgestellt, deren Organizational Unit ebenfalls Apple Certification Authority lautet.)²

Dieselbe Prüfung funktioniert im Terminal, und zwar an drei Stellen.

Ein Zertifikat in Ihrem Schlüsselbund.

security find-certificate -a -c "Developer ID Installer" -p \
  | openssl crl2pkcs7 -nocrl -certfile /dev/stdin \
  | openssl pkcs7 -print_certs -noout

Das Flag -a liefert jeden Treffer, was wegen Apples Warnung vor identischen Namen wichtig ist, und die Pipeline gibt für jedes Zertifikat eine Subject-Zeile und eine Issuer-Zeile aus. Für das App-Signaturzertifikat setzen Sie „Developer ID Application“ ein. Mein Mac enthält ein Developer-ID-Application-Zertifikat und kein Installer-Zertifikat, und mit dem systemeigenen /usr/bin/openssl lautet seine Issuer-Zeile issuer=/CN=Developer ID Certification Authority/OU=G2/O=Apple Inc./C=US. OpenSSL 3 aus Homebrew gibt dieselben Felder durch Kommas getrennt aus. Ein Name ohne Treffer erzeugt keine Ausgabe.⁴

Ein Paket, das Sie ausgeliefert haben.

pkgutil --check-signature YourProduct.pkg

Die Ausgabe nennt den Signaturstatus, den Notarisierungsstatus, den vertrauenswürdigen Zeitstempel und die Zertifikatskette. Maßgeblich ist das Datum unter dem zweiten Eintrag, „Developer ID Certification Authority“. Bei jedem meiner vier Installer steht dort Expires: 2027-02-01 22:12:15 +0000. Das Zertifikat von G2 selbst endet am 17. September 2031 (GMT), ein unter G2 signiertes Paket sollte an dieser Stelle also dieses Datum zeigen. Ein mit G2 signiertes Paket, um das zu bestätigen, habe ich nicht.⁴

Eine App. codesign -dvv allein reicht nicht, weil beide Zertifizierungsstellen denselben Common Name tragen und seine Authority=-Zeilen bei beiden gleich aussehen. Extrahieren Sie die Kette und lesen Sie das Zwischenzertifikat:

codesign -d --extract-certificates=/tmp/chain. YourApp.app
openssl x509 -inform DER -in /tmp/chain.1 -noout -subject -enddate

Bei einer mit G2 signierten App aus meinem Programme-Ordner gibt der zweite Befehl OU=G2 im Subject und notAfter=Sep 17 00:00:00 2031 GMT aus. Bei einer unter der ursprünglichen Zertifizierungsstelle signierten App gibt er OU=Apple Certification Authority und notAfter=Feb 1 22:12:15 2027 GMT aus.⁴

Was zeigt die Software auf einem Mac?

Installer. Mein Downloads-Ordner enthält vier mit Developer ID signierte Pakete von zwei Anbietern, und alle vier hängen an der ursprünglichen Zertifizierungsstelle. Drei stammen von einem Anbieter, signiert am 28. September, 14. Dezember und 29. Dezember 2025 mit einem Installer-Zertifikat, das am 13. April 2022 ausgestellt wurde und am 1. Februar 2027 endet. Dieser Anbieter hat also noch vor neun Monaten Pakete unter der ursprünglichen Zertifizierungsstelle signiert. Das vierte wurde im Februar 2014 mit einem Zertifikat signiert, das am 29. März 2017 abgelaufen ist.⁴

Gatekeepers Installationsprüfung, spctl -a -t install -vv, akzeptiert heute alle vier als „Notarized Developer ID“, auch das, dessen Signaturzertifikat vor neun Jahren abgelaufen ist. Dieses Ergebnis passt zum Satz über den vertrauenswürdigen Zeitstempel im Installer-Eintrag der Zertifikatsübersicht, nicht aber zum Satz „new installations won’t be possible“ (neue Installationen sind nicht möglich) im selben Eintrag und auch nicht zur Developer-ID-Hilfeseite. Es ist zudem genau das Verhalten, das laut Apples Mitteilung für Pakete am 1. Februar endet. Den Februar kann ich im Oktober nicht testen; was an diesem Tag geschieht, ist also Apples Aussage, nicht meine Beobachtung.¹⁴⁵

Apps. Von den 66 mit Developer ID signierten Apps in meinem Programme-Ordner hängen 49 an der ursprünglichen Zertifizierungsstelle und 17 an G2. Alle 66 Signaturen tragen einen sicheren Zeitstempel. Gatekeeper meldet 63 als „Notarized Developer ID“, also genau die Kombination, die laut Apple weiter funktioniert: 46 der 49 unter der ursprünglichen Stelle und alle 17 unter G2. Von den übrigen drei, alle unter der ursprünglichen Stelle, scheitern zwei an der Prüfung mit „a sealed resource is missing or invalid“, einem Fehler, der den Inhalt des Bundles betrifft, und eine, signiert im Juli 2018, wird als Developer ID ohne Notarisierung akzeptiert. Apples Satz deckt notarisierte Software ab, und die Mitteilung sagt nicht, was mit einer App wie dieser letzten geschieht.¹⁴

Sechs der 49 sind mit Zertifikaten signiert, die am 1. Oktober 2026 bereits abgelaufen waren, das früheste im August 2022, das späteste im Mai 2026. Gatekeeper akzeptiert alle sechs, fünf davon als notarisiert. Apples Regel für Apps, nach der ein zum Zeitpunkt der Signatur gültiges Zertifikat genügt, wirkt also bereits bei Software, die ich benutze.⁴⁵

Welcher Satz in der Mitteilung passt nicht?

Über G2 sagt die Mitteilung: „This certificate authority is valid until 2031, but the certificates issued by the certificate authority expire annually and must be renewed each year.“ (Diese Zertifizierungsstelle ist bis 2031 gültig, die von ihr ausgestellten Zertifikate laufen jedoch jährlich ab und müssen jedes Jahr erneuert werden.) Die Hilfeseite sagt dasselbe: „Certificates issued from G2 are valid for one year and must be renewed annually.“ (Von G2 ausgestellte Zertifikate gelten ein Jahr und müssen jährlich erneuert werden.)¹²

Die G2-Zertifikate, die ich prüfen kann, sind keine einjährigen Zertifikate. Die 17 mit G2 signierten Apps auf meinem Mac tragen 12 verschiedene Signaturzertifikate, ausgestellt zwischen Februar 2023 und dem 29. Mai 2026, und jedes davon gilt fünf Jahre. Drei davon wurden im April und Mai 2026 ausgestellt. Mein eigenes Developer-ID-Application-Zertifikat, ausgestellt am 10. Mai 2026, endet am 11. Mai 2031.⁴

Keine der beiden Seiten sagt, seit wann die einjährige Gültigkeit gilt, und ich habe seit der Mitteilung kein Zertifikat erstellt; ich kann also nicht sagen, mit welcher Laufzeit ein heute ausgestelltes Zertifikat kommt. Planen Sie mit einer jährlichen Erneuerung und lesen Sie die Daten auf dem Zertifikat, das Sie tatsächlich erhalten. Werden einjährige Zertifikate von nun an zur Regel, gewinnt der Widerspruch zwischen Apples Seiten, und innerhalb des Übersichtseintrags selbst, zu abgelaufenen Installer-Zertifikaten an Gewicht: Gilt der Satz über den vertrauenswürdigen Zeitstempel, überdauert ein Paket sein Zertifikat; gelten die anderen, dann nicht. Mein einziger Datenpunkt ist das oben genannte Paket von 2014, das Gatekeeper weiterhin akzeptiert. Wie diese Sätze gegeneinander zu gewichten sind, ist meine Lesart, nicht Apples.

Was würde ich tun, und in welcher Reihenfolge?

1. Bestandsaufnahme. Führen Sie die Schlüsselbund-Prüfung für beide Zertifikatstypen aus und pkgutil --check-signature für jedes Paket, das Sie noch zum Download anbieten, alte Versionen eingeschlossen. Die Paketprüfung funktioniert auch bei Installern anderer Anbieter; so finden Sie diejenigen, die Ihr Team verteilt und für die Sie einen neu signierten Build vom Anbieter brauchen.
2. Ersetzen. Zeigt ein Aussteller „Apple Certification Authority“, erstellen Sie ein G2-Zertifikat. Laut den Schritten der Hilfeseite wählen Sie, falls Sie aufgefordert werden, ein „Developer ID Certificate Intermediary“ (Developer-ID-Zwischenzertifikat) auszuwählen, „G2 Sub-CA (Xcode 11.4.1 or later)“, denn „Any other option might issue a certificate from the expiring Certificate Authority“ (jede andere Option könnte ein Zertifikat der auslaufenden Zertifizierungsstelle ausstellen), und die Mitteilung warnt, „Choosing another option may issue a certificate that also expires in 2027“ (eine andere Option kann ein Zertifikat ausstellen, das ebenfalls 2027 abläuft). Besitzen Sie beide Typen, gilt: „repeat these steps for each, since one certificate does not cover the other“ (wiederholen Sie diese Schritte für jeden, da ein Zertifikat den anderen Typ nicht abdeckt). Die Mitteilung nennt eine Voraussetzung: „If you’re using Xcode 11.4 or earlier, update before creating your new certificate.“ (Wenn Sie Xcode 11.4 oder älter verwenden, aktualisieren Sie, bevor Sie Ihr neues Zertifikat erstellen.)¹²
3. Testen, bevor das alte wegfällt. Apple: „Because you can hold up to five Developer ID Application and five Developer ID Installer certificates at a time, you can create and test a replacement before your current certificate expires.“ (Da Sie bis zu fünf Developer-ID-Application- und fünf Developer-ID-Installer-Zertifikate gleichzeitig besitzen können, lässt sich ein Ersatz erstellen und testen, bevor Ihr aktuelles Zertifikat abläuft.)²
4. Pakete neu signieren. Die Manpage von productsign sagt: „If you run productsign on a product archive that was previously signed, the existing signature will be replaced“ (wenn Sie productsign auf ein bereits signiertes Produktarchiv anwenden, wird die vorhandene Signatur ersetzt), und ein vertrauenswürdiger Zeitstempel „is enabled by default when signing with a Developer ID identity“ (ist beim Signieren mit einer Developer-ID-Identität standardmäßig aktiviert). Sie bettet außerdem „any intermediate certificates that are found in the keychain“ ein (alle im Schlüsselbund gefundenen Zwischenzertifikate), daher sollte das G2-Zwischenzertifikat zuerst im Schlüsselbund liegen (die Option --cert der Manpage benennt ein Zwischenzertifikat über den Common Name, und den teilen sich beide Zertifizierungsstellen, weshalb ich mich bei der Wahl zwischen ihnen nicht darauf verlassen würde): Laut Apples Seite von 2022 lädt Xcode 13.2 oder neuer es automatisch, andernfalls „you can download it from the Certificate Authority page“ (können Sie es von der Seite Certificate Authority herunterladen). Die obige Schlüsselbund-Pipeline, ausgeführt mit dem Namen „Developer ID Certification Authority“, listet die Zertifizierungsstellen auf, die ein Mac besitzt; meiner zeigt beide. Danach das Ergebnis erneut notarisieren und stapeln. Der Notarisierungsschritt ist meine Lesart, kein Satz von Apple: Ein neu signiertes Paket ist eine andere Datei. Ich besitze kein Developer-ID-Installer-Zertifikat und habe diesen Schritt daher nicht selbst ausgeführt.³⁴
5. Das Ergebnis prüfen. pkgutil --check-signature sollte bei der neu signierten Datei unter der Zertifizierungsstelle kein Datum aus 2027 mehr zeigen, und spctl -a -t install -vv sollte weiterhin „Notarized Developer ID“ melden.
6. App-Signaturen weiter mit Zeitstempel versehen. Ein sicherer Zeitstempel ist die Eigenschaft, die Apple für weiter funktionierende Software nennt, und Apples Anweisung für alles Kommende lautet: „sign with your new certificate and include a secure timestamp for notarization“ (mit dem neuen Zertifikat signieren und für die Notarisierung einen sicheren Zeitstempel hinzufügen).¹

Die Frist ist die zweite Installer-Änderung dieser Saison. Die erste steckt in macOS 27 selbst, wo ein Paket ohne Angabe einer Host-Architektur jetzt standardmäßig arm64 verwendet; der Beitrag zu Golden Gate erklärt, welche Pakete das betrifft, und ein Team, das seine Installer ohnehin neu signiert, kann beides in einem Durchgang prüfen. Der Beitrag zu den Versionshinweisen von macOS 27 behandelt den Rest dieser Version für Mac-Entwickler, der Beitrag zu Xcode 27 und der Intel-Beitrag decken die Toolchain ab, der Beitrag zum teamübergreifenden Container-Zugriff behandelt eine Änderung, die ausgelieferte Mac-Apps beim Lesen ohne jede Abfrage scheitern lässt, und der ld64-Beitrag beschreibt zwei Toolchain-Änderungen, die Mac-Builds abbrechen lassen.

FAQ

Wann läuft die Developer ID Certification Authority ab?

Am 1. Februar 2027. Das Zertifikat der ursprünglichen Zertifizierungsstelle endet an diesem Tag um 22:12:15 UTC. Die aktuelle Zertifizierungsstelle, G2, endet im September 2031; Apples Support-Seite nennt den 16. September, das Zertifikat selbst den 17. September um 00:00:00 GMT.¹³⁴

Startet meine Developer-ID-App ab dem 1. Februar 2027 nicht mehr?

Für notarisierte und mit sicherem Zeitstempel signierte Software sagt Apple nein: Sie „will keep working“ (funktioniert weiter), ohne dass etwas zu tun ist. codesign -dvv YourApp.app gibt eine Zeile Timestamp= aus, wenn die Signatur einen Zeitstempel hat, und spctl -a -t exec -vv YourApp.app meldet bei einer notarisierten App „source=Notarized Developer ID“.¹⁴

Was passiert mit .pkg-Installern, die unter der ursprünglichen Zertifizierungsstelle signiert sind?

Apple: „Starting February 1, 2027, .pkg files signed with an affected certificate will no longer install. Re-sign all packages with your new certificate before this date.“ (Ab dem 1. Februar 2027 lassen sich mit einem betroffenen Zertifikat signierte .pkg-Dateien nicht mehr installieren. Signieren Sie alle Pakete vor diesem Datum mit Ihrem neuen Zertifikat neu.)¹

Wie prüfe ich, welche Zertifizierungsstelle ein Paket signiert hat?

Führen Sie pkgutil --check-signature darauf aus und lesen Sie das Datum unter dem Eintrag „Developer ID Certification Authority“ in der Kette. Expires: 2027-02-01 22:12:15 +0000 steht für die ursprüngliche Zertifizierungsstelle.⁴

Gelten G2-Zertifikate ein Jahr oder fünf?

Apples Mitteilung und Hilfeseite sagen beide: ein Jahr. Jedes G2-Zertifikat, das ich am 1. Oktober 2026 prüfen konnte, das jüngste ausgestellt am 29. Mai 2026, gilt fünf Jahre. Keine der beiden Seiten sagt, seit wann die einjährige Laufzeit gilt.¹²⁴

Wer im Team kann das Ersatzzertifikat erstellen?

Die Hilfeseite nennt „Required role: Account Holder.“ (Erforderliche Rolle: Account Holder.)²

Quellen