Developer ID Certification Authority wygasa 1 lutego 2027 roku

Apple ogłosiło 1 października 2026 roku, że pierwotny Developer ID Certification Authority wygasa 1 lutego 2027 roku i że od tego dnia pakiety instalacyjne podpisane wydanym przez niego certyfikatem „will no longer install” (przestaną się instalować). Aplikacje notaryzowane są bezpieczne: „Previously signed and notarized Mac software (with a secure timestamp) will keep working.” (Wcześniej podpisane i notaryzowane oprogramowanie na Maca, z bezpiecznym znacznikiem czasu, nadal będzie działać.)¹ Następca, urząd G2, wydaje certyfikaty od 27 stycznia 2022 roku, a Apple nadal oferowało pierwotny urząd zespołom korzystającym ze starych wersji Xcode, więc zespół może mieć certyfikat z każdego z nich.²³ Testem Apple jest Organizational Unit (jednostka organizacyjna) w nazwie wystawcy certyfikatu, a nie data wygaśnięcia.

Poniżej znajdują się polecenia, które odczytują tę wartość z pęku kluczy, z pakietu i z aplikacji; to, co wypisują dla 66 aplikacji Developer ID i czterech instalatorów na moim własnym Macu, gdzie 49 aplikacji i wszystkie cztery instalatory prowadzą łańcuchem do wygasającego urzędu; jedno zdanie z komunikatu Apple, z którym nie zgadzają się certyfikaty, jakie mogę sprawdzić; oraz kolejność, w jakiej sam podpisywałbym wszystko ponownie.⁴

TL;DR

• Data. Certyfikat pierwotnego urzędu kończy ważność 1 lutego 2027 roku o 22:12:15 UTC, co do sekundy piętnaście lat po jej rozpoczęciu. Apple: „Certificates issued by this authority will stop working on that date.” (Certyfikaty wydane przez ten urząd przestaną działać tego dnia.)¹⁴
• Pakiety przestają działać, aplikacje notaryzowane nie. „.pkg files signed with an affected certificate will no longer install” (pliki .pkg podpisane certyfikatem objętym zmianą przestaną się instalować), natomiast notaryzowane oprogramowanie z bezpiecznym znacznikiem czasu „will keep working” (nadal będzie działać).¹
• Liczy się wystawca. Organizational Unit wystawcy to „Apple Certification Authority” na certyfikacie z pierwotnego urzędu i „G2” na certyfikacie z obecnego urzędu. Apple zaznacza, że data wygaśnięcia „doesn’t prove which authority issued a certificate” (nie dowodzi, który urząd wydał certyfikat).²
• Próbka z jednego Maca. Wszystkie cztery instalatory podpisane Developer ID w moim folderze Pobrane prowadzą do pierwotnego urzędu, a najnowszy z nich podpisano 29 grudnia 2025 roku. Spośród 66 aplikacji Developer ID w moim folderze Programy 49 prowadzi do niego, a 17 do G2.⁴
• Jak dotąd wygaśnięcie nie zatrzymało oprogramowania ze znacznikiem czasu. Sześć z tych 49 aplikacji podpisano certyfikatami, które wygasły między 2022 rokiem a majem 2026 roku, a jeden instalator certyfikatem, który wygasł w 2017 roku. Gatekeeper akceptuje dziś wszystkie siedem. Komunikat Apple mówi, że wygaśnięcie samego urzędu kończy ten stan rzeczy w przypadku pakietów.¹⁴
• Jedna niezgodność. Apple pisze, że certyfikaty G2 „expire annually” (wygasają co roku). Wszystkie 12 certyfikatów G2 w moich zainstalowanych aplikacjach, a także mój własny z maja 2026 roku, są ważne pięć lat. Żadna z dwóch stron nie podaje, od kiedy obowiązują okresy roczne.¹²⁴

Co ogłosiło Apple?

Komunikat jest krótki. Zaczyna się tak: „The original Developer ID Certification Authority (Sub-CA) expires on February 1, 2027. Certificates issued by this authority will stop working on that date.” (Pierwotny Developer ID Certification Authority, czyli Sub-CA, wygasa 1 lutego 2027 roku. Certyfikaty wydane przez ten urząd przestaną działać tego dnia.)¹ Dalej następują trzy kroki: sprawdzenie, czy zmiana kogoś dotyczy, utworzenie nowego certyfikatu i ponowne podpisanie. Trzeci krok zależy od tego, co się dystrybuuje:

