Berikut Cara Mengelola Sertifikat Layanan Pemberitahuan Push Apple

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 menguntungkan. Rilis keluar, kampanye dijadwalkan, dan pengiriman pemberitahuan tiba-tiba menjadi sunyi. Server aplikasi Anda mungkin masih menerima pekerjaan, tetapi APNs dapat menolak koneksi TLS sebelum pesan mencapai perangkat. Solusi praktis bukan hanya menciptakan sertifikat lain. Anda perlu memahami kredential APNs mana yang digunakan sistem Anda, melestarikan kunci pribadi, merencanakan perpanjangan, dan memindahkan beban kerja yang sesuai ke autentikasi berbasis token.

Daftar Isi

• Mengapa Notifikasi Push Berhenti Berfungsi
  • Jalankan Push Aplikasi Terpisah dari Push MDM
  • Mulai dari Penolakan, Bukan UI
• Membuat dan Mengunduh Sertifikat APNs
  • Siapkan ID Aplikasi
  • Issu Sertifikat yang Ditandatangani
• Mengexport Sertifikat ke Kunci Pribadi
  • Validasi Paket Sebelum Pengembangan
• Migrasi ke Autentikasi Berbasis Token Baru
  • Lakukan Migrasi dengan Sengaja
  • Pahami Kapan Sertifikat Masih Diperlukan
• Memperbarui dan Mengelola Siklus Sertifikat
  • Menggambarkan Format Penyedia
• Mengatasi Masalah dan Mengelola Kredensial Hilang
  • Membangun Jaringan Keselamatan Operasional

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 salah, permintaan dapat gagal sebelum pengiriman dimulai.

Apple menyatakan bahwa APNs mempertahankan 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 terus memproses 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?

Kredensial ini tidak dapat diganti-gantikan. Platform MDM dapat kehilangan kontak dengan perangkat yang terdaftar ketika kredential push MDM-nya telah kedaluwarsa, sementara backend aplikasi dapat kehilangan pengiriman pemberitahuan karena kredential App Push-nya tidak valid. Menganggap kedua hal 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 biasanya adalah 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 melalui jaringan, pastikan 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

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 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 pada 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 Surat, Pengenal, & Profil. Pilih Pengenal, pilih pengenal aplikasi bundle, dan buka konfigurasi aplikasinya. Pastikan bahwa Pemberitahuan Push context: Halaman/area: Situs web pemasaran Capgo. Peran: Label UI pendek atau item navigasi. Kunci pesan `push_notifications` (Pemberitahuan Push).

diaktifkan sebelum mengeluarkan apa pun.

Kredensial APNs terkait dengan identitas aplikasi. Jangan memilih pengenal bundle yang dekat dengan nama yang mirip. Konfigurasi aplikasi terpisah secara independen dan keluarkan kredential yang sesuai. On the Mac yang akan mempertahankan kunci, buka Akses Kunci

Komputer monitor 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 kirim permintaan. Unduh sertifikat yang dikeluarkan oleh Apple.

Geser dua kali 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 kredit lengkap yang dibutuhkan backend Anda.

Pilih konvensi penamaan yang merekam identitas aplikasi, lingkungan, pemilik, dan detail kedaluwarsa. Simpan sertifikat asli, informasi kepemilikan CSR, dan detail akun portal di sistem kredit 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 hasilnya, dan penyedia harus mengirimkan dengan topik dan lingkungan yang sesuai. Simpan ketergantungan tersebut di 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 untuk layanan Node.js atau penyedia push yang diatur. Server memerlukan sertifikat dan kunci pribadi yang sesuai, biasanya dikemas sebagai file PKCS#12 .p12 file.

Buka Akses Kunci pada Mac tempat Anda menginstal sertifikat. Cari sertifikat APNs, ekspansi atau periksa, dan cari kunci pribadi yang sesuai dengan identitas dan informasi kedaluwarsa. Pilih sertifikat dan kunci pribadi bersamaan, kemudian gunakan aksi ekspor untuk menyimpan file. .p12 Validasi bundle sebelum pengembangan

