Sertifikat layanan pemberitahuan push Apple berlaku selama satu tahun dan harus diperbarui setiap tahun di Portal Pengembang Apple untuk menghindari gangguan komunikasi perangkat. Jika Anda bertanggung jawab atas sebuah aplikasi Capacitor, sebuah kredential yang telah kedaluwarsa atau dicabut dapat menghentikan pemberitahuan bahkan ketika aplikasi itu sendiri tampak sehat.
Kegagalan sering muncul pada waktu yang paling tidak tepat. Rilis keluar, kampanye dijadwalkan, dan pengiriman pemberitahuan tiba-tiba menjadi sunyi. Server aplikasi Anda mungkin masih menerima tugas, tetapi APNs dapat menolak koneksi TLS sebelum pesan mencapai perangkat. Solusi praktis bukan hanya membuat sertifikat lain. Anda perlu memahami kredential APNs mana yang digunakan sistem Anda, menyimpan kunci pribadi, merencanakan perbaruan, dan memindahkan beban kerja yang sesuai ke autentikasi berbasis token.
Daftar Isi
- Mengapa Notifikasi Push Berhenti Berfungsi
- Membuat dan Mengunduh Sertifikat APNs
- Mengexport Sertifikat ke Kunci Pribadi
- Migrasi ke Autentikasi Berbasis Token Baru
- Merawat dan Mengelola Siklus Sertifikat
- Mengatasi Masalah dan Mengelola Kredensial Hilang
Mengapa Notifikasi Push Berhenti Berfungsi
APNs berada di antara server penyedia Anda dan perangkat Apple pengguna. Server Anda melakukan autentikasi ke Apple, mengirimkan notifikasi, dan mengandalkan APNs untuk mengirimkannya ke aplikasi dan perangkat yang terdaftar. Jika kredensial telah kedaluwarsa, dicabut, terkait dengan identitas yang salah, atau terinstal dengan cara yang salah, permintaan dapat gagal sebelum pengiriman dimulai.
Apple menyatakan bahwa APNs memelihara daftar sertifikat yang dicabut dan menolak koneksi TLS dari server yang menggunakan sertifikat di daftar tersebut. Hal ini membuat kebersihan sertifikat menjadi kebutuhan pengiriman, bukan preferensi administratif. Server mungkin dapat melanjutkan pengolahan pekerjaan notifikasi secara lokal, sementara Apple menolak koneksi penyedia.
Mengisolasi Push Aplikasi dari Push MDM
Pertanyaan diagnostik pertama adalah sederhana: Apakah layanan yang Anda coba operasikan?
| Jalur Kredensial | Apa yang dilakukan | Pemilik biasa |
|---|---|---|
| Push Aplikasi | Mengirimkan peringatan dan pemberitahuan aplikasi lainnya ke perangkat pengguna akhir | Ingenieris mobile atau backend |
| Push MDM | Mengizinkan platform manajemen perangkat untuk berkomunikasi dengan perangkat Apple yang diatur | Administrasi IT, endpoint, atau mobilitas perangkat |
Kredensial-kredensial ini tidak dapat diganti-gantikan. Platform MDM dapat kehilangan kontak dengan perangkat yang terdaftar ketika kredensial push MDM-nya telah kedaluwarsa, sementara backend aplikasi dapat kehilangan pengiriman pemberitahuan karena kredensial App Push-nya tidak valid. Menganggap kedua-duanya sebagai masalah “sertifikat push Apple” yang sama akan mengarahkan troubleshooting ke arah yang salah.
Untuk Capacitor dan tim Ionic, jalur yang relevan untuk peringatan pengguna adalah secara umum Push AplikasiAplikasi masih memerlukan kemampuan Push Notifications, tanda tangan yang benar, pendaftaran perangkat, dan backend yang mengirimkan melalui lingkungan APNs yang tepat. Jika tim Anda juga mengirimkan aset web secara daring, jaga alur rilis tersebut terpisah dari autentikasi push. Capacitor plugin dokumentasi notifikasi Mengcover integrasi sisi aplikasi, sementara kredit APNs masuk dalam konfigurasi penyedia.
Mulai dengan penolakan, bukan UI
Pertama-tama, periksa respons APNs dari server penyedia Anda sebelum mengubah salinan notifikasi atau membangun kembali aplikasi. Lalu, verifikasi identifikasi paket, identitas kredit, lingkungan, dan status sertifikat. Masalah izin notifikasi mempengaruhi kemampuan pengguna untuk melihat peringatan, tetapi tidak menjelaskan penolakan TLS dari APNs.
Jika gagal muncul setelah rilis, bandingkan tanda tangan dan hak istimewa dalam build baru dengan build sebelumnya. Jika muncul tanpa perubahan aplikasi, periksa kedaluwarsa sertifikat, revokasi, perubahan trust-store, dan rahasia pengembangan terlebih dahulu. Untuk jalur implementasi yang lebih luas, lihat panduan ini untuk Pengaturan notifikasi push Expo.
Membuat dan Mengunduh Sertifikat APNs Anda
Sebuah peluncuran push dapat gagal sebelum notifikasi pertama dikirim jika sertifikat diterbitkan untuk ID Aplikasi yang salah atau kunci pribadi tetap di Mac lain. Alur kerja Apple memiliki dua bagian: mesin Anda membuat Permintaan Tanda Tangan Sertifikat, atau CSR, dan Apple menandatanganinya untuk ID Aplikasi yang dipilih. CSR bukanlah kredit server. Ini menghubungkan sertifikat yang diterbitkan ke kunci pribadi yang dibuat secara lokal.
Siapkan ID Aplikasi
Masuk ke portal Pengembang Apple dan buka Surat, Identifikasi & Profil. Pilih Identifikasi, pilih identifikasi paket aplikasi, dan buka konfigurasi aplikasinya. Pastikan bahwa Pemberitahuan Push context: Halaman/area: Situs web pemasaran Capgo. Peran: Label UI singkat atau item navigasi. Kunci pesan `push_notifications` (Pemberitahuan Push).
diaktifkan sebelum mengeluarkan apa pun.
Kredensial APNs terkait dengan identitas aplikasi. Jangan memilih identifikasi paket aplikasi yang dekat dengan nama yang mirip. Konfigurasi aplikasi terpisah secara independen dan keluarkan kredensial yang sesuai. Pada Mac yang akan menyimpan kunci, buka Akses Kunci
Komputer monitor yang menampilkan antarmuka perintah baris Linux yang digunakan untuk menghasilkan sertifikat SSL.
Ini SertifikatPilih opsi sertifikat layanan pemberitahuan push Apple. Pilih ID Aplikasi, unggah CSR, dan kirimkan permintaan. Unduh sertifikat yang dikeluarkan oleh Apple.
Dengan mengeklik dua kali file yang diunduh di Mac yang memiliki kunci pribadi, sertifikat tersebut harus terinstal di Akses Kuncidi mana Anda dapat memverifikasi sertifikat dan kunci pribadi yang sesuai. Sertifikat yang diimpor tanpa kunci tersebut tidak dapat menyediakan kredensial lengkap yang dibutuhkan backend Anda.
Pilih konvensi nama yang merekam identitas aplikasi, lingkungan, pemilik, dan detail kedaluwarsa. Simpan sertifikat asli, informasi kepemilikan CSR, dan detail akun portal di sistem kredensial tim Anda. Folder Download seorang pengembang atau laptop pribadi bukanlah cadangan operasional.
Sertifikat tersebut hanya mendukung satu bagian pengiriman. Aplikasi harus mendaftar untuk pemberitahuan jarak jauh, server harus menyimpan token perangkat yang dihasilkan, dan penyedia harus mengirimkan dengan topik dan lingkungan yang sesuai. Simpan ketergantungan tersebut di dalam buku catatan yang sama. Untuk pengaturan sisi klien, lihat panduan integrasi pemberitahuan Capacitor notifications integration guideMenyimpan Sertifikat ke Kunci Pribadi
__CAPGO_KEEP_0__
A sertifikat Apple yang diunduh tidak otomatis siap digunakan untuk layanan Node.js atau penyedia push yang diatur. Server memerlukan sertifikat dan kunci pribadi yang sesuai, biasanya dikemas sebagai sebuah PKCS#12 .p12 file.
Buka Akses Kunci pada Mac tempat Anda menginstal sertifikat. Cari sertifikat APNs, ekspandir atau periksa, dan cari kunci pribadi dengan informasi identitas dan kadaluarsa yang sesuai. Pilih sertifikat dan kunci pribadi bersamaan, kemudian gunakan aksi ekspor untuk menyimpan sebuah .p12 file.
Validasi bundle sebelum pengembangan
Berikan nama sandi yang kuat untuk ekspor. Nama sandi melindungi kunci pribadi di dalam bundle, jadi jangan tempatkan di dalam repositori, tiket, pesan obrolan, atau log pembangunan. Unggah file dan nama sandi melalui sistem manajemen rahasia, kemudian berikan akses hanya kepada layanan yang mengirimkan notifikasi.
Hukum praktis: A
.p12file tanpa kunci pribadi yang sesuai bukanlah kredential penyedia yang lengkap.
Sebelum digunakan dalam produksi, uji bundle di lingkungan yang terkendali. Pastikan backend Anda dapat memuat file, mengatur koneksi APNs, dan mengembalikan kesalahan yang terstruktur ketika Apple menolak permintaan. Jika penyedia seperti Capgo meminta kredential push iOS, unggah file dan kata sandi melalui konfigurasi rahasia yang ditentukan, bukan menyematkannya ke dalam aplikasi Capgo. .p12 dan kata sandinya melalui konfigurasi rahasia yang ditentukan, bukan menyematkannya ke dalam aplikasi code.
Format ini juga mengekspos kelemahan alur kerja legacy. Anda harus menyimpan kunci pribadi asli, mengulangi ekspor manual, melindungi file, dan mengganti rahasia pengembangan pada waktu perpanjangan. Tim yang mengoperasikan beberapa aplikasi dapat dengan mudah kehilangan track mana bundle yang dimiliki oleh mana ID Aplikasi.
Pilih manajemen rahasia yang aman dalam alur kerja CI/CD untuk mengontrol siapa yang dapat membaca atau mengganti kredential. Simpan jejak audit untuk unggahan dan rotasi, tetapi tidak pernah log kunci pribadi atau kata sandi. .p12 Untuk pekerjaan backend baru, evaluasi apakah autentikasi sertifikat masih relevan. Integrasi yang sudah ada mungkin memerlukan
tetapi autentikasi token biasanya menghilangkan penggantian sertifikat tahunan dari koneksi penyedia. Itu tidak menghilangkan pengelolaan kredential. Hanya mengubah apa yang dilindungi dan dirotasi. .p12Migrasi ke Autentikasi Berbasis Token Baru
Apple telah bergerak APNs autentikasi ke
token penyedia Migrasi ke Autentikasi Berbasis Token Barubiasanya disebut sebagai alur p8. Sebaliknya dari menampilkan sertifikat dan kunci pribadi untuk identitas TLS yang berumur panjang, penyedia Anda menandatangani token autentikasi dengan Kunci Pengesahan Layanan Pemberitahuan Push Apple.
Buatlah kunci di portal Pengembang Apple di bawah Sertifikat, Identifikasi & Profil, kemudian buka Kunci dan mendaftarkan kunci autentikasi APNs. Unduh file dan catat ID Kunci dan ID Tim di penyimpanan rahasia Anda. Tatalah file yang diunduh sebagai rahasia tanda tangan yang berharga. .p8 Lakukan migrasi dengan sengaja
Tidak ganti lalu lintas produksi dengan mengganti file di lingkungan yang belum teruji. Bangun autentikasi token di samping jalur sertifikat yang ada, validasi perilaku sandbox dan produksi, dan bandingkan respons APNs. Kemudian ubah konfigurasi penyedia selama proses pengembangan yang terkendali.
Migrasi menghilangkan langkah perpanjangan sertifikat dan ekspor Keychain dari jalur pengiriman, tetapi tim Anda masih membutuhkan model kepemilikan yang jelas. Putuskan siapa yang dapat membuat, membatalkan, dan mengaktifkan kunci. Batasi akses ke layanan backend yang menandatangani token penyedia, dan pastikan proses pengganti darurat ada sebelum kunci saat ini tidak tersedia.
alur p8
Untuk sebuah aplikasi Capacitor, klien masih membutuhkan pendaftaran dan hak akses notifikasi yang benar. Migrasi utamanya mengubah autentikasi server ke APNsbukan pendaftaran token perangkat code. Backend Anda harus terus menghubungkan token dengan aplikasi dan lingkungan yang benar.
Tahu kapan sertifikat masih diperlukan
Beberapa alat perusahaan dan integrasi yang sudah ada masih menampilkan konfigurasi berbasis sertifikat. Jangan paksa migrasi p8 sampai sistem penerima mendukungnya dan tim Anda telah menguji jalur lengkap. Simpan kredit warisan yang dilindungi selama transisi, tetapi jangan membuat ketergantungan baru pada itu ketika autentikasi token sesuai.
Jika Anda perlu memahami aliran aplikasi yang lebih luas, ulangi Ionic dan Capacitor notifikasi push dengan Firebase. Firebase dapat menyediakan lapisan pengiriman aplikasi, tetapi kredit Apple, hak akses, pendaftaran, dan respons APNs masih memerlukan konfigurasi yang sengaja.
Mengurus dan Mengganti Siklus Hidup Sertifikat
Tangani sertifikat APNs sebagai dependensi produksi yang berakhir dari hari Anda membuatnya. Apple mengatakan bahwa sertifikat ini berlaku selama satu tahun dari pembuatan dan harus diperbarui sebelum kedaluwarsa untuk menjaga komunikasi perangkat. Apple juga mengingatkan bahwa gagal untuk diperbarui dapat memaksa pengguna untuk mendaftar ulang perangkat iOS, iPadOS, dan Mac dengan APNs dan dapat menyebabkan gangguan layanan. Lihat dokumentasi pembaruan sertifikat push notification Apple’s dokumentasi pembaruan sertifikat push notification Apple.
Jalur pembaruan sangat tepat:
- Generate a new CSR: Buat permintaan melalui alur kerja yang disetujui dan simpan bahan kunci terkait.
- Gunakan ID Apple asli: Masuk dengan ID Apple yang sama yang digunakan untuk membuat sertifikat yang ada.
- Pilih sertifikat yang akan berakhir: Match App ID, Subject DN, UID, dan detail kedaluwarsa sebelum memilih Pembarui.
- Upload CSR: Kirim permintaan baru di Portal Sertifikat Push Apple.
- Unduh dan reinstall: Mengambil kembali yang telah diperbarui
.pem, instalnya di tempat kunci privat tersedia, dan ekspor pengganti.p12jika penyedia memerlukan. - Deploy dan test: Update rahasia server, kirim notifikasi yang dikontrol, dan periksa respons APNs.
Bandingkan format penyedia
| Persyaratan | Alur sertifikat | Alur token |
|---|---|---|
| Rahasia utama | Sertifikat plus kunci privat | .p8 Kunci Autentikasi |
| Kesulitan Perpanjangan | Sertifikat kadaluarsa memerlukan penggantian berulang | Tidak ada penggantian sertifikat tahunan |
| Kerja pengembangan | Pasang, pair, ekspor, dan unggah | Simpan kunci tanda tangan dan konfigurasi generasi token |
| Risiko gagal utama | Sertifikat salah, kunci pribadi hilang, kadaluarsa, atau dicabut | Kunci autentikasi hilang, terbuka, atau dicabut |
Ekosistem sertifikat Apple juga telah memerlukan pekerjaan rantai kepercayaan yang dijadwalkan. Apple mengumumkan update sertifikat server APNs untuk sandbox pada 20 Januari 2025 dan produksi pada 24 Februari 2025, memerlukan penyimpanan kepercayaan untuk mencakup sertifikat SHA-2 Root USERTrust RSA Certification Authority baca pengumuman sertifikat server APNs Apple dan pastikan kepemilikan penyimpanan kepercayaan menjadi bagian dari daftar checklist platform Anda. Gunakan kalender perpanjangan bersama, pemilik yang ditetapkan, dan buku aksi pengembangan. Dokumentasi manajemen sertifikat __CAPGO_KEEP_0__ dapat berdiri di samping buku aksi tersebut untuk tim yang mengelola kredit iOS dengan proses rilis mobile mereka.
Pengaturan dan Penanganan Kredensial Hilang Capgo certificate management documentation Pengaturan dan Penanganan Kredensial Hilang
Insiden sulit bukan selalu peringatan kedaluwarsa. Itu pagi ketika administrator yang menciptakan sertifikat telah pergi, kunci pribadi hanya ada di Mac lama, atau sertifikat dicabut selama upaya pembersihan. Aliran perpanjangan standar bergantung pada ID Apple asli dan identitas sertifikat yang benar, sehingga akses dan asal-usulnya sangat penting sekaligus dengan file itu sendiri.
Pengaturan dan Penanganan Kredensial Hilang
Mulai dengan mengklasifikasikan gagalnya:
- Sertifikat telah kedaluwarsa: Buat pengganti melalui akun asli, pasang kembali dengan kunci privat yang sesuai, update penyedia, dan tes pengiriman. Jika komunikasi perangkat telah terganggu, ikuti panduan pemulihan Apple daripada menganggap pengganti server-side secara instan memulihkan setiap perangkat.
- Sertifikat telah dicabut: Hentikan menganggap kredential lama sebagai dapat dipulihkan. Apple menolak koneksi TLS dari server yang menggunakan sertifikat yang dicabut, jadi buat pengganti yang valid dan hapus rahasia yang dicabut dari penggunaan aktif. Periksa siapa yang mencabutnya dan apakah sistem lain telah menyalin kredential yang sama.
- Sertifikat hilang
.p12Kata sandi: File sertifikat tanpa kata sandi yang dapat digunakan mungkin tidak dapat digunakan secara operasional. Ambil cadangan yang disetujui atau buat pengganti daripada melemahkan kontrol rahasia produksi. - Kunci privat hilang: Mengunduh kembali sertifikat publik tidak akan menciptakan kunci privat. Buat CSR baru pada mesin yang dikendalikan dan buat pengganti kredential.
- Akses ID Apple hilang: Konfirmasikan apakah organisasi dapat memulihkan akun melalui proses identitas dan penggunaan deployment. Apple mengarahkan dukungan untuk sertifikat APNs yang dibuat melalui portal yang relevan ke Programs Pengembangan Support.
Recovery memerlukan identitas, bukan hanya nama file. Catat ID Apple pemilik, ID Aplikasi, identitas sertifikat, lokasi kunci pribadi, konfigurasi penyedia, dan prosedur penggantian sebelum kejadian terjadi.
Bangun jaringan keamanan operasional
Simpan sertifikat dan .p8 kunci di sebuah vault bersama yang dikontrol akses. Simpan kata sandi terpisah dari file, batasi akses produksi, dan dokumentasikan akun portal yang tepat untuk perpanjangan waktu. Sistem CI/CD Anda harus menginjeksi rahasia pada saat pengembangan dan menjalankan pengecekan kesehatan yang mendeteksi gagal autentikasi sebelum pengguna melaporkan notifikasi hilang. .p12 Tahan kunci lama tersedia selama penggantian yang dikendalikan ketika platform memungkinkannya, tetapi jangan biarkan rahasia yang usang aktif secara tidak terbatas. Uji penggantian di jalur backend yang sama yang digunakan produksi, termasuk lingkungan penyedia, identifikasi paket, dan penyimpanan token perangkat.
Ketika kegagalan telah terjadi, simpan tubuh respons APNs dan tanggal, identifikasi permintaan yang ditolak pertama, dan bandingkan rahasia pengembangan sebelum dan setelah kejadian. Jangan ulangi secara tidak terbatas terhadap kunci yang tidak valid. Perbaiki identitas atau masalah autentikasi terlebih dahulu, lalu kirim notifikasi verifikasi kecil ke perangkat uji yang diketahui.
__CAPGO_KEEP_0__ dapat menyimpan dan mengonfigurasi kunci push iOS sebagai bagian dari alur notifikasi __CAPGO_KEEP_1__ , sementara tim Anda tetap bertanggung jawab atas akses akun Apple, kunci rahasia, dan keputusan perpanjangan waktu. Kunjungi
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 untuk meninjau bagaimana alat pengiriman mobilenya dapat disesuaikan dengan siklus kredensial APNs dan proses rilis Anda.