• Pakiety instalacyjne. „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.” (Od 1 lutego 2027 roku pliki .pkg podpisane certyfikatem objętym zmianą przestaną się instalować. Przed tą datą należy ponownie podpisać wszystkie pakiety nowym certyfikatem.)
• Aplikacje na Maca. „Previously signed and notarized Mac software (with a secure timestamp) will keep working” (wcześniej podpisane i notaryzowane oprogramowanie na Maca, z bezpiecznym znacznikiem czasu, nadal będzie działać), bez żadnych działań, oraz „For future updates, sign with your new certificate and include a secure timestamp for notarization.” (Przyszłe aktualizacje należy podpisywać nowym certyfikatem i dołączać bezpieczny znacznik czasu na potrzeby notaryzacji.)¹

Strona pomocy, do której odsyła komunikat, opisuje skutek dla podpisywania: „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).” (Po tej dacie certyfikatów wydanych przez pierwotny urząd nie można już używać do podpisywania i trzeba je zastąpić certyfikatami z obecnego Developer ID Certification Authority, czyli G2.) Wymienia też „Required role: Account Holder.” (Wymagana rola: Account Holder.)²

Podział na aplikacje i pakiety jest bliski stałym wytycznym Apple dotyczącym wygasłych certyfikatów. W przypadku aplikacji strona pomocy Apple o Developer ID mówi: „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.” (Jeśli certyfikat Developer ID był ważny w chwili kompilacji aplikacji, użytkownicy mogą ją pobrać i uruchomić nawet po dacie wygaśnięcia certyfikatu.) W przypadku instalatorów strony Apple nie są zgodne, nawet same ze sobą. Ta sama strona pomocy mówi: „Your installer package will only launch if your Developer ID Installer certificate is valid.” (Pakiet instalacyjny uruchomi się tylko wtedy, gdy certyfikat Developer ID Installer jest ważny.) Wpis o Developer ID Installer w przeglądzie certyfikatów ciągnie w obie strony: użytkownicy „can still install packages that were signed with this certificate as long as the package includes a trusted timestamp” (nadal mogą instalować pakiety podpisane tym certyfikatem, o ile pakiet zawiera zaufany znacznik czasu), a jednak dwa zdania dalej „new installations won’t be possible until you have re-signed your installer package with a valid Developer ID Installer certificate.” (nowe instalacje nie będą możliwe, dopóki pakiet instalacyjny nie zostanie ponownie podpisany ważnym certyfikatem Developer ID Installer.)⁵ Komunikat z 1 października nie daje pakietom żadnego wyjątku ze względu na znacznik czasu.

Komunikat mówi wyłącznie o instalowaniu. Nie wyjaśnia, co stanie się z oprogramowaniem już zainstalowanym z pakietu objętego zmianą, ani czy instalacje wypychane przez zarządzanie urządzeniami lub uruchamiane poleceniem installer są traktowane tak samo jak pakiet otwarty przez użytkownika. Nie wspomina też o podpisanych obrazach dysków. W pierwszej kwestii wpis przeglądu dotyczący wygasłego certyfikatu instalatora mówi: „Previously installed apps will continue to run.” (Wcześniej zainstalowane aplikacje nadal będą działać.)¹⁵

Dlaczego istnieją dwa urzędy?

Certyfikat nie może przeżyć urzędu, który go wydał. Strona wsparcia Apple z 2022 roku ujmuje to jako regułę: „Certificates cannot be issued with a validity period that extends past the intermediate certificate’s expiration date.” (Nie można wydawać certyfikatów z okresem ważności sięgającym poza datę wygaśnięcia certyfikatu pośredniego.)³ Każdy certyfikat Developer ID sprzed 2022 roku, jaki udaje mi się znaleźć, jest ważny pięć lat, więc od lutego 2022 roku pierwotny urząd, któremu zostało pięć lat, nie mógł już wydać certyfikatu na pełny okres. Odpowiedzią Apple był drugi urząd: „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.” (Od 27 stycznia 2022 roku certyfikaty cyfrowe służące do podpisywania oprogramowania i pakietów instalacyjnych w macOS będą wydawane z nowego certyfikatu pośredniego Developer ID, który wygasa 16 września 2031 roku.) (Sam certyfikat traci ważność 17 września 2031 roku o 00:00:00 GMT, czyli według czasu pacyficznego wciąż 16 września.)³⁴

