애플 푸시 알림 서비스 인증서는 1년 동안 유효하며 매년 Apple Developer Portal에서 갱신해야 하며 장치와의 통신을 중단하는 것을 피하기 위해. 만약 Capacitor 앱의 책임이 있는 경우 만료되거나 취소된 자격증은 알림이 중단되더라도 앱 자체가 건강해 보이더라도 알림 전송이 중단됩니다.
실패는 항상 최악의 시기에 발생합니다. 릴리스가 출시되며 캠페인이 예약되어 알림 전송이 갑자기 침묵합니다. 애플리케이션 서버는 여전히 작업을 수락하지만 APNs는 TLS 연결을 거부하기 전에 메시지가 장치에 도달하기 전에 메시지를 거부합니다. 실제 해결책은 단순히 다른 인증서를 생성하는 것이 아닙니다. 시스템에서 사용하는 APNs 자격증을 이해하고, 개인 키를 보존하고, 갱신을 계획하고, 토큰 기반 인증으로 적합한 워크로드를 이동해야 합니다.
내용목록
- 푸시 알림이 작동하지 않는 이유
- APNs 인증서 만들기 및 다운로드
- 인증서를 개인 키로 내보내기
- 토큰 기반 인증으로 마이그레이션
- 라이선스와 인증서 수명 주기 관리
- 인증서 정보가 손실된 경우 문제 해결
푸시 알림이 작동하지 않는 이유
APNs는 제공자 서버와 사용자의 Apple 기기 사이에 위치합니다. 서버는 Apple에 인증하고 알림을 제출한 후 APNs에 알림을 등록된 애플리케이션과 기기에 전달하도록 요청합니다. 인증서가 만료되거나 취소되거나 잘못된 식별자와 관련된 경우 또는 올바르게 설치되지 않은 경우 요청은 전달 시작 전에 실패할 수 있습니다.
Apple은 APNs가 취소된 인증서 목록을 유지하고 서버가 목록에 있는 인증서를 사용하는 경우 TLS 연결을 거부한다고 말합니다. 따라서 인증서 관리는 전달 요구 사항이 아닌 관리 선호도가 아닙니다. 서버는 알림 작업을 지역적으로 계속 처리할 수 있지만 Apple은 제공자 연결을 거부할 수 있습니다.
앱 푸시와 MDM 푸시를 분리
첫 번째 진단 질문은 간단합니다: 운영 중인 서비스는 무엇인가요?
| 인증서 경로 | 무엇을 하는가 | 일반적인 소유자 |
|---|---|---|
| 애플 푸시 | 사용자 기기에서 알림 및 기타 애플리케이션 알림을 전송한다 | 모바일 또는 백엔드 엔지니어링 |
| MDM 푸시 | 관리되는 애플 기기와 통신할 수 있도록 장치 관리 플랫폼에게 허용한다 | IT, 엔드포인트 또는 기업 모빌리티 관리 |
이 인증서는 교환할 수 없다. MDM 플랫폼은 MDM 푸시 인증서가 만료될 때 등록된 기기와 연결을 잃을 수 있으며 애플리케이션 백엔드는 App Push 인증서가 유효하지 않아 알림 전달을 잃을 수 있다. 두 가지를 하나의 "애플 푸시 인증서" 문제로 처리하면 오류를 해결하는 방향을 틀게 된다.
Capacitor 및 아이오닉 팀의 경우 사용자에게 보이는 알림의 관련 경로는 일반적으로 애플 푸시. 앱은 여전히 Push Notifications 기능, 올바른 서명, 기기 등록 및 APNs 환경을 통해 알림을 전송하는 백엔드가 필요하다. 팀이 또한 오버-더-에어 웹 자산을 배송하는 경우 푸시 인증을 분리하는 릴리스 워크플로우를 유지하라. 푸시 인증과 릴리스 워크플로우를 분리하는 것이 중요하다. Capacitor 알림 플러그인 문서 애플리케이션 측 통합을 다루며 APNs 자격 증명은 제공자 구성에 속합니다.
첫 번째 UI가 아닌 거부부터 시작하세요.
APNs 응답을 확인하기 전에 알림 복사본을 변경하거나 앱을 재빌드하지 마십시오. 그런 다음 빌드 식별자, 자격 증명 식별자, 환경, 인증서 상태를 확인하십시오. 알림 허용 문제는 사용자가 알림을 볼 수 없게 하지만 APNs TLS 거부는 설명하지 않습니다.
릴리스 후 실패가 나타났다면, 새로운 빌드의 서명과 권한을 이전 빌드와 비교하십시오. 앱 변경 없이 나타났다면, 인증서 만료, 취소, 신뢰 저장소 변경, 배포 비밀을 먼저 검사하십시오. 더 광범위한 구현 경로를 보려면 이 가이드를 참조하십시오. Expo 푸시 알림 설정.
APNs 인증서 만들기 및 다운로드
푸시 론칭이 첫 번째 알림이 전송되기 전에 실패할 수 있습니다. 인증서가 잘못된 앱 ID에 발급되었거나 개인 키가 다른 맥에 남아 있는 경우입니다. 애플의 워크플로우는 두 부분으로 구성됩니다. 머신은 CSR, 즉 인증서 요청서를 생성하고, 애플은 선택한 앱 ID에 서명합니다. CSR는 서버 자격 증명이 아닙니다. 발급된 인증서를 개인 키와 연결합니다. 앱 ID 준비애플 개발자 포털에 로그인하여
Certificate Signing Request
을 열어보십시오. 인증서, 식별자 및 프로파일. 선택 식별자, 앱의 번들 식별자를 선택하고 구성 파일을 열어보세요. 푸시 알림 이용하기 전에 푸시 알림이 활성화되어 있는지 확인하세요.
APNs 인증서는 애플리케이션의 고유성을 기반으로 생성됩니다. 유사한 이름의 근처의 번들 식별자를 선택하지 마세요. 각 별도의 애플리케이션을 독립적으로 구성하고 일치하는 인증서를 발급하세요.
키를 보관할 맥을 열고 키체인 액세스 을 열어 CSR을 생성하거나 조직의 승인된 인증서 도구를 사용하세요. 요청 파일과 개인 키를 동일한 통제된 소유권하에 유지하세요. 다른 관리자가 CSR을 생성하면 나중에 사용 가능한 서버 번들을 위해 필요한 개인 키를 보유할 수 있습니다.
인증서를 발급하세요
In 인증서Apple Push Notification 서비스 인증서 옵션을 선택하세요. App ID를 선택하고 CSR을 업로드하고 요청을 제출하세요. Apple이 발급한 인증서를 다운로드하세요.
다운로드한 파일을 Mac에서 열어보세요. private key가 있는 곳에 설치되어야 합니다. Keychain Access에서 인증서와 매칭되는 private key를 확인할 수 있습니다. private key가 없는 인증서를 가져오면 backend가 필요한 전체 자격 증명 제공을 할 수 없습니다. 인증서 이름을 지정할 때 애플리케이션 식별자, 환경, 소유자, 만료일 정보를 기록하세요. 원본 인증서, CSR 소유 정보, 포털 계정 정보를 팀의 자격 증명 시스템에 저장하세요. 개발자의 다운로드 폴더나 개인 노트북은 운영 중인 백업이 아닙니다.인증서는 전달의 한 부분만 지원합니다. 앱은 remote notifications에 등록해야하고 서버는 결과적인 device token을 보관해야하고 제공자는 매칭되는 topic과 환경과 함께 보낼 수 있어야합니다. 그 의존성을 동일한 runbook에 유지하세요. 클라이언트 측 설정에 대해서는
__CAPGO_KEEP_0__
notifications integration guide Capacitor notifications integration guide인증서를 개인 키로 내보내기
인증서를 개인 키로 내보내기
다운로드 한 애플 인증서가 자동으로 Node.js 서비스나 관리형 푸시 제공자에 사용할 준비가 된 것은 아닙니다. 서버는 인증서와 해당하는 개인 키가 포함된 파일을 필요로 합니다. PKCS#12 .p12 파일.
열기 Keychain Access Mac에서 인증서를 설치한 컴퓨터에서 Keychain Access를 열어 APNs 인증서를 검색하고 확장하거나 검사한 후, 일치하는 식별 정보와 만료 정보를 가진 개인 키를 찾습니다. 인증서와 개인 키를 함께 선택한 후, 내보내기 액션을 사용하여 완전한 제공자 인증서로 저장할 수 있는 파일을 만듭니다. .p12 배포 전에 번들을 검증하세요
내보내기할 때 강력한 비밀번호를 지정하세요. 비밀번호는 번들 내의 개인 키를 보호하기 때문에, 저장소, 티켓, 채팅 메시지, 빌드 로그에 넣지 마십시오. 파일과 비밀번호를 비밀 관리 시스템에 업로드한 후, 알림을 보내는 서비스에만 접근 권한을 부여하십시오.
실용적인 규칙:
개인 키와 일치하지 않는 파일은 완전한 제공자 인증서가 아닙니다. __CAPGO_KEEP_0__
.p12__CAPGO_KEEP_0__
제품 사용 전, 제어 환경에서 패키지를 테스트하세요. 백엔드가 파일을 로드할 수 있고, APNs 연결을establish하고, Apple이 요청을 거부할 때 구조화된 오류를 반환할 수 있는지 확인하세요. 제공자 Capgo가 iOS 푸시 인증서를 요청한다면, 애플리케이션 Capgo에 임베디드하지 않고 지정된 비밀 구성으로 암호를 업로드하세요. .p12 and its password through the designated secret configuration rather than embedding either value in application code.
이 형식은 레거시 워크플로우의 약점을 드러냅니다. 원래 개인 키를 보존하고, 수동 내보내기를 반복하고, 파일을 보호하고, 배포 비밀을 갱신할 때 다시 배포해야 합니다. 여러 앱을 운영하는 팀은 쉽게 어느 패키지가 어느 App ID에 속하는지 잊을 수 있습니다.
사용 CI/CD PIPELINES에서 안전한 비밀 관리 인증서를 읽거나 교체할 수 있는 사람을 제어하세요. 업로드와 회전에 대한 감사 기록을 유지하세요. 그러나 개인 키나 암호를 로깅하지 마세요. .p12 새로운 백엔드 작업을 평가할 때, 인증서 인증이 여전히 적합한지 확인하세요. 기존 통합은
인증서를 교체할 필요가 없지만, 토큰 인증은 제공자 연결에서 연간 인증서 교체를 제거합니다. 그러나 이것은 보호하고 회전해야 하는 것을 바꾸지 않습니다. .p12New Token-Based Authentication으로 마이그레이션
Apple은 APNs 인증을
제공자 토큰 으로 이동했습니다.Apple Push Notification Service 인증서 p8 워크플로우인증서와 개인 키 대신, TLS 정체성을 위한 장기적인 인증서가 아닌 Apple Push Notification service 인증 키로 인증 토큰을 인증합니다.
Apple Developer Portal에서 Certificates, Identifiers & Profiles을 열고 Keys 에서 APNs 인증 키를 등록하세요. 다운로드한 파일을 고가치의 서명 비밀로 취급하세요. .p8 이전 환경에서 파일을 교체하지 않고 테스트되지 않은 환경에서 프로덕션 트래픽을 교체하지 마세요. 기존 인증서 경로에 토큰 인증을 함께 구축하고, 샌드박스 및 프로덕션 동작을 검증하고, APNs 응답을 비교한 후에 제공자 구성 변경을 제어된 배포 중에 진행하세요.
이전 인증서 갱신 및 Keychain 내보내기 단계를 보낼 경로에서 제거하지만, 팀은 명확한 소유권 모델이 필요합니다. 키를 생성, 취소, 배포할 수 있는 사람을 결정하세요. 백엔드 서비스에 대한 액세스를 제한하고, 현재 키가 사용할 수 없게 되기 전에緊急 대체 프로세스가 존재하는지 확인하세요.
이전 인증서 갱신 및 Keychain 내보내기 단계를 보낼 경로에서 제거하지만, 팀은 명확한 소유권 모델이 필요합니다. 키를 생성, 취소, 배포할 수 있는 사람을 결정하세요. 백엔드 서비스에 대한 액세스를 제한하고, 현재 키가 사용할 수 없게 되기 전에緊急 대체 프로세스가 존재하는지 확인하세요.
이전 인증서 갱신 및 Keychain 내보내기 단계를 보낼 경로에서 제거하지만, 팀은 명확한 소유권 모델이 필요합니다. 키를 생성, 취소, 배포할 수 있는 사람을 결정하세요. 백엔드 서비스에 대한 액세스를 제한하고, 현재 키가 사용할 수 없게 되기 전에緊急 대체 프로세스가 존재하는지 확인하세요.
For a Capacitor 앱, 클라이언트는 여전히 정확한 알림 등록 및 권한이 필요합니다. 이 마이그레이션은 주로 서버에서 APNs 인증을 변경합니다.디바이스 토큰 등록 code가 아닌 것입니다. 백엔드에서는 여전히 올바른 애플리케이션과 환경과 관련된 토큰을 연관시켜야 합니다.
인증서가 남아 있는지 알기 위해
일부 기업 도구 및established 통합은 여전히 인증서 기반 구성이 노출됩니다. 받는 시스템이 지원하고 팀이 완전한 경로를 테스트할 때까지 p8 마이그레이션을 강제하지 마십시오. 전환 중에 레거시 자격 증명을 보호하되, 토큰 인증이 적합할 때 새로운 의존성을 만들지 마십시오.
surrounding application flow를 이해해야 하는 경우 Ionic과 Capacitor 푸시 알림을 Firebase와 함께 검토하십시오.. Firebase는 애플리케이션 배포層을 제공할 수 있지만, Apple 자격 증명, 권한, 등록 및 APNs 응답은 의도적인 구성이 필요합니다.
인증서의 유효 기간을 갱신하고 관리하는 방법
APNs 인증서를 생성한 날부터 유효한 프로덕션 의존성으로 다루십시오. Apple은 이러한 인증서가 생성 후 1년 동안 유효하다고 말합니다. 그것은 만료되기 전에 갱신되어 장치 통신을 유지해야 합니다. 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의 응답을 검사하세요. 제공업체 형식들을 비교하세요.
요구사항
| 인증서 워크플로우 | 토큰 워크플로우 | 기본 비밀 |
|---|---|---|
| 인증서와 개인 키 | __CAPGO_KEEP_0__ | .p8 인증 키 |
| 갱신 문제 | 인증서 만료는 반복적인 교체가 필요합니다. | 연간 인증서 교체가 없습니다. |
| 배포 작업 | 설치, pair, export, 및 업로드 | 인증서 서명 키를 저장하고 토큰 생성을 구성합니다. |
| 주요 실패 위험 | wrong 인증서, private 키 누락, 만료, 또는 취소 | 인증 키가 사라졌거나 노출되거나 취소되었습니다. |
애플의 인증서 생태계도 정기적인 신뢰-chain 작업이 필요했습니다. 애플은 APNs sandbox 서버 인증서 업데이트를 2025년 1월 20일 발표했습니다. 2025년 1월 20일 애플 푸시 알림 서비스 인증서 2025년 2월 24일, 인증서를 포함하기 위해 신뢰 저장소에 SHA-2 Root USERTrust RSA 인증서를 포함해야 함 USERTrust RSA 인증서 Apple APNs 서버 인증서 발표를 읽으십시오. 인증서 소유권을 플랫폼 체크리스트에 포함하십시오. 공유된 갱신 캘린더, 이름이 지정된 소유자, 배포 실행 책을 사용하십시오.
__CAPGO_KEEP_0__ 인증서 관리 문서 Capgo certificate management documentation 인증서 관리
인증서가 만료되거나 소유자가 떠나거나 개인 키가 오래된 맥에만 존재하는 경우 발생하는 어려운 사례
인증서의 원래 애플 ID와 올바른 인증서 식별 정보가 필요하기 때문에 접근과 증명력이 파일 자체보다 중요합니다.
Start by classifying the failure:
- 만료된 인증서: 원래 계정에서 대체 인증서를 생성하고 일치하는 개인 키와 함께 재설치한 후 제공자 업데이트 및 테스트 전송을 진행합니다. 기기와의 통신이 이미 중단된 경우, 서버 측 대체가 즉시 모든 기기에 복원되는 것을 가정하지 말고 Apple의 복구 지침을 따르세요.
- 철회된 인증서: 기존 인증서를 복구 가능한 것으로 간주하지 마십시오. Apple은 철회된 인증서를 사용하는 서버에서 TLS 연결을 거부하므로 유효한 대체 인증서를 생성하고 활성 배포에서 철회된 비밀을 제거하세요. 인증서를 철회한 사람을 확인하고 다른 시스템이 동일한 인증서를 복사한 경우를 확인하세요.
- 잃어버린
.p12비밀번호: 사용 가능한 비밀번호가 없는 인증서 파일은 운영상 사용할 수 없습니다. 승인된 백업을 복원하거나 대체 인증서를 발급하는 대신 생산 비밀 제어를 약화시키지 마십시오. - 잃어버린 개인 키: 공개 인증서를 다시 다운로드하는 것은 개인 키를 재생성하지 않습니다. 제어된 기기에서 새로운 CSR를 생성하고 대체 인증서를 발급하세요.
- Apple ID 접근권한을 잃어버렸다: 조직이 계정에 대한 접근 권한을 회복할 수 있는지 확인하세요. Apple은 관련 포털을 통해 생성된 APNs 인증서에 대한 지원을 배포 프로그램 지원.
재구축은 단순한 파일 이름만으로는 불가능합니다. 애플 ID 소유자, 앱 ID, 인증서 ID, 개인 키 위치, 제공자 구성, 및 대체 절차를 재해가 발생하기 전에 기록하세요.
운영 안전망을 구축하세요.
인증서 및 키를 공유하고 접근 제어를 하는 보관소에 넣으세요. 파일과 비밀번호를 분리하고, 프로덕션에 대한 접근을 제한하고, 정확한 포털 계정을 사용하여 갱신을 문서화하세요. CI/CD 시스템은 배포 시 시크릿을 주입하고, 인증 실패를 감지하는 헬스 체크를 실행하여 사용자가 누락된 알림을 보고하기 전에 실행하세요. .p8 플랫폼이 허용하는 경우에만 제어된 대체를 위해 이전 인증서를 보유하세요. 그러나 오래된 시크릿을 무제한으로 활성화하지 마세요. 테스트는 프로덕션과 동일한 백엔드 경로를 사용하여, 제공자의 환경, 번들 식별자, 및 장치 토큰 저장소도 포함하여 대체를 테스트하세요. .p12 재해가 이미 발생한 경우 APNs 응답 본문과 타임스탬프를 보존하세요. 첫 번째 거부된 요청을 식별하고, 배포 시크릿을 재해 이전과 이후로 비교하세요. 무효한 인증서에 대해 무제한으로 재시도하지 마세요. 첫 번째로 인증 또는 인증 문제를 수정하세요. 그리고 알려진 테스트 장치에 작은 검증 알림을 보내세요.
__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 자격 증명 라이프 사이클과 릴리스 프로세스와 함께 적합한지 검토하는 방법을 알아보세요.
