Developer IDの旧中間証明書が2027年2月1日に期限切れ｜Macアプリと.pkgの署名の認証局を見分けてG2へ切り替える手順

2026年10月24日

Apple、Developer IDの旧中間認証局の有効期限が2027年2月1日に切れると告知

Appleは2026年10月1日、Macアプリを配布するときの署名に使う「Developer ID」証明書について、古い中間認証局（Sub-CA）の有効期限が2027年2月1日に切れると開発者向けに告知しました。この認証局から発行された証明書も、同じ日から使えなくなります。

Developer IDは、Mac App Storeの外（自社サイトやGitHubなど）でMacアプリや.pkgのインストーラを配る開発者が使う証明書です。Appleの認証局（CA、証明書を発行する組織）が証明書を発行し、ユーザーのMacはその署名を見て、アプリやインストーラを開いてよいかを判断します。アプリを配る前には、Appleにマルウェアの検査を受けて記録してもらう「公証」（ノータリゼーション）を通すのが一般的です。

Developer IDの中間認証局には、元からある認証局（以下「旧認証局」）と、新しい「Developer ID Certification Authority (G2)」（以下「G2」）の2つがあり、今回期限を迎えるのは旧認証局です。この記事では、手元のMac（macOS 27.0.1）でアプリと証明書を調べ、旧認証局とG2をどう見分けるかを確かめました。.pkgとMacアプリでそれぞれ何が起きるか、自分の証明書が対象かどうかの確認、G2の証明書への切り替えまでを順に説明します。

4つの要点

2027年2月1日までに、旧認証局の証明書で署名した.pkgを、G2の証明書で署名し直す

期限

2027年2月1日

旧認証局と、そこから発行された証明書の有効期限が切れる。

.pkgのインストーラ

署名し直しが必要

旧認証局の証明書で署名した.pkgは、2月1日からインストールできなくなる。

公証済みのMacアプリ

配布済みの版はそのまま

署名時刻の記録（タイムスタンプ）付きなら動き続ける。次の更新からG2の証明書で署名する。

見分け方

発行元の「OU」を見る

旧認証局は「Apple Certification Authority」、G2は「G2」。codesignの通常の表示では同じ名前に見える。

影響を受けるのは.pkgと、これから出すアプリの更新

Appleの告知では、配布物の種類によって必要な対応が分かれます。いちばん急ぐのは.pkgのインストーラです。

アプリと.pkgで扱いが違うのは、Macが証明書を確かめるタイミングが違うためです。AppleのDeveloper IDの説明によると、アプリは署名した時点で証明書が有効なら、証明書の期限が過ぎたあともダウンロードして使えます。.pkgは実行するときに証明書が有効かを確かめるので、期限が切れた証明書で署名した.pkgは開けません。

手元のMacで、証明書の期限がすでに過ぎたアプリを調べてみました。図の作成ツール「draw.io」は日本時間の2025年5月10日に旧認証局の証明書で署名され、その証明書の期限は2025年11月18日でした。それでも、Gatekeeper（Macがアプリを開く前に署名を確かめる仕組み）の判定は「accepted」で、公証済みのDeveloper IDアプリとして通っています。

$ spctl -a -vv -t exec /Applications/draw.io.app
/Applications/draw.io.app: accepted
source=Notarized Developer ID
origin=Developer ID Application: JGraph Ltd (UZEUFB4N53)

この結果で確かめられるのは、アプリに署名した証明書の期限が切れても、タイムスタンプ付きの公証済みアプリが開ける点です。旧認証局そのものの期限が切れる2027年2月1日以降の扱いは、公証済みでタイムスタンプ付きのアプリはそのまま動くというAppleの告知の説明が根拠になります。

codesignの通常の表示では、旧認証局とG2が同じ名前に見える

アプリの署名は codesign -dvvv で確かめるのが一般的です。ところが、旧認証局で署名されたGoogle Chromeと、G2で署名されたFigmaを並べると、認証局の行はどちらも「Developer ID Certification Authority」と表示されました。

$ codesign -dvvv "/Applications/Google Chrome.app" 2>&1 | grep Authority
Authority=Developer ID Application: Google LLC (EQHXZ8M8AV)
Authority=Developer ID Certification Authority
Authority=Apple Root CA

$ codesign -dvvv /Applications/Figma.app 2>&1 | grep Authority
Authority=Developer ID Application: Figma, Inc. (T8RA8NE3B7)
Authority=Developer ID Certification Authority
Authority=Apple Root CA