Pierwotny urząd pozostał w ofercie. Dla zespołów „running Xcode 11.4 or earlier” (korzystających z Xcode 11.4 lub starszego) Apple napisało, że „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” (witryna Apple Developer nadal będzie oferować certyfikaty Developer ID powiązane z pierwotnym certyfikatem pośrednim; nowo wydane z niego certyfikaty będą ważne krócej niż pięć lat), a opcja ta „will be available for at least one year, starting January 27, 2022.” (będzie dostępna przez co najmniej rok, licząc od 27 stycznia 2022 roku.)³

Certyfikaty na moim Macu pokazują obie połowy tej historii. 49 aplikacji prowadzących do pierwotnego urzędu nosi 27 różnych certyfikatów podpisujących. Pięć wydanych przed lutym 2022 roku jest ważnych po pięć lat. Wszystkie 22 wydane od 8 lutego 2022 roku kończą ważność w tej samej sekundzie, 1 lutego 2027 roku o 22:12:15 UTC, czyli w ostatniej sekundzie samego urzędu, a najnowszy z nich wydano 15 stycznia 2026 roku. Pierwotny urząd wciąż wydawał certyfikaty niemal cztery lata po pojawieniu się G2, każdy krótszy od poprzedniego.⁴

Jak sprawdzić, który urząd wydał mój certyfikat?

Strona pomocy Apple zaczyna od portalu deweloperskiego: „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.” (Wszystkie certyfikaty wygasające 1 lutego 2027 roku lub wcześniej prawdopodobnie są objęte zmianą. Sama data wygaśnięcia nie dowodzi jednak, który urząd wydał certyfikat.) Podany powód: „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.” (Zespół może mieć certyfikat z każdego urzędu o identycznej nazwie, na przykład dwa razy ten sam wpis Developer ID Installer, różniące się tylko datą wygaśnięcia.) Test Apple odbywa się w Keychain Access: należy zaznaczyć certyfikat, „expand the Issuer Name field, and review the Organizational Unit field” (rozwinąć pole Issuer Name i sprawdzić pole Organizational Unit). „Apple Certification Authority” oznacza „The certificate was issued from the previous Sub-CA. Replace this certificate.” (Certyfikat wydał poprzedni Sub-CA. Należy go zastąpić.) „G2” oznacza „The certificate was issued from the current Sub-CA. No action needed.” (Certyfikat wydał obecny Sub-CA. Nie trzeba nic robić.) Strona dodaje ostrzeżenie: „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.” (Należy sprawdzić własny certyfikat, a nie wpis Developer ID Certification Authority w pęku kluczy. Ten wpis to sam urząd, wydany przez Apple Root CA, którego Organizational Unit również brzmi Apple Certification Authority.)²

Ten sam test można przeprowadzić z terminala, w trzech miejscach.

Certyfikat w pęku kluczy.

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

Flaga -a zwraca wszystkie dopasowania, co ma znaczenie ze względu na ostrzeżenie Apple o identycznych nazwach, a potok wypisuje dla każdego z nich wiersz podmiotu i wiersz wystawcy. Dla certyfikatu do podpisywania aplikacji wystarczy podstawić „Developer ID Application”. Mój Mac ma jeden certyfikat Developer ID Application i żadnego certyfikatu Installer, a przy systemowym /usr/bin/openssl jego wiersz wystawcy brzmi issuer=/CN=Developer ID Certification Authority/OU=G2/O=Apple Inc./C=US. OpenSSL 3 z Homebrew wypisuje te same pola rozdzielone przecinkami. Nazwa bez dopasowania nie wypisuje niczego.⁴

Wydany już pakiet.

pkgutil --check-signature YourProduct.pkg

Wynik pokazuje stan podpisu, stan notaryzacji, zaufany znacznik czasu i łańcuch certyfikatów. Datę należy odczytać pod drugim wpisem, „Developer ID Certification Authority”. W każdym z moich czterech instalatorów brzmi ona Expires: 2027-02-01 22:12:15 +0000. Własny certyfikat G2 kończy ważność 17 września 2031 roku (GMT), więc pakiet podpisany w ramach G2 powinien w tym miejscu pokazywać tę datę. Nie mam pakietu podpisanego w ramach G2, by to potwierdzić.⁴

