Developer ID Certification Authorityは2027年2月1日に失効

Appleは2026年10月1日、元のDeveloper ID Certification Authorityが2027年2月1日に失効し、その認証局が発行した証明書で署名されたインストーラパッケージはその日から「will no longer install」（インストールできなくなる）と発表しました。 公証済みのアプリは対象外です。「Previously signed and notarized Mac software (with a secure timestamp) will keep working.」（署名と公証を済ませた既存のMacソフトウェアは、セキュアタイムスタンプがあれば引き続き動作する）¹ 後継の認証局であるG2は2022年1月27日から証明書を発行していますが、Appleは古いXcodeを使うチーム向けに元の認証局も提供し続けたため、1つのチームが両方の認証局の証明書を持っていることがあります。²³ Appleが示す判定基準は有効期限ではなく、証明書の発行者名に含まれるOrganizational Unit（組織単位）です。

以下では、キーチェーン、パッケージ、アプリのそれぞれからこの値を読み取るコマンドを紹介します。続いて、私自身のMacにあるDeveloper ID署名のアプリ66本とインストーラ4つでの出力を示します。このうちアプリ49本とインストーラ4つすべてが、失効する認証局につながっていました。さらに、Appleの告知のうち、私が調べられる証明書と一致しない一文と、私なら再署名をどの順番で進めるかを取り上げます。⁴

TL;DR

• 日付。 元の認証局の証明書は2027年2月1日22:12:15 UTCに期限を迎えます。開始からちょうど15年、秒単位まで同じ時刻です。Appleは「Certificates issued by this authority will stop working on that date.」（この認証局が発行した証明書はその日に機能しなくなる）と書いています。¹⁴
• 止まるのはパッケージで、公証済みアプリは止まりません。 「.pkg files signed with an affected certificate will no longer install」（影響を受ける証明書で署名された.pkgファイルはインストールできなくなる）一方で、セキュアタイムスタンプ付きの公証済みソフトウェアは「will keep working」（引き続き動作する）とされています。¹
• 発行者を読みましょう。 発行者のOrganizational Unitは、元の認証局が発行した証明書では「Apple Certification Authority」、現行の認証局が発行した証明書では「G2」です。Appleは、有効期限は「doesn’t prove which authority issued a certificate」（どちらの認証局が証明書を発行したかの証明にはならない）と述べています。²
• 1台のMacのサンプル。 私のダウンロードフォルダにあるDeveloper ID署名のインストーラ4つはすべて元の認証局につながっており、最も新しいものは2025年12月29日に署名されていました。アプリケーションフォルダにあるDeveloper IDアプリ66本のうち、49本が元の認証局に、17本がG2につながっています。⁴
• これまでのところ、期限切れはタイムスタンプ付きのソフトウェアを止めていません。 元の認証局につながる49本のうち6本は2022年から2026年5月までの間に期限が切れた証明書で署名され、インストーラ1つは2017年に期限が切れた証明書で署名されています。Gatekeeperは現時点でこの7つすべてを受け入れます。Appleの告知によれば、パッケージについては、認証局そのものの失効によってこの扱いが終わります。¹⁴
• 食い違いが1つ。 AppleはG2の証明書が「expire annually」（毎年失効する）と書いています。しかし、私のインストール済みアプリにあるG2の証明書12枚すべてと、2026年5月に取得した私自身の証明書は、有効期間が5年です。1年の期間がいつ始まったのかは、どちらのページにも書かれていません。¹²⁴

Appleは何を発表したのか？

告知は短いものです。冒頭はこうです。「The original Developer ID Certification Authority (Sub-CA) expires on February 1, 2027. Certificates issued by this authority will stop working on that date.」（元のDeveloper ID Certification Authority（Sub-CA）は2027年2月1日に失効する。この認証局が発行した証明書はその日に機能しなくなる）¹ そのあとに3つのステップが続きます。影響を受けるかどうかを確認する、新しい証明書を作成する、再署名する、の3つです。3つ目のステップは、何を配布しているかによって変わります。

• インストーラパッケージ。 「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.」（2027年2月1日以降、影響を受ける証明書で署名された.pkgファイルはインストールできなくなる。この日までに、すべてのパッケージを新しい証明書で再署名すること）
• Macアプリ。 「Previously signed and notarized Mac software (with a secure timestamp) will keep working」（署名と公証を済ませた既存のMacソフトウェアは、セキュアタイムスタンプがあれば引き続き動作する）とされ、対応は不要です。そのうえで「For future updates, sign with your new certificate and include a secure timestamp for notarization.」（今後のアップデートでは、新しい証明書で署名し、公証のためにセキュアタイムスタンプを含めること）とあります。¹

