애플 푸시 알림 서비스 인증서는 1년 동안 유효하며, 연간 Apple Developer Portal에서 갱신하지 않으면 장치 통신을 중단하는 것을 피하기 위해 갱신해야 합니다. 당신이 Capacitor 앱의 책임을 지는 경우 만료되거나 취소된 자격증은 앱이 보이는 것과는 달리 알림을 중단할 수 있습니다.
애플 푸시 알림 서비스 인증서 문제는 때때로 최악의 시기에 발생합니다. 릴리스가 출시되고 캠페인이 예약되면, 알림 전송이 갑자기 멈추게 됩니다. 애플 푸시 알림 서비스(APNs)는 TLS 연결을 수락하기 전에 메시지가 장치에 도달하기 전에 애플리케이션 서버가 작업을 수락할 수 있지만, APNs가 인증서를 거부할 수 있습니다. 단순히 다른 인증서를 생성하는 것만으로는 문제를 해결할 수 없습니다. 시스템에서 사용하는 APNs 인증서를 이해하고, 개인 키를 보존하고, 갱신을 계획하고, 토큰 기반 인증으로 적절한 워크로드를 이동해야 합니다.
Table of Contents
- 푸시 알림이 작동하지 않습니다.
- APNs 인증서 만들기 및 다운로드
- 개인 키로 인증서를 내보내기
- 신규 토큰 기반 인증으로 마이그레이션
- 인증서의 수명주기를 갱신하고 관리하십시오
- 인증 정보가 손실된 경우 문제 해결 및 처리
푸시 알림이 작동하지 않는 이유
APNs는 제공자 서버와 사용자의 애플 기기 사이에 위치합니다. 서버는 애플에 인증하고 알림을 제출한 후 APNs에 알림을 라우팅하도록 의뢰합니다. 만약 인증 정보가 만료되거나 취소되거나 올바른 식별자와 관련된 경우 또는 올바르게 설치되지 않은 경우, 요청은 전달을 시작하기 전에 실패할 수 있습니다.
애플은 APNs가 취소된 인증서 목록을 유지하고 서버가 취소된 인증서 목록에 있는 인증서를 사용하는 서버에 대한 TLS 연결을 거부한다고 말합니다. 따라서 인증서 관리는 전달 요구 사항이 아닌 관리 선호도가 아닙니다. 서버는 알림 작업을 지역적으로 계속 처리할 수 있지만 애플은 제공자 연결을 거부합니다.
앱 푸시와 MDM 푸시를 분리하십시오
첫 번째 진단 질문은 간단합니다: 운영하려는 서비스가 무엇인지 알려주세요.
| 인증 경로 | 무엇을 하는가 | 일반적인 소유자 |
|---|---|---|
| 애플 푸시 | 사용자 기기에서 알림 및 기타 애플리케이션 알림을 전송합니다. | 모바일 또는 백엔드 엔지니어링 |
| MDM 푸시 | 관리되는 애플 기기와 통신할 수 있도록 장치 관리 플랫폼을 허용합니다. | IT, 엔드포인트 또는 엔터프라이즈 모빌리티 관리 |
이 인증서는 교환할 수 없습니다. MDM 플랫폼이 등록된 장치와의 연락을 잃을 수 있습니다. 만약 MDM 푸시 인증서가 만료되면, 애플리케이션 백엔드가 알림 전달을 잃을 수 있습니다. 만약 App Push 인증서가 유효하지 않다면.
Apple Push Notification Service 인증서에 대한 Capacitor 및 Ionic 팀의 관련 경로는 일반적으로 앱 푸시. 앱은 여전히 푸시 알림 기능, 올바른 서명, 장치 등록 및 APNs 환경에 맞는 백엔드가 푸시 알림을 전송하는 것을 필요로 합니다. 만약 팀이 오버-더-에어 웹 자산을 배포하는 경우, 푸시 인증과 배포 워크플로우를 분리하세요. __CAPGO_KEEP_0__ 알림 플러그인 문서는 Capacitor 알림 플러그인 문서 는 애플리케이션 측 통합을 다루고, APNs 인증서의 속성을 APNs 제공자 구성에 포함합니다.
UI에서 시작하지 말고, 시작점에서 시작하세요
제공자 서버에서 APNs 응답을 확인하기 전에 알림 복사본을 변경하거나 앱을 재빌드하지 마세요. 그런 다음 버전, 자격 증명, 환경, 인증서 상태를 확인하세요. 알림 허용 문제는 사용자가 알림을 볼 수 없게 하지만, APNs TLS 거부는 알림 허용 문제를 설명하지 않습니다.
배포 후 실패가 나타났다면, 새로운 빌드와 이전 빌드의 서명 및 권한을 비교하세요. 앱 변경 없이 나타났다면, 인증서 만료, 취소, 신뢰 저장소 변경, 배포 비밀을 먼저 검사하세요. 더 광범위한 구현 경로를 보려면 Expo 푸시 알림 설정.
APNs 인증서 만들기 및 다운로드
푸시 론아웃은 첫 번째 알림이 전송되기 전에 인증서가 잘못된 앱 ID에 발급되거나 개인 키가 다른 맥에 남아 있는 경우 실패할 수 있습니다. Apple의 워크플로우는 두 부분으로 구성되며, 머신은 인증서 서명 요청또는 CSR, 그리고 Apple이 선택한 App ID에 서명합니다. CSR는 서버 인증서가 아닙니다. CSR은 로컬에서 생성한 개인 키와 연결된 발급 된 인증서를 연결합니다.
앱 ID 준비
Apple 개발자 포털에 로그인하고 열어보세요. 인증서, 식별자 및 프로필. 식별자 선택 식별자, 앱의 번들 식별자 선택하고, 그 구성 열어보세요. 발급 전 확인하세요. 푸시 알림 인증서를 발급하기 전에 활성화되어야 합니다.
푸시 알림이 활성화되어 있어야 발급합니다.
Mac에서 키를 보관할 컴퓨터를 열어 인증서를 보관할 맥을 열고, 키체인 액세스 열어보세요. CSR을 생성하거나 조직의 승인된 인증서 도구를 사용하여 CSR을 생성하세요. 요청 파일과 개인 키를 동일한 제어된 소유권 하에 유지하세요. 다른 관리자가 CSR을 생성하면, 관리자는 나중에 사용 가능한 서버 번들에 필요한 개인 키를 보유할 수 있습니다.
인증서를 발급하세요.
In CertificatesApple Push Notification Service 인증서를 생성하는 데 사용되는 Linux 터미널 명령어 인터페이스를 표시하는 컴퓨터 모니터.
Apple Push Notification Service 인증서를 생성하는 데 사용되는 Linux 터미널 명령어 인터페이스를 표시하는 컴퓨터 모니터. Apple Push Notification Service 인증서를 생성하는 데 사용되는 Linux 터미널 명령어 인터페이스를 표시하는 컴퓨터 모니터.Apple Push Notification Service 인증서를 생성하는 데 사용되는 Linux 터미널 명령어 인터페이스를 표시하는 컴퓨터 모니터.
Apple Push Notification Service 인증서를 생성하는 데 사용되는 Linux 터미널 명령어 인터페이스를 표시하는 컴퓨터 모니터.
Apple Push Notification Service 인증서를 생성하는 데 사용되는 Linux 터미널 명령어 인터페이스를 표시하는 컴퓨터 모니터. Capacitor 알림 통합 가이드. 이 인증서를 관리형 자격증으로 다루고, 일회용 다운로드로 다루지 않는다. 나중에 키를 관리하는 사람을 알기 위해 export, 토큰 이동, 갱신, 복구가 의존하기 때문이다.
인증서를 개인 키로 내보내기
다운로드한 애플 인증서는 자동으로 Node.js 서비스나 관리형 푸시 제공자에 사용할 준비가 되어 있지 않다. 서버는 인증서와 해당 개인 키가 포함된 PKCS#12 파일이 필요하다. PKCS#12 .p12 파일.
열기 키 체인 액세스 Mac에서 인증서를 설치한 곳에서 Keychain Access를 열고, APNs 인증서를 검색하고 확장하거나 검사한 후, 해당 식별자와 유효 기간 정보와 일치하는 개인 키를 찾는다. 인증서와 개인 키를 함께 선택하고, 내보내기 액션을 사용하여 파일을 저장한다. .p12 file.
배포 전에 번들을 검증하세요.
Give the export a strong password. The password protects the private key inside the bundle, so don’t place it in a repository, ticket, chat message, or build log. Upload the file and password through your secret-management system, then grant access only to the service that sends notifications.
실무 규칙: A
.p12비밀 키와 일치하는 파일이 없는 경우 제공자 인증서는 완전하지 않습니다.
제품 사용 전에 제어 환경에서 번들을 테스트하고, 백엔드가 파일을 로드할 수 있고, APNs 연결을establish하고, Apple이 요청을 거부할 때 구조화된 오류를 반환할 수 있는지 확인하세요. 제공자 Capgo가 iOS 푸시 인증서를 요청하면, 애플리케이션 Capgo에 임베디드하지 않고, 지정된 비밀 구성에서 파일과 비밀번호를 업로드하세요. .p12 애플 푸시 알림 서비스 인증서를 사용하는 경우, 인증서와 그 비밀번호는 지정된 비밀 설정을 통해 전달되며 애플리케이션 code 내에 포함되지 않습니다.
사용
Use CI/CD pipeline에서 안전한 비밀 관리 인증서 인증이 여전히 적절한지 평가하세요. 기존 통합은 인증서 인증을 사용할 수 있지만, 토큰 인증은 제공자 연결에서 연간 인증서 갱신을 제거할 수 있습니다. 하지만, 인증서 관리는 사라지지 않습니다. 보호하고 회전해야 하는 것이 달라집니다. .p12 password.
인증서 인증이 여전히 적절한지 평가하세요. 기존 통합은 인증서 인증을 사용할 수 있지만, 토큰 인증은 제공자 연결에서 연간 인증서 갱신을 제거할 수 있습니다. 하지만, 인증서 관리는 사라지지 않습니다. 보호하고 회전해야 하는 것이 달라집니다. .p12인증서 인증이 여전히 적절한지 평가하세요. 기존 통합은 인증서 인증을 사용할 수 있지만, 토큰 인증은 제공자 연결에서 연간 인증서 갱신을 제거할 수 있습니다. 하지만, 인증서 관리는 사라지지 않습니다. 보호하고 회전해야 하는 것이 달라집니다.
새 토큰 기반 인증으로 마이그레이션
애플은 APNs 인증을 제공자 토큰으로 이동 시켰습니다.공통적으로 p8 워크플로우라고 불리는 p8 workflow장기적으로 유지되는 TLS 식별성을 위해,
제공자는 Apple Push Notification service 인증 키로 인증 토큰을 서명합니다. Apple Developer portal의 , 그런 다음 열기 에서 키를 생성하고 Keys .p8 를 열어 APNs 인증 키를 등록하세요. 다운로드한 파일을 고가치 서명 비밀로 처리하세요.
이전 마이그레이션을 의도적으로 수행하십시오
생산 트래픽을 전환하지 말고 파일을 테스트되지 않은 환경에서 교체하지 마십시오. 기존 인증서 경로 옆에 토큰 인증을 구축하고 샌드박스 및 프로덕션 동작을 검증하고 APNs 응답을 비교하십시오. 그런 다음 제어된 배포 중에 제공자 구성 변경을 수행하십시오.
이전 마이그레이션은 인증서 갱신 및 키체인 내보내기 단계를 전송 경로에서 제거하지만, 팀은 명확한 소유권 모델이 필요합니다. 키를 생성, 취소, 배포할 수 있는 사람을 결정하고 백엔드 서비스에 대한 접근을 제한하고 현재 키가 사용할 수 없게 되기 전에緊急 대체 프로세스가 존재하는지 확인하십시오.
Capacitor 앱의 경우, 클라이언트는 여전히 알림 등록 및 권한이 올바르게 구성되어야 합니다. 이전 마이그레이션은 서버에서 APNs 인증을 변경디바이스 토큰 등록 code이 아닌 것입니다. 백엔드는 여전히 토큰을 올바른 애플리케이션 및 환경과 연관시켜야 합니다.
인증서가 남아 있는 경우 알리십시오
일부 기업 도구 및established 통합은 여전히 인증서 기반 구성이 노출됩니다. p8 마이그레이션을 강제하지 마십시오. 받는 시스템이 이를 지원하고 팀이 완전한 경로를 테스트할 때까지. 전환 중에 기존 자격 증명을 보호하십시오. 그러나 토큰 인증이 적합할 때 새로운 의존성을 만들지 마십시오.
이전 마이그레이션을 이해하기 위해 주변 애플리케이션 흐름을 검토하십시오. 아이오닉과 Capacitor 푸시 알림을 Firebase와 함께. Firebase는 애플리케이션 배포層을 제공할 수 있지만, Apple 인증서, 권한, 등록, APNs 응답은 명시적인 구성이 필요합니다.
인증서의 유효 기간 관리
APNs 인증서를 생성한 날부터는 만료되는 프로덕션 의존성으로 다루세요. Apple은 이러한 인증서가 유효한 기간이 1년이라고 말합니다. 갱신 경로는 다음과 같습니다: 새로운 CSR 생성: 승인된 워크플로우를 통해 요청을 생성하고 관련 키 자료를 보존하세요..
원래 Apple ID 사용:
- 기존 인증서를 생성한 Apple ID와 동일한 ID로 로그인하세요. Renewing and Managing Certificate Lifecycles
- Treat an APNs certificate as an expiring production dependency from the day you create it. Apple says these certificates are valid for one year from creation
- 인증서가 만료되는 것을 선택하세요: 애플리케이션 ID, 주제 DN, UID, 만료 날짜를 확인한 후 선택하세요. 갱신.
- CSR 업로드: 애플 푸시 인증서 포털에서 새로운 요청을 제출하세요.
- 다운로드 및 재설치: 갱신된
.pem개인 키가 있는 곳에 설치하고, 대체를 내보내세요. 만약 제공자가 요구한다면..p12배포 및 테스트: - 서버 시크릿을 업데이트하고, 제어된 알림을 보내고, APNs 응답을 검사하세요. 제공자 형식 비교
제공자 형식 비교
| 필수 조건 | 인증서 워크플로우 | 토큰 워크플로우 |
|---|---|---|
| 기본 비밀 | 인증서와 개인 키 | .p8 인증 키 |
| 갱신 문제 | 인증서 만료는 반복적인 교체가 필요합니다. | 연간 인증서 교체가 없습니다. |
| 배포 작업 | 설치, pair, 내보내기, 업로드 | 서명 키 저장 및 토큰 생성 구성 |
| 주요 실패 위험 | 오류된 인증서, 개인 키 누락, 만료, 또는 취소 | 인증 키 노출, 잃어버리거나 취소 |
애플의 인증서 생태계는 또한 정기적인 신뢰 체인 작업이 필요했습니다. 애플은 샌드박스에 APNs 서버 인증서 업데이트 및 2025년 1월 20일 2025년 2월 24일 에 대한 프로덕션에 대해 발표했습니다. 이로 인해 신뢰 저장소에 SHA-2 루트 USERTrust RSA 인증 기관 인증서 인증서를 포함해야 합니다. 애플 APNs 서버 인증서 발표 을 읽고 플랫폼 체크리스트에 신뢰 소유권을 포함하세요. 2025년 2월 24일
__CAPGO_KEEP_0__ 인증 관리 문서 Capgo 인증서 관리 문서 실패 유형을 분류하세요.
만료된 인증서:
원래 계정에서 대체 인증서를 생성하고 일치하는 개인 키와 함께 재설치한 다음 공급자 업데이트 및 테스트 전송을 진행하세요. 기기와의 통신이 이미 중단된 경우, Apple의 복구 지침을 따르세요.
철회된 인증서:
- 기존 인증서를 복구 가능한 것으로 간주하지 마세요. Apple은 철회된 인증서를 사용하는 서버에서 TLS 연결을 거부하므로, 유효한 대체 인증서를 생성하고 활성 배포에서 철회된 비밀을 제거하세요. 인증서를 철회한 사람을 확인하고 다른 시스템이 동일한 인증서를 복사했는지 확인하세요. 잃어버린
- 비밀번호: Troubleshooting and Handling Lost Credentials
- Lost
.p12password: 운영 중에 사용할 수 없는 비밀번호가 있는 인증서 파일이 있을 수 있습니다. 승인된 백업을 다시 가져오거나 대체 인증서를 발급하는 것이 생산 비밀 제어를 약화시키는 대신에 대체 인증서를 발급하는 것이 좋습니다. - 사라진 개인 키: 공개 인증서를 다시 다운로드하는 것은 개인 키를 재생성하지 않습니다. 제어된 기기에서 새로운 CSR를 생성하고 대체 인증서를 발급하세요.
- 사라진 Apple ID 접근 권한: 계정 회복 여부를 확인하세요. Apple은 APNs 인증서를 생성한 관련 포털에 대한 지원을 제공합니다. 배포 프로그램 지원.
계정 회복은 단순한 파일 이름만으로는 불가능합니다. 사고가 발생하기 전에 Apple ID 소유자, App ID, 인증서 식별자, 개인 키 위치, 제공자 구성, 대체 절차를 기록하세요.
운영 안전망을 구축하세요.
인증서와 .p8 키를 공유된 접근 제어된 보관소에 저장하세요. .p12 인증서와
기존 인증서를 유지하고 제어된 교체 시 플랫폼이 허용하는 경우에는 오래된 비밀을 활성화하지 말고, 테스트를 동일한 백엔드 경로에서 진행하여, 제공자의 환경, 번들 식별자, 및 장치 토큰 저장소까지 포함한다.
이미 장애가 발생한 경우 APNs 응답 본문과 타임스탬프를 보존하고, 첫 번째 거부된 요청을 식별하고, 배포 비밀을 사고 이전과 이후로 비교한다. 유효하지 않은 인증서에 대해 무한히 다시 시도하지 말고, 첫 번째로 문제를 해결한 후, 알려진 테스트 장치로 작은 검증 알림을 보낸다.
Capgo은 iOS 푸시 인증서를 저장하고 구성할 수 있으며, Capacitor 알림 워크플로우의 일부로, 팀은 애플 계정 접근, 비밀 보관, 및 갱신 결정의 책임을 유지한다. Capgo Capgo