Aplikacja. Samo codesign -dvv nie wystarczy, ponieważ oba urzędy mają tę samą nazwę pospolitą (Common Name), a jego wiersze Authority= wyglądają identycznie dla każdego z nich. Należy wyodrębnić łańcuch i odczytać certyfikat pośredni:

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

Dla aplikacji z mojego folderu Programy podpisanej w ramach G2 drugie polecenie wypisuje OU=G2 w podmiocie i notAfter=Sep 17 00:00:00 2031 GMT. Dla aplikacji podpisanej w ramach pierwotnego urzędu wypisuje OU=Apple Certification Authority i notAfter=Feb 1 22:12:15 2027 GMT.⁴

Co pokazuje oprogramowanie na jednym Macu?

Instalatory. W moim folderze Pobrane są cztery pakiety podpisane Developer ID, od dwóch dostawców, i wszystkie cztery prowadzą do pierwotnego urzędu. Trzy pochodzą od jednego dostawcy i zostały podpisane 28 września, 14 grudnia i 29 grudnia 2025 roku certyfikatem instalatora wydanym 13 kwietnia 2022 roku, ważnym do 1 lutego 2027 roku. Ten dostawca jeszcze dziewięć miesięcy temu podpisywał pakiety w ramach pierwotnego urzędu. Czwarty podpisano w lutym 2014 roku certyfikatem, który wygasł 29 marca 2017 roku.⁴

Ocena instalacji przez Gatekeepera, spctl -a -t install -vv, akceptuje dziś wszystkie cztery jako „Notarized Developer ID”, łącznie z tym, którego certyfikat podpisujący wygasł dziewięć lat temu. Ten wynik zgadza się ze zdaniem o zaufanym znaczniku czasu we wpisie o instalatorach w przeglądzie certyfikatów, a nie ze zdaniem „new installations won’t be possible” (nowe instalacje nie będą możliwe) z tego samego wpisu ani ze stroną pomocy o Developer ID. Jest to też zachowanie, które według komunikatu Apple kończy się dla pakietów 1 lutego. W październiku nie mogę przetestować lutego, więc to, co stanie się tego dnia, jest stwierdzeniem Apple, a nie moją obserwacją.¹⁴⁵

Aplikacje. Spośród 66 aplikacji w moim folderze Programy podpisanych Developer ID 49 prowadzi do pierwotnego urzędu, a 17 do G2. Wszystkie 66 podpisów zawiera bezpieczny znacznik czasu. Gatekeeper zgłasza 63 jako „Notarized Developer ID”, czyli połączenie, które według Apple nadal działa: 46 z 49 w ramach pierwotnego urzędu i wszystkie 17 w ramach G2. Z pozostałych trzech, wszystkich w ramach pierwotnego urzędu, dwie nie przechodzą oceny z komunikatem „a sealed resource is missing or invalid”, czyli błędem dotyczącym zawartości pakietu aplikacji, a jedna, podpisana w lipcu 2018 roku, jest akceptowana jako Developer ID bez notaryzacji. Zdanie Apple obejmuje oprogramowanie notaryzowane, a komunikat nie mówi, co stanie się z aplikacją taką jak ta ostatnia.¹⁴

Sześć z 49 podpisano certyfikatami, które do 1 października 2026 roku już wygasły, najwcześniej w sierpniu 2022 roku, najpóźniej w maju 2026 roku. Gatekeeper akceptuje wszystkie sześć, pięć z nich jako notaryzowane. Reguła Apple dla aplikacji, zgodnie z którą wystarcza certyfikat ważny w chwili podpisywania, już działa w oprogramowaniu, którego używam.⁴⁵

Które zdanie komunikatu się nie zgadza?

Komunikat mówi o G2: „This certificate authority is valid until 2031, but the certificates issued by the certificate authority expire annually and must be renewed each year.” (Ten urząd certyfikacji jest ważny do 2031 roku, ale wydawane przez niego certyfikaty wygasają co roku i trzeba je odnawiać corocznie.) Strona pomocy mówi to samo: „Certificates issued from G2 are valid for one year and must be renewed annually.” (Certyfikaty wydane przez G2 są ważne przez rok i trzeba je odnawiać co roku.)¹²