告知がリンクしているヘルプページは、署名への影響をこう説明しています。「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).」（その日以降、元の認証局から発行された証明書は署名に使えなくなり、現行のDeveloper ID Certification Authority（G2）の証明書に置き換える必要がある）また、「Required role: Account Holder.」（必要な役割：Account Holder）とも記載されています。²

アプリとパッケージで扱いを分ける考え方は、期限切れの証明書に関するAppleの従来からの案内に近いものです。アプリについて、Appleの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.」（アプリをコンパイルした時点でDeveloper ID証明書が有効であれば、証明書の有効期限が過ぎた後でも、ユーザーはアプリをダウンロードして実行できる）インストーラについては、Appleのページ同士で、さらには同じページの中でも記述が食い違っています。同じヘルプページには「Your installer package will only launch if your Developer ID Installer certificate is valid.」（インストーラパッケージは、Developer ID Installer証明書が有効な場合にのみ起動する）とあります。証明書の概要ページにあるDeveloper ID Installerの項目は、両方向に引っ張られています。ユーザーは「can still install packages that were signed with this certificate as long as the package includes a trusted timestamp」（パッケージに信頼できるタイムスタンプが含まれていれば、この証明書で署名されたパッケージを引き続きインストールできる）と書きながら、その2文後には「new installations won’t be possible until you have re-signed your installer package with a valid Developer ID Installer certificate」（有効なDeveloper ID Installer証明書でインストーラパッケージを再署名するまで、新規のインストールはできない）と書いているのです。⁵ 10月1日の告知は、パッケージにタイムスタンプによる例外を設けていません。

告知が触れているのはインストールのことだけです。影響を受けるパッケージからすでにインストールされたソフトウェアがどうなるのかは書かれていません。デバイス管理で配布されるインストールやinstallerコマンドで実行するインストールが、ユーザーが開くパッケージと同じ扱いになるのかどうかも書かれていません。署名済みのディスクイメージにも言及していません。1つ目の点については、概要ページの期限切れインストーラ証明書の項目に「Previously installed apps will continue to run.」（以前にインストールされたアプリは引き続き動作する）とあります。¹⁵

なぜ認証局が2つあるのか？

証明書は、それを発行した認証局より長く有効にはなれません。Appleの2022年のサポートページは、これを規則として述べています。「Certificates cannot be issued with a validity period that extends past the intermediate certificate’s expiration date.」（中間証明書の有効期限を超える有効期間で証明書を発行することはできない）³ 2022年より前のDeveloper ID証明書で私が見つけられたものは、すべて有効期間が5年です。したがって2022年2月以降、残り5年となった元の認証局は、5年満期の証明書を発行できなくなりました。Appleの答えは2つ目の認証局でした。「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.」（2022年1月27日以降、macOSでソフトウェアとインストーラパッケージの署名に使うデジタル証明書は、2031年9月16日に失効する新しいDeveloper ID中間証明書から発行される）（証明書そのものの期限は2031年9月17日00:00:00 GMTで、太平洋時間ではまだ9月16日です。）³⁴

元の認証局も引き続き提供されました。Appleは「running Xcode 11.4 or earlier」（Xcode 11.4以前を使っている）チーム向けに、こう書いています。「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」（Apple Developerウェブサイトは、元の中間証明書に紐づくDeveloper ID証明書を引き続き提供する。この中間証明書から新たに発行される証明書の有効期間は5年未満になる）。この選択肢は「will be available for at least one year, starting January 27, 2022」（2022年1月27日から少なくとも1年間は利用できる）とされていました。³

私のMacにある証明書には、この経緯の両面が表れています。元の認証局につながる49本のアプリは、27種類の署名証明書を使っています。2022年2月より前に発行された5枚は、いずれも有効期間が5年です。2022年2月8日以降に発行された22枚は、すべて同じ秒、つまり2027年2月1日22:12:15 UTCに期限を迎えます。これは元の認証局そのものの最後の1秒であり、22枚のうち最も新しいものは2026年1月15日に発行されていました。元の認証局は、G2が登場してから4年近く経っても証明書を発行し続けており、1枚ごとに有効期間が短くなっていったのです。⁴

自分の証明書をどちらの認証局が発行したのか、どう見分けるか？

