애플 푸시 알림 서비스 인증서는 1년 동안 유효하며 매년 Apple Developer Portal에서 갱신해야 하며, 만료 또는 취소된 자격증이 있으면 알림이 중단됩니다. 만약 Capacitor 앱의 책임이 있으면 만료 또는 취소된 자격증이 있으면 알림이 중단됩니다.
알림이 중단되는 경우는 항상 최악의 시점에 발생합니다. 릴리스가 출시되고 캠페인이 계획되어 있으면 알림 전송이 갑자기 멈추게 됩니다. 애플리케이션 서버는 여전히 작업을 수락하지만 APNs는 TLS 연결을 거부할 수 있습니다. 실제 해결책은 단순히 인증서를 생성하는 것이 아닙니다. 시스템에서 사용하는 APNs 자격증을 이해하고 개인 키를 보존하고 갱신을 계획하고 토큰 기반 인증으로 적절한 워크로드를 이동해야 합니다.
내용목록
- 푸시 알림이 작동하지 않는 이유
- APNs 인증서 만들기
- 인증서를 개인 키로 내보내기
- 토큰 기반 인증으로 마이그레이션
- 라이선스 기간 재발급 및 관리
- 문제 해결 및 잃어버린 자격 증명 처리
푸시 알림이 작동하지 않는 이유
APNs는 제공자 서버와 사용자의 애플 기기 사이에 위치합니다. 서버는 애플에 인증하고 알림을 제출하고 APNs에 알림을 등록된 애플리케이션과 기기에 전달하도록頼みます. 자격 증명이 만료되거나 취소되거나 잘못된 식별자와 관련된 경우 또는 올바르게 설치되지 않은 경우 요청은 전달 시작 전에 실패할 수 있습니다.
애플은 APNs가 취소된 자격 증명 목록을 유지하고 서버가 그 목록에 있는 자격 증명으로 인증하는 서버에 TLS 연결을 거부한다고 말합니다. 따라서 자격 증명 관리는 전달 요구 사항이 아닌 관리 선호도입니다. 서버는 알림 작업을 지역적으로 계속 처리할 수 있지만 애플은 제공자 연결을 거부할 수 있습니다.
앱 푸시와 MDM 푸시를 분리
첫 번째 진단 질문은 간단합니다: 어떤 서비스를 운영하려고 하는지?
| 자격 증명 경로 | 무엇을 하는가 | 일반적인 소유자 |
|---|---|---|
| 애플 푸시 | 사용자 기기에서 알림 및 다른 애플리케이션 알림을 전송합니다. | 모바일 또는 백엔드 엔지니어링 |
| MDM 푸시 | 관리되는 애플 기기와 통신할 수 있도록 장치 관리 플랫폼에게 허용합니다. | IT, 엔드포인트 또는 기업 모빌리티 관리 |
이 인증서는 교환할 수 없습니다. MDM 플랫폼이 등록된 장치와의 연락을 잃을 수 있습니다. 만약 MDM 푸시 인증서가 만료되면, 애플리케이션 백엔드가 알림 전달을 잃을 수 있습니다. 만약 앱 푸시 인증서가 유효하지 않다면.
For Capacitor and Ionic teams, the relevant path for user-facing alerts is generally 애플 푸시앱은 여전히 Push Notifications 기능, 올바른 서명, 장치 등록 및 APNs 환경을 통해 알림을 전송하는 백엔드가 필요합니다. 만약 팀이 오버-더-에어 웹 자산을 배포하는 경우, 푸시 인증을 위한 릴리즈 워크플로우와 분리하여 유지하세요. Capacitor 알림 플러그인 문서 애플리케이션 측 통합은 APNs 자격 증명은 제공자 구성에 속합니다.
첫 번째 UI가 아닌 거부 시작
APNs 응답을 확인하기 전에 알림 복사본을 변경하거나 앱을 재빌드하기 전에 제공자 서버에서 APNs 응답을 확인하세요. 그런 다음 버전, 자격 증명, 환경, 인증서 상태를 확인하세요. 알림 허용 문제는 사용자가 알림을 볼 수 없게 하지만 APNs TLS 거부는 설명하지 않습니다.
릴리스 후에 실패가 나타났다면, 새로운 빌드의 서명 및 권한과 이전 빌드의 서명 및 권한을 비교하세요. 앱 변경 없이 나타났다면, 인증서 만료, 취소, 신뢰 저장소 변경, 배포 비밀을 먼저 검사하세요. 더 광범위한 구현 경로를 보려면 이 가이드를 참조하세요. Expo 푸시 알림 설정.
APNs 인증서 만들기 및 다운로드
인증서가 잘못된 앱 ID에 발급된 경우 또는 개인 키가 다른 맥에 남아 있는 경우 첫 번째 알림이 전송되기 전에 푸시 론칭이 실패할 수 있습니다. 애플의 워크플로우는 두 가지 부분으로 구성됩니다: 머신은 선택한 앱 ID에 대한 CSR을 생성하고, 애플은 CSR을 서명합니다. 앱 ID 준비애플 개발자 포털에 로그인하고
인증서 서명 요청
(CSR) 또는 CSR, 애플이 선택한 앱 ID에 대한 CSR을 서명합니다. CSR은 서버 자격 증명이 아닙니다. CSR은 발급된 인증서를 개인 키와 연결합니다. 인증서, 식별자 및 프로필. 선택 식별자, 앱의 번들 식별자 선택하고 구성 파일을 열어보세요. 푸시 알림 이용하기 전에 푸시 알림이 활성화되어 있는지 확인하세요.
APNs 인증서는 애플리케이션의 고유성을 기반으로 생성됩니다. 유사한 이름의 근처의 번들 식별자를 선택하지 마세요. 각 별도의 애플리케이션을 독립적으로 구성하고 일치하는 인증서를 발급하세요.
키를 보관할 맥을 열고 Keychain Access 을 열어 CSR을 생성하거나 조직의 승인된 인증서 도구를 사용하세요. 요청 파일과 개인 키는 동일한 통제된 소유권하에 유지하세요. 다른 관리자가 CSR을 생성하면 나중에 사용 가능한 서버 번들을 위해 필요한 개인 키를 보유할 수 있습니다.
발급된 인증서
In 인증서Apple Push Notification 서비스 인증서 옵션을 선택하세요. App ID를 선택하고 CSR을 업로드하고 요청을 제출하세요. Apple이 발급한 인증서를 다운로드하세요.
다운로드한 파일을 Mac에서 열어보세요. private key가 있는 곳에 설치되어야 합니다. Keychain Access에서 인증서와 매칭되는 private key를 확인할 수 있습니다. private key가 없는 인증서를 임포트하면 백엔드가 필요한 전체 자격 증명 제공을 할 수 없습니다. 인증서 이름을 지정할 때 애플리케이션 식별자, 환경, 소유자, 만료 날짜를 기록하세요. 원본 인증서, CSR 소유 정보, 포털 계정 정보를 팀의 자격 증명 시스템에 저장하세요. 개발자의 다운로드 폴더나 개인 노트북은 운영 환경 백업이 아닙니다.인증서는 전달의 한 부분만 지원합니다. 앱은 remote notifications에 등록해야 하며 서버는 결과 디바이스 토큰을 보관해야 하며 제공자는 매칭된 토픽과 환경과 함께 보낼 수 있어야 합니다. 이러한 의존성을 동일한 runbook에 유지하세요. 클라이언트 측 설정에 대한 자세한 내용은
__CAPGO_KEEP_0__
通知 통합 가이드 Capacitor notifications integration guide인증서를 개인 키로 내보내기
Keychain Access
다운로드 한 애플 인증서가 자동으로 Node.js 서비스나 관리형 푸시 제공자에 사용할 준비가 된 것은 아닙니다. 서버는 인증서와 해당하는 개인 키가 포함된 파일을 필요로 합니다. 이 파일은 일반적으로 PKCS#12 형식으로 패키징됩니다. PKCS#12 .p12 파일.
열기 Keychain Access Mac에서 인증서를 설치한 기기에서 Keychain Access를 열고, APNs 인증서를 검색하고 확장하거나 검사한 후, 일치하는 식별 정보와 유효 기간 정보를 가진 개인 키를 찾습니다. 인증서와 개인 키를 함께 선택한 후, 내보내기 작업을 사용하여 완전한 제공자 인증서로 저장할 수 있는 파일을 만듭니다. .p12 배포 전에 번들을 검증하세요
내보내기 작업에 강력한 암호를 제공하세요. 암호는 개인 키를 포함하는 번들을 보호하기 때문에, 저장소, 티켓, 채팅 메시지, 빌드 로그에 포함하지 마세요. 파일과 암호를 비밀 관리 시스템에 업로드한 후, 알림을 보내는 서비스에만 접근 권한을 부여하세요.
실용적인 규칙:
개인 키와 일치하지 않는 파일은 완전한 제공자 인증서가 아닙니다. A file without its matching private key is not a complete provider credential.
.p12Validate the bundle before deployment
제품 사용 전에, 제어 환경에서 패키지를 테스트하세요. 백엔드가 파일을 로드할 수 있고, APNs 연결을establish하고, Apple이 요청을 거부할 때 구조화된 오류를 반환할 수 있는지 확인하세요. 제공자 Capgo가 iOS 푸시 인증서를 요청한다면, 애플리케이션 Capgo에 임베디드하지 않고, 지정된 비밀 구성에서 키와 패스워드를 업로드하세요. .p12 and its password through the designated secret configuration rather than embedding either value in application code.
CI/CD pipeline에서
보안 비밀 관리를 사용하여谁이 읽거나 패키지를 대체할 수 있는지 제어하세요. 업로드 및 회전에 대한 감사 기록을 유지하세요, 그러나 개인 키나 패스워드를 로그하지 마세요. 새로운 백엔드 작업을 평가할 때, 인증서 인증이 여전히 적합한지 확인하세요. 기존 통합은 하지만 토큰 인증은 제공자 연결에서 연간 인증서 갱신을 제거합니다. 그럼에도 불구하고, 자격 증명 관리는 변경되지 않습니다. 보호하고 회전해야 하는 것은 달라집니다. .p12 APNs 인증을 New Token-Based Authentication로 마이그레이션하는 방법
Apple은 APNs 인증을 .p12제공자 토큰
provider tokens
provider tokens provider tokens, 일반적으로 APNs 인증 키라고 불리는 p8 워크플로우. 오랜 기간 동안 TLS 식별성을 위한 인증서와 개인 키를 제공하는 대신, 제공자는 APNs 인증 키로 인증 토큰을 서명합니다.
Apple Developer Portal에서 Certificates, Identifiers & Profiles에서 키를 생성하세요. 그런 다음 Keys 를 열고 APNs 인증 키를 등록하세요. 다운로드한 파일을 다운로드한 파일을 고가의 서명 비밀로 취급하세요. .p8 이전 환경에서 파일을 교체하지 않고 테스트되지 않은 환경에서 프로덕션 트래픽을 교체하지 마십시오. 기존 인증서 경로에 토큰 인증을 함께 구축하고 샌드박스 및 프로덕션 동작을 검증한 후 APNs 응답을 비교한 후 제공자 구성 변경을 제어된 배포 중에 수행하십시오.
이전 방법에서 인증서 갱신 및 키체인 내보내기 단계를 제거하지만, 팀은 키의 소유권 모델에 명확한 소유권 모델이 필요합니다. 키를 생성, 취소, 배포할 수 있는 사람을 결정하고, 키를 서명하는 백엔드 서비스에 대한 접근을 제한하고, 현재 키가 사용할 수 없게 되기 전에緊急 대체 프로세스가 존재하는지 확인하십시오.
Don’t switch production traffic by replacing a file in an untested environment. Build token authentication beside the existing certificate path, validate sandbox and production behavior, and compare APNs responses. Then make the provider configuration change during a controlled deployment.
The migration removes the certificate renewal and Keychain export steps from the sending path, but your team still needs a clear ownership model. Decide who can create, revoke, and deploy keys. Limit access to the backend service that signs provider tokens, and make sure an emergency replacement process exists before the current key becomes unavailable.
Capacitor 앱의 경우, 클라이언트는 여전히 정확한 알림 등록 및 권한이 필요합니다. 이 마이그레이션은 주로 서버에서 APNs 인증에 대한 변경을 의미합니다. 서버에서 APNs 인증에 대한 변경code 토큰 등록이 아닌, 디바이스 토큰 등록이 변경되지 않습니다. 백엔드는 여전히 토큰을 올바른 애플리케이션 및 환경과 연관시켜야 합니다.
인증서가 남아 있는 경우 알림 받을 때 알림
일부 기업 도구 및established 통합은 여전히 인증서 기반 구성이 노출됩니다. p8 마이그레이션을 강제하지 마십시오. 받는 시스템이 이를 지원하고 팀이 완전한 경로를 테스트할 때까지 기다려야 합니다. 전환 중에 레거시 자격 증명을 보호하지만, 토큰 인증이 적합할 때 새로운 의존성을 만들지 마십시오.
애플 푸시 알림 서비스 인증서가 필요한 경우 이해하기 Ionic과 Capacitor 푸시 알림을 Firebase와 함께 이해하기. Firebase는 애플리케이션 배포層을 제공할 수 있지만, Apple 자격 증명, 권한, 등록, APNs 응답은 의도적인 구성이 필요합니다.
인증서의 유효 기간을 관리하는 방법
APNs 인증서를 생성한 날부터 유효한 프로덕션 의존성으로 다루세요. Apple은 이러한 인증서가 생성 후 1년 동안 유효하다고 말합니다. __CAPGO_KEEP_0__ 그리고 만료 전에 갱신해야 하므로 장치 통신을 보존합니다. Apple은 갱신을 실패하면 APNs와 iOS, iPadOS, Mac 장치에 다시 등록해야 하는 사용자에게 서비스 중단을 유발할 수 있다고 경고합니다. Apple의 push 알림 인증서 갱신 문서를 참조하십시오..
갱신 경로는 다음과 같습니다:
- 새로운 CSR를 생성하십시오: 승인된 워크플로우를 통해 요청을 생성하고 관련 키 자료를 보존하십시오.
- 원래 Apple ID를 사용하십시오: 기존 인증서를 생성한 동일한 Apple ID로 로그인하십시오.
- 갱신되는 인증서를 선택하십시오: App ID, Subject DN, UID, 만료 일자와 일치시킨 후 갱신.
- CSR 업로드: Apple Push Certificates Portal에서 새로운 요청을 제출하십시오.
- 다운로드 및 재설치: 갱신된 인증서를 획득하세요.
.pem, 개인 키가 있는 곳에 설치하고 대체 인증서를 내보내세요..p12제공 업체가 요구하는 경우. - 배포 및 테스트: 서버 비밀을 업데이트하고 제어된 알림을 보내고 APNs 응답을 검사하세요.
제공 업체 형식 비교:
| 요구 사항 | 인증서 워크플로우 | 토큰 워크플로우 |
|---|---|---|
| 기본 비밀 | 인증서와 개인 키 | .p8 인증 키 |
| 갱신 문제 | 인증서 만료는 반복적인 교체가 필요합니다. | 연간 인증서 교체가 없습니다. |
| 배포 작업 | 설치, pair, 내보내기, 업로드 | 스토어 서명 키와 토큰 생성을 구성 |
| 주요 실패 위험 | wrong 인증서, 미공개 키 누락, 만료, 또는 취소 | 인증 키가 사라졌거나 노출되거나 취소되었습니다. |
애플의 인증서 생태계도 정기적인 신뢰 체인 작업이 필요했습니다. 애플은 샌드박스 APNs 서버 인증서 업데이트를 2025년 1월 20일 발표했습니다. 2025년 1월 20일 and production on 2025년 2월 24일, trust stores에 포함해야 하는 SHA-2 Root USERTrust RSA Certification Authority 을 읽으십시오. Apple APNs 서버-인증서 발표 및 플랫폼 체크리스트에 소유권을 포함하세요.
공유된 갱신 일정, 이름이 지정된 소유자, 배포 실행 책임을 사용하세요. Capgo 인증서 관리 문서 iOS 배포 인증서 관리와 모바일 릴리스 프로세스와 함께 팀이 관리할 수 있습니다.
문제 해결 및 잃어버린 인증서 처리
어렵게 된 사고는 항상 만료 경고만이 아닙니다. 관리자가 생성한 인증서가 떠난 아침, 개인 키가 오래된 맥에만 존재하거나 인증서가 취소된 시도가 있었을 때입니다. 표준 갱신 흐름은 원래 Apple ID와 인증서의 올바른 식별성을 의존하기 때문에 접근과 증명력이 파일 자체만큼 중요합니다.
Start by classifying the failure:
- 만료된 인증서: 원래 계정에서 새로운 인증서를 생성하고 매칭되는 개인 키와 함께 재설치한 후 제공자 업데이트 및 테스트 전송을 진행합니다. 기기 통신이 이미 중단된 경우, 서버 측에서 즉시 모든 기기를 복원하는 대신 Apple의 복구 지침을 따르세요.
- 철회된 인증서: 기존 인증서를 복구 가능한 것으로 간주하지 마십시오. Apple은 철회된 인증서를 사용하는 서버에서 TLS 연결을 거부하므로 유효한 대체 인증서를 생성하고 활성 배포에서 철회된 비밀을 제거하세요. 인증서를 철회한 사람을 확인하고 다른 시스템이 동일한 인증서를 복사했는지 확인하세요.
- 잃어버린
.p12비밀번호: 사용 가능한 비밀번호가 없는 인증서 파일은 운영적으로 사용할 수 없습니다. 승인된 백업을 검색하거나 생산 비밀 제어를 약화시키지 않고 대체 인증서를 발급하세요. - 잃어버린 개인 키: 공개 인증서를 다시 다운로드하는 것은 개인 키를 재생성하지 않습니다. 제어된 기기에서 새로운 CSR를 생성하고 대체 인증서를 발급하세요.
- Apple ID 접근권한을 잃어버렸다: 조직이 계정을 복원할 수 있는지 확인하고 계정과 배포 프로세스를 통해 확인하세요. Apple은 관련 포털을 통해 생성된 APNs 인증서에 대한 지원을 지시합니다. 배포 프로그램 지원.
재구축은 단순한 파일 이름만으로는 불가능합니다. 애플 ID 소유자, 앱 ID, 인증서 ID, 개인 키 위치, 제공자 구성, 및 대체 절차를 사전에 재구축이 발생하기 전에 기록하세요.
운영 안전망을 구축하세요
인증서 및 .p8 키를 공유된 접근 제어된 보관소에 넣으세요. 파일과 비밀번호를 분리하고, 프로덕션에 대한 접근을 제한하고, 정확한 포털 계정을 사용하여 갱신을 문서화하세요. CI/CD 시스템은 배포 시 시크릿을 주입하고, 인증 실패를 감지하는 헬스 체크를 실행하여 사용자가 누락된 알림을 보고하기 전에 사용하세요. .p12 __CAPGO_KEEP_0__는 iOS 푸시 인증서를 __CAPGO_KEEP_1__ 알림 워크플로우의 일부로 저장하고 구성할 수 있지만, 팀은 애플 계정 접근, 시크릿 보관, 및 갱신 결정의 책임을 유지합니다.
__CAPGO_KEEP_0__
__CAPGO_KEEP_0__
Capgo can store and configure iOS push credentials as part of a Capacitor notification workflow, while your team retains responsibility for Apple account access, secret custody, and renewal decisions. Visit Capgo APNs 인증서 라이프사이클과 릴리스 프로세스와 함께 모바일 전달 도구를 검토하는 방법을 알아보세요.