Berikan nama sandi yang kuat. Nama sandi melindungi kunci pribadi di dalam bundle, jadi jangan tempatkan di 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.

Aturan praktis:

Sertifikat tanpa kunci pribadi yang sesuai bukanlah kredential penyedia yang lengkap. A file without its matching private key is not a complete provider credential. .p12 Practical rule:

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 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 yang sudah usang. 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 di Pipa 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 ke arah autentikasi APNs yang berbasis

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 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 dan catat ID Kunci dan ID Tim di penyimpanan rahasia Anda. Tatalaksana file yang diunduh sebagai rahasia penandatanganan yang berharga. .p8 Lakukan migrasi dengan sengaja

Tidak ganti 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 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 memaksakan 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 sesuai.

Jika Anda membutuhkan memahami aliran aplikasi yang terkait, tinjau Ionic dan Capacitor notifikasi push dengan Firebase. Firebase dapat menyediakan layer pengiriman aplikasi, tetapi kredential 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 memperbarui dapat memerlukan pengguna untuk mendaftar ulang perangkat iOS, iPadOS, dan Mac dengan APNs dan dapat menyebabkan gangguan layanan. Lihat dokumentasi pembaruan sertifikat push Apple’s dokumentasi pembaruan sertifikat push Apple.

Jalur pembaruan sangat tepat:

1. Generate a new CSR: Buat permintaan melalui alur kerja yang disetujui dan simpan material kunci yang terkait.
2. Gunakan ID Apple asli: Masuk dengan ID Apple yang sama yang digunakan untuk membuat sertifikat yang ada.
3. Pilih sertifikat yang akan kedaluwarsa: Match App ID, Subject DN, UID, dan detail kedaluwarsa sebelum memilih Pilih Pembarui.
4. Upload CSR: Kirim permintaan baru di Portal Sertifikat Push Apple.
5. Unduh dan reinstall: Mendapatkan yang diperbarui .pem, instalnya di tempat kunci pribadi tersedia, dan ekspor pengganti .p12 jika penyedia memerlukan.
6. Deploy dan tes: Update rahasia server, kirim notifikasi terkendali, dan periksa respons APNs.

Bandingkan format penyedia

Sistem ekosistem sertifikat Apple juga telah memerlukan pekerjaan rantai kepercayaan yang dijadwalkan. 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__ dapat berdiri di samping buku catatan peluncuran 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 privat 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 gagalnya:

• Surat sertifikat telah kedaluwarsa: Generate 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 langsung 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.
• Terlupakan .p12 Kata sandi: File sertifikat tanpa kata sandi yang dapat digunakan mungkin tidak dapat digunakan secara operasional. Ambil cadangan yang disetujui atau buat pengganti lainnya daripada melemahkan kontrol rahasia produksi.
• Terlupakan kunci privat: Mengunduh kembali sertifikat publik tidak akan menciptakan kunci privat. Buat CSR baru pada 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 Programs Support Deployemen.

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 keselamatan operasional

Simpan sertifikat dan .p8 kunci di sebuah peti simpan 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 waktu pengiriman dan jalankan periksa kesehatan yang mendeteksi gagal autentikasi sebelum pengguna melaporkan notifikasi hilang. .p12 Tahan kunci lama 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, identifier paket, dan penyimpanan token perangkat.

Ketika kegagalan telah terjadi, simpan tubuh respons APNs dan timestamps, identifikasi permintaan yang ditolak pertama, 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 kirim notifikasi verifikasi kecil ke perangkat uji yang diketahui.

__CAPGO_KEEP_0__ dapat menyimpan dan mengonfigurasi kunci push iOS sebagai bagian dari __CAPGO_KEEP_1__ alur 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 mobilenya dapat disesuaikan dengan siklus kredensial APNs dan proses rilis Anda.