Appleのヘルプページは、デベロッパポータルから確認を始めます。「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.」（2027年2月1日以前に期限を迎える証明書は、おそらく影響を受ける。ただし、有効期限だけでは、どちらの認証局が証明書を発行したかの証明にはならない）その理由として挙げられているのはこうです。「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.」（1つのチームが、同じ名前の証明書を両方の認証局から持つことがある。たとえば、有効期限だけが異なる同じDeveloper ID Installerの項目が2つ並ぶ）Appleの判定方法はKeychain Accessで行います。証明書を選択し、「expand the Issuer Name field, and review the Organizational Unit field」（発行者名のフィールドを展開し、Organizational Unitのフィールドを確認する）という手順です。「Apple Certification Authority」なら「The certificate was issued from the previous Sub-CA. Replace this certificate.」（この証明書は以前のSub-CAから発行された。この証明書を置き換えること）、「G2」なら「The certificate was issued from the current Sub-CA. No action needed.」（この証明書は現行のSub-CAから発行された。対応は不要）という意味です。ページには注意書きもあります。「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.」（確認するのは自分の証明書であり、キーチェーン内のDeveloper ID Certification Authorityの項目ではない。その項目は認証局そのものであり、Apple Root CAによって発行されている。Apple Root CAのOrganizational UnitもApple Certification Authorityである）²

同じ判定はターミナルからも、3つの場所で実行できます。

キーチェーン内の証明書。

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

-aフラグは一致するものをすべて返します。Appleの同名に関する注意を考えると、これが重要です。このパイプラインは、証明書ごとにsubject行とissuer行を出力します。アプリ署名用の証明書を調べるには、「Developer ID Application」に置き換えてください。私のMacにはDeveloper ID Application証明書が1枚あり、Installer証明書はありません。システムの/usr/bin/opensslで読むと、issuer行はissuer=/CN=Developer ID Certification Authority/OU=G2/O=Apple Inc./C=USとなります。HomebrewのOpenSSL 3では、同じフィールドがカンマ区切りで出力されます。一致する名前がなければ、何も出力されません。⁴

出荷済みのパッケージ。

pkgutil --check-signature YourProduct.pkg

出力には、署名の状態、公証の状態、信頼できるタイムスタンプ、証明書チェーンが並びます。読むべき日付は、2つ目の項目「Developer ID Certification Authority」の下にあるものです。私のインストーラ4つでは、いずれもExpires: 2027-02-01 22:12:15 +0000でした。G2自身の証明書は2031年9月17日（GMT）に期限を迎えるので、G2の配下で署名されたパッケージなら、そこにはその日付が表示されるはずです。ただし、私はG2で署名されたパッケージを持っていないため、確認はできていません。⁴

アプリ。 codesign -dvvだけでは足りません。2つの認証局は同じコモンネームを共有しているので、そのAuthority=行はどちらの場合も同じ表示になるからです。チェーンを取り出して、中間証明書を読みましょう。

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

私のアプリケーションフォルダにあるG2署名のアプリでは、2つ目のコマンドがsubjectにOU=G2を、そしてnotAfter=Sep 17 00:00:00 2031 GMTを出力します。元の認証局の配下で署名されたアプリでは、OU=Apple Certification AuthorityとnotAfter=Feb 1 22:12:15 2027 GMTが出力されます。⁴

1台のMacのソフトウェアから何がわかるか？

インストーラ。 私のダウンロードフォルダには、Developer IDで署名されたパッケージが2社分で4つあり、4つすべてが元の認証局につながっています。そのうち3つは同じベンダーのもので、2025年9月28日、12月14日、12月29日に署名されていました。使われているインストーラ証明書は2022年4月13日発行で、2027年2月1日に期限を迎えます。このベンダーは9か月前の時点でも、元の認証局の配下でパッケージに署名していたことになります。4つ目は2014年2月に、2017年3月29日に期限が切れた証明書で署名されていました。⁴

Gatekeeperのインストール評価spctl -a -t install -vvは、現時点でこの4つすべてを「Notarized Developer ID」として受け入れます。署名証明書の期限が9年前に切れたものも含めてです。この結果は、証明書の概要ページのインストーラ項目にある信頼できるタイムスタンプについての一文とは一致しますが、同じ項目の「new installations won’t be possible」（新規のインストールはできない）という一文や、Developer IDヘルプページとは一致しません。そしてこれこそ、Appleの告知がパッケージについて2月1日に終わると述べている挙動です。10月の時点で2月を試すことはできません。その日に何が起きるかは、私の観察ではなくAppleの言明です。¹⁴⁵

