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 kali 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 menciptakan sertifikat lain. Anda perlu memahami kredential APNs yang digunakan oleh sistem Anda, melestarikan kunci privat, merencanakan perpanjangan, 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
- Memperbarui 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, dibatalkan, terkait dengan identitas yang salah, atau terinstal dengan cara yang salah, permintaan dapat gagal sebelum pengiriman dimulai.
Apple menyatakan bahwa APNs mempertahankan daftar sertifikat yang dibatalkan dan menolak koneksi TLS dari server yang menggunakan sertifikat pada 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.
Memisahkan Push Aplikasi dari Push MDM
Pertanyaan diagnostik pertama adalah sederhana: Apakah layanan yang Anda coba operasikan?
| Jalur Kredensial | Apa yang dilakukannya | Pemilik biasa |
|---|---|---|
| Push Aplikasi | Mengirimkan peringatan dan pemberitahuan aplikasi lainnya ke perangkat pengguna akhir | Ingenieris mobile atau backend |
| Push MDM | Mengizinkan platform pengelolaan perangkat untuk berkomunikasi dengan perangkat Apple yang diatur | Administrasi IT, endpoint, atau mobilitas perusahaan |
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 tim Capacitor dan Ionic, jalur yang relevan untuk peringatan pengguna biasanya adalah Push AplikasiAplikasi masih memerlukan kemampuan Push Notifications, penandatanganan yang benar, pendaftaran perangkat, dan backend yang mengirimkan melalui lingkungan APNs yang tepat. Jika tim Anda juga mengirimkan aset web melalui jaringan, jangan campuradukkan alur rilis push dengan autentikasi. Capacitor plugin dokumentasi notifikasi Mengcover integrasi sisi aplikasi, sementara kredit APNs masuk dalam konfigurasi penyedia.
Mulai dengan penolakan, bukan UI
Periksa respons APNs dari server penyedia Anda sebelum mengubah salinan notifikasi atau membangun kembali aplikasi. Kemudian 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 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 Pertanyaan 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 Sertifikat, Identifikasi & Profil. Pilih Identifikasi, pilih identifikasi paket aplikasi, dan buka konfigurasi aplikasinya. Pastikan bahwa Pemberitahuan Push telah diaktifkan sebelum mengeluarkan apa pun.
Kredensial APNs terkait dengan identitas aplikasi. Jangan memilih identifikasi paket aplikasi yang mirip dengan nama lain. Konfigurasi aplikasi terpisah secara independen dan keluarkan kredensial yang sesuai.
Buka Akses Kunci pada komputer yang akan menyimpan kunci tersebut, dan buat CSR, atau gunakan alat sertifikasi yang disetujui oleh organisasi Anda. Simpan file permintaan dan kunci pribadi di bawah kontrol kepemilikan yang sama. Jika administrator lain yang membuat CSR, administrator tersebut mungkin akan menyimpan kunci pribadi yang diperlukan nanti untuk membuat bundle server yang dapat digunakan.
Keluarkan sertifikat yang telah ditandatangani
Ini SertifikatPilih opsi sertifikat layanan pemberitahuan push Apple. Pilih ID Aplikasi, unggah CSR, dan kirimkan permintaan. Unduh sertifikat yang dikeluarkan oleh Apple.
Dengan mengeklik ganda file yang diunduh di Mac yang memiliki kunci pribadi. File tersebut harus terinstal di Akses Kunci, di 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 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 membutuhkan 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, ekspansi atau periksa, dan cari kunci pribadi dengan informasi identitas dan kadaluarsa yang sesuai. Pilih sertifikat dan kunci pribadi bersamaan, kemudian gunakan aksi export untuk menyimpan sebuah .p12 file.
Validasi bundle sebelum pengembangan
Berikan nama sandi yang kuat untuk export. Nama sandi melindungi kunci pribadi di dalam bundle, jadi jangan tempatkan di repository, tiket, pesan obrolan, atau log pembangunan. Unggah file dan nama sandi melalui sistem manajemen rahasia, kemudian berikan akses hanya kepada layanan yang mengirimkan notifikasi.
Hal praktis: A
.p12file tanpa kunci pribadi yang sesuai bukanlah kredit penyedia yang lengkap.
Sebelum digunakan dalam produksi, tes 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 nilai Capgo dan kata sandinya melalui konfigurasi rahasia yang ditentukan bukan mengembangkannya ke dalam aplikasi Capgo. .p12 and its password through the designated secret configuration rather than embedding either value in application 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 pengelolaan rahasia yang aman dalam alur 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 diganti. .p12Migrasi ke Autentikasi Berbasis Token Baru
Apple telah bergerak APNs autentikasi ke
token penyedia __CAPGO_KEEP_0__biasanya disebut sebagai alur p8. Sebaliknya dari menampilkan sertifikat dan kunci pribadi untuk identitas TLS yang berumur panjang, penyedia Anda menandatangani token autentikasi dengan Kunci Autentikasi 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 tersebut dan catat ID Kunci dan ID Tim di penyimpanan rahasia Anda. Tatalah file yang diunduh sebagai rahasia tanda tangan yang berharga. .p8 Lakukan migrasi secara sengaja
Tidak gantikan lalu lintas produksi dengan mengganti file di lingkungan yang belum diuji. 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 mengembangkan kunci. Batasi akses ke layanan backend yang menandatangani token penyedia, dan pastikan proses penggantian 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 APNs, bukan 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 kreditur legasi dilindungi selama transisi, tetapi jangan membuat ketergantungan baru pada itu ketika autentikasi token cocok.
Jika Anda perlu memahami aliran aplikasi yang lebih luas, tinjau Ionic dan Capacitor notifikasi push dengan Firebase. Firebase dapat menyediakan layer pengiriman aplikasi, tetapi kredit Apple, hak akses, pendaftaran, dan respons APNs masih memerlukan konfigurasi yang sengaja.
Mengurus 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 memerlukan pengguna untuk mendaftar ulang perangkat iOS, iPadOS, dan Mac dengan APNs dan dapat menyebabkan gangguan layanan. Lihat dokumentasi pembaruan sertifikat push Apple dokumentasi pembaruan sertifikat push 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 kedaluwarsa: 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: Mendapatkan yang diperbarui
.pem, instalnya di tempat kunci pribadi tersedia, dan ekspor pengganti.p12jika penyedia memerlukan. - Deploy dan tes: Update rahasia server, kirim notifikasi yang dikendalikan, dan periksa respons APNs.
Bandingkan format penyedia
| Persyaratan | Alur sertifikat | Alur token |
|---|---|---|
| Rahasia utama | Sertifikat plus kunci pribadi | .p8 Kunci Autentikasi |
| Kesadaran Perpanjangan | Perlu penggantian sertifikat yang berulang karena kedaluwarsa | Tidak ada penggantian sertifikat tahunan |
| Kerja pengembangan | Pasang, pair, ekspor, dan unggah | Simpan kunci tanda tangan dan atur penghasilan token |
| Risiko utama gagal | Kunci sertifikat salah, kunci pribadi hilang, kedaluwarsa, atau dicabut | Kunci autentikasi hilang, terbuka, atau dicabut |
Sistem ekosistem sertifikat Apple juga telah memerlukan pekerjaan rantai kepercayaan yang terjadwal. Apple mengumumkan update sertifikat server APNs untuk sandbox pada tanggal 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 ditunjuk, dan buku catatan peluncuran. Dokumentasi manajemen sertifikat
__CAPGO_KEEP_0__ Capgo certificate management documentation Pengaturan dan Penanganan Kredensial Hilang
Insiden sulit bukan selalu peringatan kadaluarsa. 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 seperti file itu sendiri.
Pengaturan dan Penanganan Kredensial Hilang
Mulai dengan mengklasifikasikan kegagalan:
- 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 dapat memulihkan setiap perangkat secara instan.
- Sertifikat telah dicabut: Hentikan menganggap kredential lama 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 di mesin yang dikendalikan dan buat pengganti kredential.
- Akses ID Apple hilang: Konfirmasi apakah organisasi dapat memulihkan akun melalui proses identitas dan penggunaan deployment. Apple mengarahkan dukungan untuk sertifikat APNs yang dibuat melalui portal yang relevan ke Program Bantuan Penggunaan.
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 dalam 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 proses pengiriman dan menjalankan pengecekan kesehatan yang mendeteksi gagal autentikasi sebelum pengguna melaporkan peringatan yang hilang. .p12 Simpan 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 kali, dan bandingkan rahasia pengiriman sebelum dan setelah kejadian. Jangan ulangi secara tidak terbatas terhadap kunci yang tidak valid. Perbaiki identitas atau masalah autentikasi terlebih dahulu, lalu kirimkan peringatan verifikasi kecil ke perangkat uji yang diketahui.
__CAPGO_KEEP_0__ dapat menyimpan dan mengonfigurasi kredential push iOS sebagai bagian dari __CAPGO_KEEP_1__ alur kerja notifikasi, 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 perangkat selulernya dapat disesuaikan dengan siklus kredensial APNs dan proses rilis Anda.
