Alat pengembang · Encoder & decoder Base64
PEM menjelaskan: mengapa sertifikat dan kunci adalah Base64 antara BEGIN dan END
· Latar belakang
base64 pengkodean
File PEM adalah biner DER yang dibungkus dalam Base64 dengan garis pelindung berlabel. Posting ini menjelaskan asal-usul format, aturan garisnya, dan apa yang bisa dan tidak bisa Anda pelajari dengan mendekode format tersebut.
Sertifikat yang 'terlihat seperti teks' tetapi gagal diurai — kesalahan ketik header, pengembalian yang menyimpang, dan format di bawahnya
File PEM adalah biner berkode Base64 yang dibungkus dengan label teks. Nama ini berasal dari Privacy-Enhanced Mail (RFC 1421, 1992), yang menggunakan format ini untuk pesan terenkripsi. Format ini bertahan hingga saat ini dalam sertifikat TLS, kunci SSH, dan kunci GPG. Strukturnya sederhana: baris yang mengatakan -----BEGIN CERTIFICATE----- (atau BEGIN PRIVATE KEY, BEGIN PUBLIC KEY, dll.), diikuti oleh 64-baris karakter teks base64, diikuti oleh -----END CERTIFICATE-----.
Badan base64 mendekode ke format biner yang disebut DER (Aturan Pengkodean Terhormat), yang merupakan cara untuk membuat serial data terstruktur (khususnya, struktur ASN.1). Mendekode base64 memberi Anda biner; membaca biner memerlukan pemahaman ASN.1, yang rumit. Armor PEM ada karena file biner sulit dikirim melalui email dan diedit. File sertifikat dalam bentuk biner murni akan rusak ketika melewati sistem email lama, USENET, atau formulir web.
Pelindung teks terlihat di blok PEM — memberi label di sekitar badan Base64
Dengan mengkodekan biner base64 dan membungkusnya dalam label teks, seluruh sertifikat menjadi teks 7-bit ASCII yang bertahan dalam pengangkutan apa pun. Editor teks dapat membukanya; sistem email tidak akan merusaknya. Garis -----BEGIN dan -----END adalah label untuk manusia dan alat otomatis; mereka dengan jelas menandai jenis data apa yang ada di dalamnya. Sertifikat diberi label CERTIFICATE; kunci pribadi diberi label PRIVATE KEY.
Label tersebut tidak diverifikasi oleh perangkat lunak kriptografi; itu hanyalah petunjuk bagi manusia dan peralatan. Batas baris 64 karakter di PEM berasal dari RFC 1421 dan alasan MIME yang sama dengan basis email64: sistem email lama memiliki batas panjang baris, dan 64 karakter muat di terminal tahun 1980an. PEM membungkus output base64 pada 64 karakter dengan akhiran baris (CR LF di Windows, LF di Unix).
Dari teks berlabel hingga byte yang didekodekan — repositori ini tidak membuat riwayat format
Saat mendekode sertifikat PEM, parser harus menghapus garis pelindung (-----BEGIN..., -----END...) dan garis terputus, lalu mendekode base64 sisanya. Pengembalian media yang menyimpang atau label yang tidak cocok dapat merusak penguraian. Pembungkusan garis bukan bagian dari standar base64 (RFC 4648 base64 tidak dibungkus); ini khusus untuk PEM. Di dalam base64 terdapat biner berkode DER. DER adalah ASN.1 (Notasi Sintaks Abstrak), spesifikasi kompleks untuk merepresentasikan struktur data.
Sertifikat adalah catatan terstruktur yang berisi nama subjek, kunci publik, tanda tangan, dan metadata. ASN.1 tidak mendeskripsikan byte secara langsung; ini menjelaskan bagaimana struktur harus dikodekan.
Anatomi blok sebagai masukan ke alat ini — hapus label dan teruskan hanya isi Base64
Pengkodean dimulai dengan triplet tag-length-value. Misalnya, SEQUENCE di ASN.1 dikodekan sebagai tag 0x30, diikuti dengan panjang konten, diikuti dengan konten itu sendiri. Sertifikat selalu dimulai dengan byte 0x30 0x82 (urutan, panjang dikodekan dalam dua byte), yang muncul sebagai MII di base64.
Memeriksa sertifikat tanpa menguraikannya: tiga karakter pertama dari badan sertifikat PEM hampir selalu MII (yaitu 0x30 0x82 di base64, awal dari SEQUENCE). Jika blok PEM tidak didekodekan menjadi 0x30, base64 rusak atau labelnya salah. Alat encoder & decoder Base64 dapat memecahkan kode isi dan menampilkan hex: tempelkan garis base64 (tanpa pelindung -----BEGIN dan END), hapus jeda baris, dan dekode.
Apa yang diungkapkan oleh penguraian kode: byte biner, bukan bidang sertifikat yang diurai
Jika keluarannya berupa biner yang dimulai dengan 30 82, kemungkinan besar itu adalah struktur sertifikat yang valid. Jika itu omong kosong atau teks, dekode gagal atau base64 salah. Kesalahan PEM yang umum: ketidakcocokan label (misalnya, badan sertifikat dengan label PRIVATE KEY), masalah akhir baris Windows (beberapa parser tersedak CRLF), kesalahan ketik pada baris pelindung (spasi atau karakter ekstra), atau jeda baris yang hilang.
Alat diharapkan -----BEGIN CERTIFICATE----- bukan -----BEGIN CERT----- atau BEGIN CERTIFICATE. Menyalin-menempelkan PEM dari browser web atau PDF dapat menimbulkan tanda kutip Unicode atau tanda kutip cerdas alih-alih tanda kutip ASCII, sehingga merusak label. Menempelkan kunci pribadi ke dalam bidang sertifikat adalah kesalahan umum; parser akan menolaknya karena labelnya tidak cocok. PEM mendukung banyak blok dalam satu file.
Contoh praktis: mendekode badan pendek dan memeriksa byte tanpa menegaskan tanda tangan sertifikat
File kunci SSH mungkin berisi kunci pribadi (berlabel PRIVATE KEY) dan kunci publik (berlabel PUBLIC KEY), atau beberapa blok sertifikat. Parser membaca file dari atas, mencari baris yang dimulai dengan -----BEGIN. Ketika menemukannya, ia membaca hingga -----END dengan label yang cocok, mengekstrak dan mendekode base64 tubuh, dan memprosesnya. Kemudian dilanjutkan mencari blok berikutnya.
Rantai sertifikat yang digabungkan secara tidak sengaja (beberapa blok PEM untuk sertifikat dan perantaranya) dalam satu file valid jika semua labelnya benar. Format PEM distandarisasi untuk Email yang Ditingkatkan Privasi (RFC 1421) pada awal tahun 1990an.
Apa yang tidak tercakup di sini — penguraian struktur ASN.1, enkripsi kunci pribadi, dan bundel PKCS#12
RFC 7468 (2015) memodernisasi definisi tersebut, memperjelas aturan panjang garis, format garis pelindung, dan kasus tepi. Sebagian besar alat dan standar merujuk pada RFC 7468 sekarang. Ada format biner-ke-teks lainnya (seperti DER-to-hex untuk beberapa protokol), tetapi PEM dengan label base64 dan ASCII adalah standar de facto untuk kriptografi dan TLS karena dapat dibaca manusia, teks biasa, dan mudah disalin atau dikirim.
Membangun blok PEM: ambil biner DER (misalnya, sertifikat dari perpustakaan kriptografi), enkodekan ke base64, bungkus hasilnya pada karakter 64 dengan jeda baris, dan kelilingi dengan -----BEGIN CERTIFICATE----- dan -----END CERTIFICATE----- garis. Mengurai blok PEM: temukan baris -----BEGIN dan -----END, ekstrak badan base64 (lepaskan armor dan jeda baris), dekode base64 untuk mendapatkan biner, lalu parsing biner DER dan ASN.1.
Kesimpulan: PEM adalah Base64 dengan label — bagaimana encoder & decoder Base64 memberi Anda tempat lokal untuk mencoba isi Base64 blok, seluruhnya di browser
Kebanyakan alat mengotomatiskan hal ini; Anda jarang membuat PEM dengan tangan. Namun memahami strukturnya berguna saat men-debug kesalahan penguraian atau saat memverifikasi sertifikat secara manual. Sertifikat PEM terlihat seperti teks, namun isinya adalah data biner. Membaca label awal dan akhir tidak memberi tahu Anda isi sertifikat; Anda harus memecahkan kode base64 dan mengurai ASN.1 untuk melihat nama subjek, kunci publik, penerbit dan kedaluwarsa.
Alat encoder & decoder Base64 dapat memecahkan kode isi sehingga Anda dapat memeriksa beberapa byte pertama. Untuk penguraian penuh, Anda memerlukan parser ASN.1 (sebagian besar bahasa pemrograman memiliki perpustakaan untuk ini). Wawasan utamanya adalah bahwa PEM adalah format kontainer: ia menampung data apa pun yang dikodekan DER, bukan hanya sertifikat. Label memberi tahu Anda tujuan penggunaan, tetapi parser harus menangani tipe data dengan benar.