アプリ。 私のアプリケーションフォルダにあるDeveloper ID署名のアプリ66本のうち、49本が元の認証局に、17本がG2につながっています。66本の署名すべてにセキュアタイムスタンプが付いています。Gatekeeperは63本を「Notarized Developer ID」と報告しており、これはAppleが引き続き動作すると述べている組み合わせです。内訳は、元の認証局の配下の49本のうち46本と、G2の配下の17本すべてです。残りの3本はすべて元の認証局の配下にあり、そのうち2本はバンドルの中身に関するエラーである「a sealed resource is missing or invalid」で評価に失敗します。もう1本は2018年7月に署名されたもので、公証なしのDeveloper IDとして受け入れられます。Appleの一文が対象としているのは公証済みのソフトウェアであり、この最後の1本のようなアプリがどうなるのかは、告知には書かれていません。¹⁴

元の認証局の配下の49本のうち6本は、2026年10月1日の時点ですでに期限が切れていた証明書で署名されています。最も早いものは2022年8月、最も遅いものは2026年5月に期限切れになりました。Gatekeeperは6本すべてを受け入れ、そのうち5本は公証済みとして受け入れます。署名時点で証明書が有効であれば十分というAppleのアプリ向けの規則は、私が使っているソフトウェアですでに働いています。⁴⁵

告知のどの一文が一致しないのか？

告知はG2についてこう述べています。「This certificate authority is valid until 2031, but the certificates issued by the certificate authority expire annually and must be renewed each year.」（この認証局は2031年まで有効だが、この認証局が発行する証明書は毎年失効し、毎年更新する必要がある）ヘルプページも同じことを書いています。「Certificates issued from G2 are valid for one year and must be renewed annually.」（G2から発行される証明書の有効期間は1年で、毎年更新する必要がある）¹²

私が調べられるG2の証明書は、1年の証明書ではありません。私のMacにあるG2署名のアプリ17本は12種類の署名証明書を使っており、発行日は2023年2月から2026年5月29日までにわたりますが、どれも有効期間は5年です。そのうち3枚は2026年4月と5月に発行されています。私自身のDeveloper ID Application証明書は2026年5月10日に発行され、2031年5月11日に期限を迎えます。⁴

1年の有効期間がいつ始まったのかは、どちらのページにも書かれていません。また、私は告知以降に証明書を作成していないので、今日発行される証明書がどのような期間で届くのかはわかりません。毎年の更新を前提に計画し、実際に発行された証明書の日付を読みましょう。もし今後1年の証明書が標準になるなら、期限切れのインストーラ証明書をめぐるAppleのページ同士の食い違い、そして概要ページの同じ項目の中での食い違いが、より重要になってきます。信頼できるタイムスタンプについての一文が正しければ、パッケージは証明書より長く使えます。ほかの記述が正しければ、そうはなりません。私の手元にあるデータは、Gatekeeperが今も受け入れている上記の2014年のパッケージだけです。これらの記述をどう比べて重みづけるかは私の解釈であり、Appleの見解ではありません。

私ならどの順番で進めるか？