2つの認証局は名前（CN）が同じで、違いは「OU」（組織単位）という欄にあります。Appleの切り替えの手順書も、アプリに署名した証明書の期限だけでは発行元を判定できないので、発行元を確かめるよう書いています。

2026年10月23日に、macOS 27.0.1の /Applications にあるアプリを調べた結果です。旧認証局の欄のアプリはいずれも公証済みで、Appleの説明では配布済みの版はそのまま動きます。配布元が新しい証明書で署名した版を出せば、結果は変わります。

見分けるときの手がかりは2つあります。1つは発行元のOUで、もう1つは中間証明書の期限です。アプリに署名した証明書の期限は、draw.ioのように2027年2月1日より前に切れているものもあるので、それだけでは判定できません。中間証明書の期限は旧認証局が2027年2月1日、G2が2031年9月17日と決まっているので、判定に使えます。

アプリと.pkgの署名がどちらの認証局かを確かめる手順

ここからは、配布しているアプリや.pkgが旧認証局の証明書で署名されているかを確かめる手順です。どれもmacOSに入っているコマンドだけで動きます。

アプリの署名から証明書を取り出して発行元を見る

作業用のフォルダで codesign -d --extract-certificates を実行すると、署名に含まれる証明書が codesign0（アプリに署名した証明書）、codesign1（中間証明書）、codesign2（ルート証明書）として保存されます。codesign0 の発行元（issuer）と期限、codesign1 の期限を表示します。

mkdir -p ~/devid-check && cd ~/devid-check
codesign -d --extract-certificates "/Applications/Google Chrome.app"
openssl x509 -inform DER -in codesign0 -noout -issuer -enddate
openssl x509 -inform DER -in codesign1 -noout -enddate

実行すると、最初に Executable= の行が出たあと、発行元と期限が表示されます。Google ChromeとFigmaでは次のように分かれました（← の注記は説明のために足したものです）。

# Google Chrome（旧認証局）
issuer=CN=Developer ID Certification Authority, OU=Apple Certification Authority, O=Apple Inc., C=US
notAfter=Feb  1 22:12:15 2027 GMT    ← codesign0（アプリに署名した証明書）
notAfter=Feb  1 22:12:15 2027 GMT    ← codesign1（中間証明書）

# Figma（G2）
issuer=CN=Developer ID Certification Authority, OU=G2, O=Apple Inc., C=US
notAfter=Apr 10 17:15:34 2031 GMT    ← codesign0
notAfter=Sep 17 00:00:00 2031 GMT    ← codesign1

issuerの行に OU=Apple Certification Authority があれば旧認証局、OU=G2 があればG2です。確認が終わったら、作業用のフォルダ ~/devid-check は削除してかまいません。

/Applications のアプリをまとめて調べる

同じ処理をくり返すと、/Applications にあるアプリを一度に分類できます。Developer ID以外（App Storeのアプリなど）で署名されたアプリは表示しません。macOS標準のzshとbashの両方で、同じ結果になることを確かめています。

