Developer ID 만료, Mac 앱과 설치 파일 중 무엇을 다시 서명해야 하나?
Developer ID 인증 기관이 2027년 2월 1일 만료된다. 이미 서명해 둔 앱은 그대로 열릴까, 새 고객이 내려받을 설치 파일은 어떻게 될까?

- 기존 Developer ID 인증 기관의 만료일은 2027년 2월 1일이며, 영향을 받는 .pkg는 새 인증서로 재서명해야 한다.
- 이미 서명·공증했고 보안 타임스탬프가 있는 Mac 앱은 이 만료 때문에 다시 서명할 필요가 없다.
- 자신의 인증서에서 발급자를 확인하고 Application·Installer 인증서를 용도에 맞게 각각 교체해야 한다.
기존 앱이 계속 실행돼도 오래된 설치 파일은 교체해야 한다
Mac App Store 밖에서 프로그램을 배포한다면, 지금 실행 중인 앱과 다운로드 페이지의 .pkg를 나눠 봐야 한다. Apple의 10월 1일 공지는 구형 Developer ID 인증 기관에서 발급한 인증서로 서명된 설치 패키지를 2027년 2월 1일 전에 재서명하라고 안내한다.
| 배포물 | 이번 만료에 따른 조치 |
|---|---|
| 영향받는 인증서로 서명한 .pkg | 2027년 2월 1일부터 설치되지 않으므로 새 인증서로 재서명한다. |
| 이미 서명·공증했고 보안 타임스탬프가 있는 Mac 앱 | 계속 작동한다. 이번 만료 때문에 다시 서명할 필요는 없다. |
| 향후 앱 업데이트와 새 배포 | 새 인증서로 서명하고 공증에 필요한 보안 타임스탬프를 포함한다. |
이는 앱 안의 다른 유효기간까지 없애는 조치가 아니다. Developer ID 프로비저닝 프로파일을 쓰는 앱은 프로파일이 만료되면 실행되지 않는다. 인증서가 취소된 경우도 단순 만료와 다르게 취급된다.
인증서 이름과 만료일만으로 G2를 구분하지 않는다
교체 대상은 키체인에 있는 자신의 Developer ID 인증서에서 확인한다. Apple의 교체 도움말은 같은 이름으로 구형 기관과 G2에서 각각 발급받은 인증서를 함께 보유할 수 있다고 설명한다.
Keychain Access에서 해당 인증서를 선택하고 Issuer Name의 Organizational Unit을 펼친다. Apple Certification Authority면 이전 기관의 인증서이므로 교체 대상이다. G2면 현재 기관에서 발급한 것으로, 이번 구형 기관 만료에 따른 교체는 필요하지 않다.
여기서 Developer ID Certification Authority라는 인증 기관 항목 자체를 고르면 안 된다. 그 항목의 발급자는 루트 기관이며, 같은 문구가 나타나 혼동할 수 있다. 개발자가 실제 서명에 사용하는 인증서를 선택해야 한다.
Apple PKI 목록에서 G2 기관은 2031년까지 유효하다. 그러나 Apple은 G2에서 발급하는 개발자 인증서를 매년 갱신해야 한다고 명시한다. 기관의 수명을 자신의 서명 인증서 만료일로 읽어서는 안 된다.
앱용 인증서 하나로 설치 패키지까지 서명할 수는 없다
Developer ID Application은 앱을, Developer ID Installer는 설치 패키지를 위한 인증서다. 생성 도움말에서도 두 종류를 구분한다. 둘 다 사용하는 배포 과정이라면 각 종류의 교체가 필요하다.
이 절차로 인증서를 교체하려면 Account Holder 권한이 필요하다. 계정의 Certificates, Identifiers & Profiles → Certificates → +에서 필요한 종류를 선택하고, 중간 인증 기관을 고르라는 화면이 나오면 G2 Sub-CA를 선택한다. 인증서 서명 요청을 제출하고 새 인증서를 설치한 뒤, 빌드 시스템이 새 인증서를 쓰도록 갱신한다.
개발용 Mac에서 인증서를 받았다고 배포 서버 설정까지 바뀌지는 않는다. Apple의 패키징 문서는 서명에 쓸 Installer identity가 실제로 존재하는지 확인하도록 안내한다. identity를 조회할 때 -p codesigning으로 필터링하면 Installer identity가 제외되므로, 앱 서명 목록에 없다는 이유만으로 설치용 인증서가 없다고 판단하면 안 된다.
인증서 발급 완료가 아니라 새 설치 파일 배포가 마감이다
교체 작업은 사용자가 내려받는 파일까지 바뀌어야 끝난다. 배포 중인 pkg 가운데 이번 만료의 영향을 받는 파일을 새 Installer 인증서로 다시 서명하고, 앱을 새로 빌드하는 경우에는 그 안의 코드 서명도 맞춘다. 패키징 문서는 안쪽 코드와 컨테이너부터 차례로 서명하도록 안내한다.
그다음에는 실제 배포할 컨테이너를 공증하고 검사 결과를 확인한다. 공증 서비스는 악성 구성 요소와 코드 서명 문제를 검사하고 ticket을 발급한다. Apple은 공증이 성공한 뒤에도 로그의 경고를 읽고 소프트웨어를 테스트하라고 안내한다.
설치 파일 교체 후에는 다운로드 경로가 새 파일을 제공하는지 확인한다. 이미 설치된 앱이 잘 열린다는 사실만으로 새 고객의 설치까지 안전하다고 볼 수는 없다. 이번 작업의 우선순위는 기존 앱을 전부 다시 만드는 것이 아니라, 영향을 받는 설치 패키지를 찾아 기한 전에 교체하고 다음 인증서 갱신 일정을 관리하는 것이다.