1. 棚卸し。 両方の種類の証明書についてキーチェーンのチェックを実行し、今もダウンロード提供しているすべてのパッケージに、古いバージョンも含めてpkgutil --check-signatureを実行します。パッケージのチェックはほかのベンダーのインストーラにも使えるので、チームが展開しているインストーラのうち、ベンダーに再署名したビルドを求める必要があるものを見つけられます。
2. 置き換え。 発行者が「Apple Certification Authority」と表示されたら、G2の証明書を作成します。ヘルプページの手順によれば、「Developer ID Certificate Intermediary」（Developer ID証明書の中間認証局）の選択を求められた場合は「G2 Sub-CA (Xcode 11.4.1 or later)」を選びます。理由は「Any other option might issue a certificate from the expiring Certificate Authority」（ほかの選択肢では、失効する認証局から証明書が発行される可能性がある）からで、告知も「Choosing another option may issue a certificate that also expires in 2027.」（別の選択肢を選ぶと、同じく2027年に失効する証明書が発行される可能性がある）と警告しています。両方の種類を持っている場合は、「repeat these steps for each, since one certificate does not cover the other」（一方の証明書はもう一方を兼ねないので、それぞれについてこの手順を繰り返す）必要があります。告知は前提条件も付け加えています。「If you’re using Xcode 11.4 or earlier, update before creating your new certificate.」（Xcode 11.4以前を使っている場合は、新しい証明書を作成する前にアップデートすること）¹²
3. 古い証明書がなくなる前にテストする。 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.」（Developer ID ApplicationとDeveloper ID Installerの証明書はそれぞれ最大5枚まで同時に持てるので、現在の証明書が期限を迎える前に、代わりの証明書を作成してテストできる）²
4. パッケージを再署名する。 productsignのマニュアルには「If you run productsign on a product archive that was previously signed, the existing signature will be replaced」（署名済みのプロダクトアーカイブに対してproductsignを実行すると、既存の署名は置き換えられる）とあり、信頼できるタイムスタンプは「is enabled by default when signing with a Developer ID identity」（Developer IDの署名IDで署名する場合はデフォルトで有効）とされています。さらに、このツールは「any intermediate certificates that are found in the keychain」（キーチェーン内で見つかったすべての中間証明書）を埋め込むので、先にG2の中間証明書をキーチェーンに入れておく必要があるでしょう（マニュアルの--certオプションは中間証明書をコモンネームで指定しますが、2つの認証局は同じ名前を共有しているので、私なら両者のどちらかを選ぶのにこのオプションは頼りません）。Appleの2022年のページによれば、Xcode 13.2以降は中間証明書を自動でダウンロードし、それ以外の場合は「you can download it from the Certificate Authority page」（Certificate Authorityのページからダウンロードできる）とのことです。上記のキーチェーンのパイプラインを「Developer ID Certification Authority」という名前で実行すると、そのMacにある認証局が一覧表示されます。私のMacには両方がありました。そのうえで、結果のファイルを改めて公証し、ステープルします。公証のステップはAppleの文言ではなく私の解釈です。再署名したパッケージは別のファイルだからです。私はDeveloper ID Installer証明書を持っていないので、このステップは実行していません。³⁴
5. 結果を確認する。 再署名したファイルにpkgutil --check-signatureを実行したとき、認証局の下に2027年の日付が表示されなくなっているはずです。また、spctl -a -t install -vvは引き続き「Notarized Developer ID」と表示するはずです。
6. アプリの署名にタイムスタンプを付け続ける。 セキュアタイムスタンプは、引き続き動作するソフトウェアの条件としてAppleが挙げている性質です。今後についてのAppleの指示も「sign with your new certificate and include a secure timestamp for notarization」（新しい証明書で署名し、公証のためにセキュアタイムスタンプを含める）というものです。¹

今回の期限は、この秋2つ目のインストーラ関連の変更です。1つ目はmacOS 27そのものにあり、ホストアーキテクチャを指定していないパッケージのデフォルトがarm64になりました。どのパッケージが影響を受けるかはGolden Gateの記事で取り上げています。どのみちインストーラを再署名するチームなら、両方を一度に確認できます。Mac開発者向けのそのほかの変更はmacOS 27リリースノートの記事にまとめています。ツールチェーン側についてはXcode 27の記事とIntelの記事で、出荷済みのMacアプリがプロンプトなしに読み取り時点で失敗するようになる変更についてはチーム間コンテナの記事で、Macのビルドを止める2つのツールチェーンの変更についてはld64の記事で解説しています。

FAQ

Developer ID Certification Authorityはいつ失効しますか？

2027年2月1日です。元の認証局の証明書は、その日の22:12:15 UTCに期限を迎えます。現行の認証局であるG2は2031年9月に期限を迎えます。Appleのサポートページは9月16日としていますが、証明書そのものには9月17日00:00:00 GMTと記載されています。¹³⁴

私のDeveloper IDアプリは2027年2月1日に起動しなくなりますか？

公証済みで、かつセキュアタイムスタンプ付きで署名されたソフトウェアについて、Appleの答えは「いいえ」です。そうしたソフトウェアは「will keep working」（引き続き動作する）とされ、対応も不要です。署名にタイムスタンプがあればcodesign -dvv YourApp.appがTimestamp=行を出力し、公証済みのアプリならspctl -a -t exec -vv YourApp.appが「source=Notarized Developer ID」と報告します。¹⁴

元の認証局の配下で署名された.pkgインストーラはどうなりますか？

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.」（2027年2月1日以降、影響を受ける証明書で署名された.pkgファイルはインストールできなくなる。この日までに、すべてのパッケージを新しい証明書で再署名すること）¹

パッケージに署名した認証局はどう確認しますか？

パッケージにpkgutil --check-signatureを実行し、チェーン内の「Developer ID Certification Authority」の項目の下にある日付を読みます。Expires: 2027-02-01 22:12:15 +0000なら元の認証局です。⁴

G2の証明書の有効期間は1年ですか、5年ですか？

Appleの告知とヘルプページは、どちらも1年としています。2026年10月1日に私が調べられたG2の証明書は、最も新しい2026年5月29日発行のものを含め、すべて有効期間が5年でした。1年の期間がいつ始まったのかは、どちらのページにも書かれていません。¹²⁴

代わりの証明書はチームの誰が作成できますか？

ヘルプページには「Required role: Account Holder.」（必要な役割：Account Holder）と記載されています。²

出典