Sertifikat Apple Push Notification service berlaku selama satu tahun dan harus diperbarui setiap tahun di Apple Developer Portal untuk menghindari gangguan komunikasi perangkat. Jika Anda bertanggung jawab atas aplikasi Capacitor, kredensial yang kedaluwarsa atau dicabut dapat menghentikan notifikasi meskipun aplikasi itu sendiri tampak sehat.
Kegagalan ini sering muncul di saat yang paling tidak tepat. Rilis sudah keluar, kampanye terjadwal, dan pengiriman notifikasi tiba-tiba berhenti. Server aplikasi Anda mungkin masih menerima job, tetapi APNs bisa menolak koneksi TLS sebelum pesan sampai ke perangkat. Solusi praktisnya bukan sekadar membuat sertifikat baru. Anda perlu memahami kredensial APNs mana yang digunakan sistem Anda, menyimpan private key, merencanakan perpanjangan, dan memindahkan workload yang sesuai ke autentikasi berbasis token.
Table of Contents
- Mengapa Push Notification Berhenti Berfungsi
- Membuat dan mengunduh sertifikat APNs Anda
- Ekspor Sertifikat ke Private Key
- Migrasi ke Autentikasi Berbasis Token Baru
- Memperbarui dan Mengelola Siklus Hidup Sertifikat
- Troubleshooting dan Penanganan Kredensial yang Hilang
Mengapa Push Notification Berhenti Berfungsi
APNs berada di antara server provider Anda dan perangkat Apple pengguna. Server Anda melakukan autentikasi ke Apple, mengirim notifikasi, dan mengandalkan APNs untuk merutekannya ke aplikasi dan perangkat yang terdaftar. Jika kredensial kedaluwarsa, dicabut, terkait dengan identitas yang salah, atau terpasang dengan tidak benar, permintaan dapat gagal sebelum pengiriman dimulai.
Apple menyatakan bahwa APNs menyimpan daftar sertifikat yang dicabut dan menolak koneksi TLS dari server yang menggunakan sertifikat dalam daftar tersebut. Hal ini menjadikan kebersihan sertifikat sebagai persyaratan pengiriman, bukan preferensi administratif. Server mungkin terus memproses pekerjaan notifikasi secara lokal, sementara Apple menolak koneksi provider.
Pisahkan push aplikasi dari push MDM
Pertanyaan diagnostik pertama sederhana: layanan apa yang sedang Anda coba operasikan?
| Jalur kredensial | Fungsinya | Pemilik umum |
|---|---|---|
| Push Aplikasi | Mengirimkan peringatan dan notifikasi aplikasi lainnya ke perangkat pengguna akhir | Rekayasa mobile atau backend |
| MDM Push | Memungkinkan platform manajemen perangkat berkomunikasi dengan perangkat Apple yang dikelola | IT, endpoint, atau administrasi mobilitas enterprise |
Kredensial ini tidak dapat dipertukarkan. Platform MDM dapat kehilangan kontak dengan perangkat yang terdaftar ketika kredensial push MDM-nya kedaluwarsa, sementara backend aplikasi dapat kehilangan pengiriman notifikasi karena kredensial App Push-nya tidak valid. Memperlakukan keduanya sebagai satu masalah “sertifikat push Apple” akan mengarahkan pemecahan masalah ke arah yang salah.
Untuk tim Capacitor dan Ionic, jalur yang relevan untuk peringatan yang ditujukan ke pengguna umumnya adalah Push Aplikasi. Aplikasi tetap membutuhkan capability Push Notifications, signing yang benar, registrasi perangkat, dan backend yang mengirim melalui environment APNs yang sesuai. Jika tim Anda juga mengirimkan web assets secara over-the-air, pisahkan workflow rilis itu dari autentikasi push. Dokumentasi plugin notifikasi Capacitor mencakup integrasi sisi aplikasi, sedangkan kredensial APNs ada di konfigurasi provider.
Mulai dari penolakan, bukan UI
Periksa respons APNs dari server provider Anda sebelum mengubah teks notifikasi atau rebuild aplikasi. Lalu verifikasi bundle identifier, identitas kredensial, environment, dan status sertifikat. Masalah izin notifikasi memengaruhi kemampuan user melihat alert, tetapi tidak menjelaskan penolakan TLS dari APNs.
Jika kegagalan muncul setelah rilis, bandingkan signing dan entitlements di build baru dengan build sebelumnya. Jika muncul tanpa perubahan aplikasi, periksa masa berlaku sertifikat, revocation, perubahan trust-store, dan deployment secrets terlebih dahulu. Untuk jalur implementasi yang lebih luas, lihat panduan ini untuk Setup push notification Expo.
Membuat dan mengunduh sertifikat APNs Anda
Rollout push bisa gagal sebelum notifikasi pertama dikirim jika sertifikat diterbitkan untuk App ID yang salah atau private key tertinggal di Mac lain. Workflow Apple terdiri dari dua bagian: komputer Anda membuat Permintaan Penandatanganan Sertifikat, atau CSR, lalu Apple menandatanganinya untuk App ID yang dipilih. CSR bukanlah kredensial server. CSR menghubungkan sertifikat yang diterbitkan dengan private key yang dibuat secara lokal.
Siapkan App ID
Masuk ke portal Apple Developer dan buka Sertifikat, Identifiers & Profiles. Pilih Pengenal, pilih bundle identifier aplikasi, dan buka konfigurasinya. Pastikan bahwa Notifikasi Push diaktifkan sebelum menerbitkan apa pun.
Kredensial APNs terikat pada identitas aplikasi. Jangan pilih bundle identifier lain yang namanya mirip. Konfigurasikan setiap aplikasi secara terpisah dan terbitkan kredensial yang sesuai.
Pada Mac yang akan menyimpan key tersebut, buka Akses Keychain dan buat CSR, atau gunakan tooling sertifikat yang disetujui organisasi Anda. Simpan file permintaan dan private key dalam kepemilikan terkontrol yang sama. Jika administrator lain yang membuat CSR, administrator itu mungkin memegang private key yang nanti dibutuhkan untuk server bundle yang bisa dipakai.
Terbitkan sertifikat yang sudah ditandatangani
Di Sertifikat, pilih opsi sertifikat Apple Push Notification service. Pilih App ID, upload CSR, lalu kirim permintaan. Download sertifikat yang diterbitkan Apple.
Klik dua kali file yang diunduh di Mac yang memegang private key. File itu akan terinstal di Akses Keychain, tempat Anda bisa memverifikasi sertifikat dan private key yang cocok. Sertifikat yang diimpor tanpa key tersebut tidak bisa menyediakan kredensial lengkap yang dibutuhkan backend Anda.
Gunakan konvensi penamaan yang mencatat identitas aplikasi, environment, pemilik, dan detail masa berlaku. Simpan sertifikat asli, info kepemilikan CSR, dan detail akun portal di sistem kredensial tim Anda. Folder Downloads atau laptop pribadi developer bukan backup operasional.
Sertifikat ini hanya mendukung satu bagian dari pengiriman. Aplikasi harus mendaftar untuk remote notifications, server harus menyimpan device token yang dihasilkan, dan provider harus mengirim dengan topic dan environment yang sesuai. Simpan dependensi tersebut dalam runbook yang sama. Untuk setup sisi client, lihat panduan integrasi notifikasi Capacitor. Perlakukan sertifikat ini sebagai kredensial terkelola, bukan sekadar download sekali, karena export, migrasi token, renewal, dan recovery nanti bergantung pada siapa yang mengontrol key-nya.
Ekspor Sertifikat ke Private Key
Sertifikat Apple yang diunduh tidak otomatis siap untuk layanan Node.js atau managed push provider. Server membutuhkan sertifikat beserta private key pasangannya, yang biasanya dikemas sebagai PKCS#12 .p12 file.
Buka Akses Keychain di Mac tempat Anda menginstal sertifikat. Cari sertifikat APNs, periksa atau kembangkan detailnya, lalu temukan private key dengan identitas dan informasi kedaluwarsa yang sesuai. Pilih sertifikat dan private key secara bersamaan, lalu gunakan aksi export untuk menyimpan file .p12 Anda.
Validasi bundle sebelum deployment
Beri password yang kuat untuk export tersebut. Password melindungi private key di dalam bundle, jadi jangan simpan di repository, tiket, pesan chat, atau build log. Upload file dan password melalui sistem secret-management Anda, lalu berikan akses hanya ke layanan yang mengirim notifikasi.
Aturan praktis: Sebuah
.p12file tanpa private key yang sesuai bukanlah kredensial provider yang lengkap.
Sebelum digunakan di produksi, uji bundle di lingkungan yang terkontrol. Pastikan backend Anda dapat memuat file, membangun koneksi APNs, dan mengembalikan error terstruktur ketika Apple menolak permintaan. Jika provider seperti Capgo meminta kredensial push iOS, upload .p12 dan password-nya melalui konfigurasi secret yang ditentukan, bukan dengan menyematkan nilai tersebut di code aplikasi.
Format ini juga mengungkap kelemahan alur kerja legacy. Anda harus menyimpan private key asli, mengulangi ekspor manual, melindungi file, dan mengganti secret deployment saat perpanjangan. Tim yang mengoperasikan beberapa aplikasi dengan mudah kehilangan lacak bundle mana yang milik App ID mana.
Gunakan manajemen secret yang aman di pipeline CI/CD untuk mengontrol siapa yang dapat membaca atau mengganti kredensial. Simpan jejak audit untuk upload dan rotasi, tetapi jangan pernah mencatat private key atau .p12 password.
Untuk pekerjaan backend baru, evaluasi apakah autentikasi sertifikat masih tepat. Integrasi yang ada mungkin memerlukan .p12, tetapi autentikasi token biasanya menghilangkan penggantian sertifikat tahunan dari koneksi provider. Itu tidak menghilangkan tata kelola kredensial. Itu mengubah apa yang Anda lindungi dan rotasi.
Migrasi ke Autentikasi Berbasis Token Baru
Apple telah mengalihkan autentikasi APNs ke provider token, yang biasa disebut workflow p8. Alih-alih menggunakan sertifikat dan private key untuk identitas TLS jangka panjang, provider Anda kini menandatangani token autentikasi dengan Apple Push Notification service Authentication Key.
Buat key di portal Apple Developer pada bagian Sertifikat, Identifiers & Profiles, lalu buka Kunci dan daftarkan APNs authentication key. Download .p8 file tersebut dan simpan Key ID serta Team ID terkait di secret store Anda. Perlakukan file yang di-download sebagai secret signing bernilai tinggi.
Lakukan migrasi secara terencana
Jangan alihkan traffic produksi hanya dengan mengganti file di environment yang belum diuji. Bangun autentikasi token di samping path sertifikat yang ada, validasi perilaku sandbox dan produksi, lalu bandingkan respons APNs. Setelah itu, lakukan perubahan konfigurasi provider saat deployment terkendali.
Migrasi ini menghapus langkah pembaruan sertifikat dan ekspor Keychain dari jalur pengiriman, namun tim Anda tetap butuh model kepemilikan yang jelas. Tentukan siapa yang bisa membuat, mencabut, dan men-deploy key. Batasi akses ke backend service yang menandatangani provider token, dan pastikan proses penggantian darurat sudah siap sebelum key saat ini tidak bisa digunakan.
Untuk aplikasi Capacitor, client tetap membutuhkan registrasi notifikasi dan entitlements yang benar. Migrasi ini utamanya mengubah autentikasi server-ke-APNs, bukan registrasi device token code. Backend Anda harus tetap mengaitkan token dengan aplikasi dan environment yang tepat.
Pahami kapan sertifikat tetap diperlukan
Beberapa tool enterprise dan integrasi yang sudah mapan masih mengekspos konfigurasi berbasis sertifikat. Jangan paksa migrasi p8 sampai sistem penerima mendukungnya dan tim Anda sudah menguji seluruh jalurnya. Tetap amankan kredensial legacy selama transisi, tapi jangan membuat dependensi baru padanya saat autentikasi token cocok.
Jika Anda perlu memahami alur aplikasi di sekitarnya, tinjau Ionic dan push notifications Capacitor dengan Firebase. Firebase bisa menyediakan layer pengiriman aplikasi, tapi kredensial Apple, entitlements, registrasi, dan respons APNs tetap butuh konfigurasi yang cermat.
Memperbarui dan Mengelola Siklus Hidup Sertifikat
Anggap sertifikat APNs sebagai dependensi produksi yang akan kedaluwarsa sejak hari pertama dibuat. Apple menyatakan sertifikat ini berlaku selama satu tahun sejak pembuatan dan harus diperbarui sebelum kedaluwarsa agar komunikasi perangkat tetap terjaga. Apple juga memperingatkan bahwa kegagalan memperbarui dapat mengharuskan pengguna mendaftarkan ulang perangkat iOS, iPadOS, dan Mac ke APNs serta menyebabkan gangguan layanan. Lihat dokumentasi Apple tentang pembaruan sertifikat push notification.
Alur pembaruannya sangat spesifik:
- Generate CSR baru: Buat request melalui workflow yang sudah disetujui dan simpan material key terkait.
- Gunakan Apple ID asli: Login dengan Apple ID yang sama yang dipakai untuk membuat sertifikat yang ada.
- Pilih sertifikat yang akan kedaluwarsa: Pastikan App ID, Subject DN, UID, dan detail masa berlaku sudah sesuai sebelum memilih Perbarui.
- Upload CSR: Kirim request baru di Apple Push Certificates Portal.
- Download dan instal ulang: Ambil sertifikat yang sudah diperbarui
.pem, instal di tempat private key tersedia, dan export penggantinya.p12jika provider Anda membutuhkannya. - Deploy dan tes: Perbarui server secret, kirim notifikasi terkontrol, dan periksa respons APNs.
Bandingkan format provider
| Persyaratan | Alur kerja sertifikat | Alur kerja token |
|---|---|---|
| Secret utama | Sertifikat plus private key | .p8 kunci autentikasi |
| Kekhawatiran perpanjangan | Kedaluwarsa sertifikat memerlukan penggantian berulang | Tidak ada penggantian sertifikat tahunan |
| Pekerjaan deployment | Instal, pair, export, dan upload | Simpan signing key dan konfigurasikan pembuatan token |
| Risiko kegagalan utama | Sertifikat salah, private key hilang, kedaluwarsa, atau dicabut | Authentication key hilang, terekspos, atau dicabut |
Ekosistem sertifikat Apple juga memerlukan pemeliharaan trust-chain terjadwal. Apple mengumumkan pembaruan sertifikat server APNs untuk sandbox pada 20 Januari 2025 dan produksi pada 24 Februari 2025, yang mengharuskan trust store menyertakan sertifikat SHA-2 Root USERTrust RSA Certification Authority sertifikat. Baca pengumuman sertifikat server APNs Apple dan jadikan kepemilikan trust store bagian dari checklist platform Anda.
Gunakan kalender perpanjangan bersama, penanggung jawab yang jelas, dan runbook deployment. dokumentasi manajemen sertifikat Capgo dapat diletakkan berdampingan dengan runbook tersebut untuk tim yang mengelola kredensial pengiriman iOS dalam proses rilis mobile mereka.
Troubleshooting dan Penanganan Kredensial yang Hilang
Insiden yang sulit tidak selalu berupa peringatan kedaluwarsa. Ini adalah pagi hari ketika administrator yang membuat sertifikat sudah pergi, kunci privat hanya ada di Mac lama, atau sertifikat dicabut selama upaya pembersihan. Alur perpanjangan standar bergantung pada Apple ID asli dan identitas sertifikat yang benar, sehingga akses dan asal-usul sama pentingnya dengan file-nya sendiri.
Mulai dengan mengklasifikasikan kegagalan:
- Sertifikat kedaluwarsa: Buat penggantian melalui akun asli, pasang ulang dengan kunci privat yang cocok, perbarui provider, dan uji pengiriman. Jika komunikasi perangkat sudah terputus, ikuti panduan pemulihan Apple daripada mengasumsikan penggantian sisi server secara instan memulihkan setiap perangkat.
- Sertifikat dicabut: Berhenti memperlakukan kredensial lama sebagai dapat dipulihkan. Apple menolak koneksi TLS dari server yang menggunakan sertifikat yang dicabut, jadi buat penggantian yang valid dan hapus rahasia yang dicabut dari deployment aktif. Periksa siapa yang mencabutnya dan apakah sistem lain menyalin kredensial yang sama.
- Kata sandi
.p12hilang: File sertifikat tanpa password yang dapat digunakan mungkin tidak tersedia secara operasional. Ambil backup yang disetujui atau terbitkan pengganti, alih-alih melemahkan kontrol rahasia produksi. - Private key hilang: Mengunduh ulang sertifikat publik tidak akan membuat ulang private key. Buat CSR baru di mesin yang terkontrol dan terbitkan kredensial pengganti.
- Akses Apple ID hilang: Konfirmasi apakah organisasi dapat memulihkan akun melalui proses identitas dan deployment-nya. Apple mengarahkan dukungan untuk sertifikat APNs yang dibuat melalui portal terkait ke Dukungan Program Deployment.
Pemulihan membutuhkan identitas, bukan hanya nama file. Catat pemilik Apple ID, App ID, identitas sertifikat, lokasi private key, konfigurasi provider, dan prosedur penggantian sebelum insiden terjadi.
Bangun jaring pengaman operasional
Simpan sertifikat dan .p8 keys di vault bersama yang terkontrol aksesnya. Simpan .p12 password terpisah dari file, batasi akses produksi, dan dokumentasikan akun portal yang tepat yang digunakan untuk perpanjangan. Sistem CI/CD Anda harus menyuntikkan secrets saat deployment dan menjalankan health check yang mendeteksi kegagalan autentikasi sebelum pengguna melaporkan peringatan yang hilang.
Jaga agar kredensial lama tetap tersedia selama penggantian yang terkontrol jika platform mengizinkannya, tetapi jangan biarkan secret yang sudah usang tetap aktif tanpa batas waktu. Uji penggantian pada jalur backend yang sama dengan yang digunakan produksi, termasuk lingkungan penyedia, bundle identifier, dan penyimpanan device-token.
Ketika gangguan sudah terjadi, simpan respons body dan timestamp APNs, identifikasi permintaan pertama yang ditolak, dan bandingkan secret deployment sebelum dan sesudah insiden. Jangan retry tanpa batas terhadap kredensial yang tidak valid. Perbaiki masalah identitas atau autentikasi terlebih dahulu, lalu kirim notifikasi verifikasi kecil ke perangkat uji yang diketahui.
Capgo dapat menyimpan dan mengonfigurasi kredensial push iOS sebagai bagian dari alur kerja notifikasi Capacitor, sementara tim Anda tetap bertanggung jawab atas akses akun Apple, penyimpanan secret, dan keputusan perpanjangan. Kunjungi Capgo untuk meninjau bagaimana tooling pengiriman mobile-nya dapat melengkapi siklus hidup kredensial APNs dan proses rilis Anda.
Pertanyaan yang sering diajukan
Apakah sertifikat SSL klien untuk notifikasi push dipindahkan ketika aplikasi dipindahkan ke akun Apple lain?
Tidak. Dokumentasi transfer aplikasi Apple menyatakan bahwa sertifikat SSL klien untuk notifikasi push tidak dipindahkan. Setelah transfer, tim penerima harus membuat sertifikat APNs baru atau, lebih baik, menggunakan kunci .p8 berbasis token dari akun mereka sendiri, lalu memperbarui penyedia push. Lihat bermigrasi ke autentikasi berbasis token.