Certyfikaty G2, które mogę sprawdzić, nie są certyfikatami rocznymi. 17 aplikacji podpisanych w ramach G2 na moim Macu nosi 12 różnych certyfikatów podpisujących, wydanych między lutym 2023 roku a 29 maja 2026 roku, i każdy z nich jest ważny pięć lat. Trzy z nich wydano w kwietniu i maju 2026 roku. Mój własny certyfikat Developer ID Application, wydany 10 maja 2026 roku, kończy ważność 11 maja 2031 roku.⁴

Żadna z dwóch stron nie podaje, od kiedy obowiązuje roczna ważność, a od czasu komunikatu nie tworzyłem certyfikatu, więc nie wiem, z jakim okresem ważności przychodzi certyfikat wydany dzisiaj. Warto planować coroczne odnawianie i odczytać daty na certyfikacie, który faktycznie zostanie wydany. Jeśli od teraz regułą mają być certyfikaty roczne, niezgodność między stronami Apple, a także wewnątrz samego wpisu przeglądu, w kwestii wygasłych certyfikatów instalatora zaczyna mieć większe znaczenie: jeśli obowiązuje zdanie o zaufanym znaczniku czasu, pakiet przeżywa swój certyfikat, a jeśli obowiązują pozostałe, nie przeżywa. Jedynym punktem danych, jaki mam, jest wspomniany wyżej pakiet z 2014 roku, który Gatekeeper wciąż akceptuje. To, jak te zdania ważą się nawzajem, jest moją interpretacją, nie stanowiskiem Apple.

Co zrobiłbym, po kolei?

1. Inwentaryzacja. Uruchomić sprawdzenie pęku kluczy dla obu typów certyfikatów oraz pkgutil --check-signature dla każdego pakietu, który wciąż jest dostępny do pobrania, łącznie ze starymi wersjami. Sprawdzenie pakietu działa też na instalatorach innych dostawców, dzięki czemu można znaleźć te wdrażane przez zespół, które wymagają od dostawcy ponownie podpisanej kompilacji.
2. Wymiana. Jeśli wystawca pokazuje „Apple Certification Authority”, należy utworzyć certyfikat G2. Kroki na stronie pomocy mówią, że w razie prośby o wybranie opcji „Developer ID Certificate Intermediary” (certyfikat pośredni Developer ID) należy wybrać „G2 Sub-CA (Xcode 11.4.1 or later)”, ponieważ „Any other option might issue a certificate from the expiring Certificate Authority” (każda inna opcja może wydać certyfikat z wygasającego urzędu certyfikacji), a komunikat ostrzega, że „Choosing another option may issue a certificate that also expires in 2027.” (Wybór innej opcji może skutkować certyfikatem, który również wygasa w 2027 roku.) Przy obu typach certyfikatów należy „repeat these steps for each, since one certificate does not cover the other.” (powtórzyć te kroki dla każdego, ponieważ jeden certyfikat nie obejmuje drugiego). Komunikat dodaje warunek wstępny: „If you’re using Xcode 11.4 or earlier, update before creating your new certificate.” (Przy Xcode 11.4 lub starszym należy przed utworzeniem nowego certyfikatu przeprowadzić aktualizację.)¹²
3. Test, zanim stary certyfikat zniknie. 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.” (Ponieważ można jednocześnie mieć do pięciu certyfikatów Developer ID Application i pięciu Developer ID Installer, da się utworzyć i przetestować zamiennik przed wygaśnięciem obecnego certyfikatu.)²
4. Ponowne podpisanie pakietów. Podręcznik productsign mówi: „If you run productsign on a product archive that was previously signed, the existing signature will be replaced” (uruchomienie productsign na wcześniej podpisanym archiwum produktu zastąpi istniejący podpis), a zaufany znacznik czasu „is enabled by default when signing with a Developer ID identity.” (jest domyślnie włączony przy podpisywaniu tożsamością Developer ID). Narzędzie osadza też „any intermediate certificates that are found in the keychain” (wszelkie certyfikaty pośrednie znalezione w pęku kluczy), więc certyfikat pośredni G2 powinien najpierw znaleźć się w pęku kluczy (opcja --cert z podręcznika wskazuje certyfikat pośredni po nazwie pospolitej, a oba urzędy noszą tę samą nazwę, więc nie polegałbym na niej przy wyborze między nimi): strona Apple z 2022 roku podaje, że Xcode 13.2 lub nowszy pobiera go automatycznie, a w przeciwnym razie „you can download it from the Certificate Authority page.” (można go pobrać ze strony Certificate Authority). Opisany wyżej potok dla pęku kluczy, uruchomiony z nazwą „Developer ID Certification Authority”, wypisuje urzędy obecne na danym Macu; mój pokazuje oba. Następnie wynik należy ponownie poddać notaryzacji i zszywaniu (staple). Krok notaryzacji to moja interpretacja, a nie zdanie Apple: ponownie podpisany pakiet jest innym plikiem. Nie mam certyfikatu Developer ID Installer, więc tego kroku nie wykonałem.³⁴
5. Sprawdzenie wyniku. pkgutil --check-signature na ponownie podpisanym pliku nie powinno już pokazywać daty z 2027 roku pod urzędem, a spctl -a -t install -vv powinno nadal zgłaszać „Notarized Developer ID”.
6. Znaczniki czasu w podpisach aplikacji. Bezpieczny znacznik czasu to cecha, którą Apple wskazuje dla oprogramowania, które nadal działa, a jego polecenie na przyszłość brzmi: „sign with your new certificate and include a secure timestamp for notarization.” (podpisywać nowym certyfikatem i dołączać bezpieczny znacznik czasu na potrzeby notaryzacji).¹