for app in /Applications/*.app; do
  tmp=$(mktemp -d)
  (cd "$tmp" && codesign -d --extract-certificates "$app" 2>/dev/null)
  if [ -f "$tmp/codesign0" ]; then
    issuer=$(openssl x509 -inform DER -in "$tmp/codesign0" -noout -issuer)
    case "$issuer" in
      *"Developer ID Certification Authority, OU=G2"*) echo "G2   $(basename "$app")" ;;
      *"Developer ID Certification Authority, OU=Apple Certification Authority"*) echo "旧CA $(basename "$app")" ;;
    esac
  fi
  rm -rf "$tmp"
done

自分が配布しているアプリを調べるときは、/Applications の代わりに、ビルドしたアプリのパスを指定します。

.pkgは pkgutil で証明書ごとの期限を見る

.pkgの署名は pkgutil --check-signature で確かめます。

pkgutil --check-signature 配布する.pkg

署名に含まれる証明書が上から順に並び、それぞれの「Expires」（期限）が表示されます。手元にあったAppleのソフトウェア更新の.pkgでは、次の形式でした。

   Certificate Chain:
    1. Software Update
       Expires: 2029-04-14 21:28:23 +0000
       ...
    2. Apple Software Update Certification Authority
       Expires: 2031-10-15 00:00:00 +0000
       ...
    3. Apple Root CA
       Expires: 2035-02-09 21:40:36 +0000

Developer IDで署名した.pkgでは、2番目に中間証明書の「Developer ID Certification Authority」が並びます。その期限が2027-02-01なら旧認証局、2031-09-17ならG2です。旧認証局とG2の中間証明書の期限は、前の手順でアプリから取り出した codesign1 で確かめた値です。

自分のDeveloper ID証明書が対象かを確かめる

配布物を調べたら、次は署名に使っている自分の証明書です。Appleの手順書は、Certificates, Identifiers & Profiles（Apple Developerサイトの証明書の管理画面）で、Developer ID ApplicationとDeveloper ID Installerの証明書のうち、期限が2027年2月1日以前のものを影響の可能性が高いとしています。確実に見分けるには、発行元のOUを確かめます。

手順書が挙げる方法は、キーチェーンアクセスで自分の証明書を選び、「発行者名」を開いて「部署」（OU）の欄を見るものです。キーチェーンに入っている「Developer ID Certification Authority」という中間証明書の項目を見ても判定できないので、自分の名前が入った証明書のほうを選びます。

ターミナルでまとめて確かめるなら、次のコマンドで、キーチェーンにあるDeveloper ID ApplicationとDeveloper ID Installerの証明書を1枚ずつ表示できます。出力には証明書の種類、発行元のOU、期限だけを出し、名前は表示しません。

tmp=$(mktemp -d)
security find-certificate -a -c "Developer ID" -p > "$tmp/all.pem"
touch "$tmp/cert0.pem"
awk -v d="$tmp" '/BEGIN CERT/{n++} {print > (d "/cert" n ".pem")}' "$tmp/all.pem"
for f in "$tmp"/cert*.pem; do
  [ -s "$f" ] || continue
  name=$(openssl x509 -in "$f" -noout -subject -nameopt multiline | awk -F'= ' '/commonName/{print $2}')
  case "$name" in "Developer ID Application:"*|"Developer ID Installer:"*) ;; *) continue ;; esac
  ou=$(openssl x509 -in "$f" -noout -issuer -nameopt multiline | awk -F'= ' '/organizationalUnitName/{print $2}')
  end=$(openssl x509 -in "$f" -noout -enddate | cut -d= -f2)
  echo "${name%%:*} / 発行元OU: $ou / 期限: $end"
done
rm -rf "$tmp"

筆者のMacでは、キーチェーンアクセスで同じ名前に見えるDeveloper ID Application証明書が3枚あり、このコマンドで調べると、そのうち1枚が旧認証局のものでした。

Developer ID Application / 発行元OU: G2 / 期限: Feb 17 16:34:17 2028 GMT
Developer ID Application / 発行元OU: Apple Certification Authority / 期限: Feb  1 22:12:15 2027 GMT
Developer ID Application / 発行元OU: G2 / 期限: Nov 18 16:05:52 2027 GMT

Appleの手順書にあるとおり、1つのチームが両方の認証局の証明書を同じ名前で持つことがあります。キーチェーンアクセスの一覧では名前だけで区別できないので、署名に使う証明書を選ぶときは発行元のOUと期限まで確かめ、署名後には前の節の手順で配布物の発行元を確かめます。

G2の証明書を作って署名を切り替える

旧認証局の証明書を使っていた場合は、G2から新しい証明書を作ります。手順書によると、作成できるのはApple Developer Programのチームの「Account Holder」（チームの代表者）です。

Developer ID ApplicationとDeveloper ID Installerは、それぞれ最大5枚まで同時に持てます。そのため、いまの証明書を使い続けながら新しい証明書を作り、署名と公証、インストールまでを試してから切り替えられます。

Appleの手順書は、これからG2で作る証明書の有効期間を1年とし、毎年の更新を求めています。手元で見た既存のG2の証明書には2028〜2031年まで有効なものもありましたが、新しく作った証明書は1年で期限が来る前提で、キーチェーンを調べるコマンドで期限を確かめ、次の更新日を予定に入れておきます。

2027年2月1日までに確かめる3つのこと

Macアプリや.pkgを配布している人が、期限までに確かめることを3つにまとめます。

.pkgで配っているツールは、期限を過ぎるとユーザーの手元でインストールが止まります。締め切りは2027年2月1日です（証明書に記録された期限は日本時間の2月2日午前7時12分）。.pkgを差し替えたあとに、ダウンロードページや自動更新の配信先が新しいファイルを指しているかも確かめておくと、取りこぼしを防げます。