Ten termin to druga w tym sezonie zmiana dotycząca instalatorów. Pierwsza jest w samym macOS 27, gdzie pakiet niewskazujący żadnej architektury hosta domyślnie przyjmuje teraz arm64; wpis o Golden Gate opisuje, których pakietów to dotyczy, a zespół, który i tak podpisuje instalatory ponownie, może sprawdzić obie rzeczy naraz. Wpis o notach wydania macOS 27 omawia resztę tego wydania z perspektywy deweloperów aplikacji na Maca, wpis o Xcode 27 i wpis o Intelu obejmują stronę narzędzi, wpis o dostępie do kontenerów między zespołami opisuje zmianę, przez którą wydane już aplikacje na Maca zawodzą w chwili odczytu, bez żadnego monitu, a wpis o ld64 omawia dwie zmiany w narzędziach, które zatrzymują kompilacje na Maca.

FAQ

Kiedy wygasa Developer ID Certification Authority?

1 lutego 2027 roku. Certyfikat pierwotnego urzędu kończy ważność tego dnia o 22:12:15 UTC. Obecny urząd, G2, wygasa we wrześniu 2031 roku; strona wsparcia Apple podaje 16 września, a sam certyfikat 17 września, godzinę 00:00:00 GMT.¹³⁴

Czy moja aplikacja Developer ID przestanie się uruchamiać 1 lutego 2027 roku?

Apple odpowiada, że nie, w przypadku oprogramowania notaryzowanego i podpisanego z bezpiecznym znacznikiem czasu: „will keep working” (nadal będzie działać), bez żadnych działań. codesign -dvv YourApp.app wypisuje wiersz Timestamp=, gdy podpis go zawiera, a spctl -a -t exec -vv YourApp.app zgłasza „source=Notarized Developer ID” dla aplikacji notaryzowanej.¹⁴

Co stanie się z instalatorami .pkg podpisanymi w ramach pierwotnego urzędu?

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.” (Od 1 lutego 2027 roku pliki .pkg podpisane certyfikatem objętym zmianą przestaną się instalować. Przed tą datą należy ponownie podpisać wszystkie pakiety nowym certyfikatem.)¹

Jak sprawdzić, który urząd podpisał pakiet?

Należy uruchomić na nim pkgutil --check-signature i odczytać datę pod wpisem „Developer ID Certification Authority” w łańcuchu. Expires: 2027-02-01 22:12:15 +0000 oznacza pierwotny urząd.⁴

Czy certyfikaty G2 są ważne rok, czy pięć lat?

Komunikat Apple i strona pomocy podają rok. Każdy certyfikat G2, jaki mogłem sprawdzić 1 października 2026 roku, z najnowszym wydanym 29 maja 2026 roku, jest ważny pięć lat. Żadna z dwóch stron nie podaje, od kiedy obowiązuje okres roczny.¹²⁴

Kto w zespole może utworzyć zamiennik?

Strona pomocy wymienia „Required role: Account Holder.” (Wymagana rola: Account Holder.)²

Źródła