PEM Adalah: Isi Berkas .pem, Fungsi, dan Konversinya

Setiap kali sertifikat SSL selesai diterbitkan, yang Anda terima biasanya bukan satu berkas melainkan beberapa: ada yang berekstensi .crt, ada .key, kadang ada .ca-bundle. Dibuka dengan penyunting teks, isinya terlihat mirip semua — sebaris penanda, lalu ratusan karakter yang tampak acak, lalu penanda penutup. Hal serupa terjadi saat Anda membuat key pair (pasangan kunci) di panel VPS: berkas yang terunduh berekstensi .pem dengan pola isi yang persis sama.

PEM adalah format pembungkus berbasis teks untuk data kriptografi biner. Isinya bisa berupa sertifikat, kunci privat, kunci publik, atau permintaan penandatanganan sertifikat, yang semuanya ditulis dalam bentuk Base64 di antara dua baris penanda. Kepanjangannya Privacy Enhanced Mail, nama yang terdengar tidak nyambung dengan sertifikat SSL, dan alasan di baliknya akan kita bahas sebentar lagi.

Yang membuat berkas-berkas tadi membingungkan sebenarnya bukan deretan karakter acaknya. Yang membingungkan adalah tidak adanya cara langsung mengetahui berkas mana berisi apa, sebab ekstensinya tidak menjamin apa pun. Artikel ini membedah anatomi berkas PEM, label yang mungkin Anda temui di dalamnya, dan bedanya dengan DER maupun PFX. Setelah itu kita masuk ke cara memeriksa isinya dan cara mengonversinya ketika perangkat lunak tujuan menolak format yang Anda punya.

Apa Itu PEM?

PEM adalah aturan penulisan yang mengubah data kriptografi berbentuk biner menjadi teks ASCII yang aman disalin, dikirim lewat email, dan ditempel ke kolom formulir. Struktur dasarnya selalu sama: satu baris pembuka -----BEGIN LABEL-----, badan Base64 di tengah, dan satu baris penutup -----END LABEL-----.

Ada satu hal yang perlu diluruskan sejak awal, karena kekeliruan ini sering jadi sumber salah paham. PEM bukan algoritma enkripsi, dan bukan pula jenis sertifikat. PEM hanya menentukan bagaimana data dibungkus, bukan data apa yang dibungkus. Sertifikat SSL, kunci privat RSA, kunci publik, dan berkas permintaan sertifikat bisa sama-sama disimpan dalam format PEM. Yang membedakannya hanya tulisan pada baris BEGIN dan END.

Konsekuensinya cukup penting untuk pekerjaan sehari-hari: satu berkas .pem boleh berisi lebih dari satu blok. Rantai sertifikat lengkap — sertifikat domain Anda diikuti sertifikat perantara penerbitnya — umumnya disimpan sebagai beberapa blok CERTIFICATE yang ditumpuk berurutan dalam satu berkas. Sebagian penyedia menyebut berkas semacam ini fullchain.

Empat ikon isi berkas PEM: sertifikat, gembok tertutup, gembok terbuka, dan formulir dengan pena.

Kenapa Format Sertifikat Bernama "Mail"

Nama Privacy Enhanced Mail datang dari proyek yang sama sekali berbeda. Pada Februari 1993, IETF menerbitkan RFC 1421 — bagian pertama dari empat dokumen — yang merancang PEM sebagai standar keamanan untuk email internet. Sasarannya empat: kerahasiaan isi pesan, autentikasi pengirim, jaminan integritas pesan, dan non-repudiation (pengirim tidak bisa menyangkal telah mengirim pesan tersebut). Baris penanda yang dipakai waktu itu berbunyi -----BEGIN PRIVACY-ENHANCED MESSAGE-----.

Standar itu tidak pernah diadopsi secara luas. Dunia justru memilih S/MIME dan PGP, dan RFC 1421 kini berstatus Historic di katalog IETF. Namun satu bagian kecilnya bertahan: mekanisme pembungkusnya, yang sebenarnya diwarisi dari RFC 934 tentang enkapsulasi pesan. Mekanisme itu terlalu praktis untuk dibuang. Perangkat lunak kriptografi meminjamnya untuk menyimpan sertifikat dan kunci, lalu kebiasaan tersebut menyebar selama dua dekade tanpa ada dokumen resmi yang mengaturnya.

Baru pada April 2015 IETF membakukan kebiasaan itu lewat RFC 7468, Textual Encodings of PKIX, PKCS, and CMS Structures. Dokumen itulah rujukan yang berlaku hari ini. Menariknya, RFC 7468 secara terbuka mengakui bahwa yang dibakukannya adalah praktik lapangan yang lebih dulu ada. Karena itu pula label PEM begitu beragam: sebagian lahir dari standar, sebagian lahir dari perangkat lunak tertentu yang lantas ditiru orang lain.

Pola pembungkus serupa juga dipakai di tempat lain dengan nama berbeda, misalnya ASCII armor pada OpenPGP dan format kunci OpenSSH. Bentuknya mirip, tetapi ketiganya bukan hal yang sama.

Membaca Isi Berkas .pem Baris demi Baris

Berikut contoh berkas PEM yang isinya dipangkas supaya muat di layar:

-----BEGIN CERTIFICATE-----
MIIDdzCCAl+gAwIBAgIEAgAAuTANBgkqhkiG9w0BAQUFADBaMQswCQYDVQQGEwJJ
RTESMBAGA1UEChMJQmFsdGltb3JlMRMwEQYDVQQLEwpDeWJlclRydXN0MSIwIAYD
VQQDExlCYWx0aW1vcmUgQ3liZXJUcnVzdCBSb290
-----END CERTIFICATE-----

Tiga bagian yang terlihat di atas punya aturan penulisan yang lebih ketat daripada dugaan kebanyakan orang. RFC 7468 menetapkan bahwa baris penanda harus memakai tepat lima tanda hubung di kedua sisi. Di antara kata BEGIN atau END dan labelnya juga harus ada tepat satu spasi. Perangkat lunak yang taat aturan akan menolak berkas dengan empat atau enam tanda hubung. Kegagalan pemasangan sertifikat karena hal ini termasuk yang paling sulit dilacak, sebab mata manusia sukar membedakan jumlah tanda hubung yang berdempetan.

Badan Base64 juga diatur: pembuat berkas wajib memotong barisnya tepat 64 karakter, kecuali baris terakhir yang berisi sisanya. Aturan ini warisan dari zaman ketika sistem email membatasi panjang baris.

Isi badan itu sendiri bukan teks acak. Data kriptografi awalnya berbentuk struktur biner yang dikodekan dengan aturan bernama DER (Distinguished Encoding Rules). Base64 kemudian menerjemahkan setiap tiga byte biner menjadi empat karakter ASCII yang aman dikirim ke mana saja. Karena tiga byte menjadi empat karakter, berkas PEM selalu sekitar sepertiga lebih besar daripada bentuk DER-nya.

Diagram alur pembentukan berkas PEM: sertifikat atau kunci dikodekan DER, diubah Base64, lalu dibungkus BEGIN dan END.

Satu kelonggaran yang berguna diketahui: RFC 7468 mengizinkan teks penjelas ditulis sebelum baris BEGIN dan sesudah baris END khusus untuk sertifikat. Itu sebabnya sebagian penerbit menyertakan keterangan nama domain atau masa berlaku di atas blok sertifikat tanpa membuat berkasnya rusak.

Label PEM yang Akan Anda Temui

Label adalah penentu isi. Tabel berikut memisahkan label yang benar-benar dibakukan RFC 7468 dari label yang beredar luas tanpa payung standar tersebut.

Dua baris terakhir tabel pantas diberi catatan tambahan.

Perbedaan RSA PRIVATE KEY dan PRIVATE KEY bukan soal selera penamaan. Yang pertama memakai PKCS#1, pengkodean lama yang hanya mengenal kunci RSA. Yang kedua memakai PKCS#8, pengkodean yang menyertakan keterangan jenis algoritma sehingga bisa menampung RSA, ECDSA, maupun Ed25519 dengan struktur yang sama. Perangkat lunak modern umumnya menghasilkan PKCS#8, tetapi masih banyak yang menerima keduanya.

Sementara OPENSSH PRIVATE KEY sebenarnya bukan PEM dalam pengertian RFC 7468, meski bentuknya mirip. Sejak versi 7.8 yang dirilis 24 Agustus 2018, ssh-keygen menulis kunci privat dengan format buatan OpenSSH sendiri sebagai bawaan, menggantikan format PEM milik OpenSSL. Alasannya disebutkan langsung di catatan rilisnya: format baru itu jauh lebih tahan terhadap penebakan kata sandi secara luring, sekaligus mendukung komentar di dalam kunci privat. Anda masih bisa memaksa bentuk lama dengan menambahkan -m PEM saat membuat kunci. Ini penting diketahui karena banyak panduan lama masih menyebut kunci SSH sebagai "kunci PEM", padahal sejak 2018 keluaran bawaannya sudah berbeda.

PEM, DER, CRT, CER, dan PFX: Mana Format, Mana Ekstensi

Inilah sumber kebingungan terbesar, dan aturannya sebenarnya satu kalimat: ekstensi berkas tidak menentukan formatnya.

Perbandingan berkas PEM berupa teks yang terbaca dengan berkas DER berupa data biner.

Cara memastikannya sederhana dan tidak perlu perangkat khusus: buka berkas dengan penyunting teks. Kalau baris pertamanya terbaca sebagai -----BEGIN, itu PEM. Kalau yang muncul kumpulan karakter rusak yang tidak terbaca, kemungkinan besar itu DER atau PFX.

Empat Berkas .pem dari Let's Encrypt dan Bedanya

Kalau server Anda memakai sertifikat gratis dari Let's Encrypt lewat Certbot, keempat berkas di /etc/letsencrypt/live/namadomain/ semuanya berekstensi .pem. Perbedaannya hanya pada isi, dan salah pilih di berkas konfigurasi adalah penyebab error pemasangan yang paling sering terjadi.

Aturan praktisnya: untuk Nginx dan Apache modern, pakai fullchain.pem, bukan cert.pem. Dokumentasi Certbot memperingatkan bahwa cert.pem dan chain.pem harus dipasang berdua kalau Anda memilih jalur itu. Memasang salah satunya saja membuat sebagian browser menampilkan peringatan koneksi tidak tepercaya, karena sertifikat perantaranya tidak terkirim ke pengunjung.

Gejalanya khas dan menyesatkan: situs terlihat normal di komputer Anda, tetapi gagal di ponsel atau di aplikasi yang memakai pustaka HTTP sendiri. Browser desktop sering menyimpan sertifikat perantara dari kunjungan sebelumnya, sehingga menutupi kesalahan konfigurasi yang sebenarnya ada.

Kenapa PEM Jadi Format Standar

Format biner sebenarnya lebih efisien, tetapi PEM menang karena beberapa alasan yang sangat praktis:

1. Bisa disalin-tempel: kolom "Certificate" dan "Private Key" di panel hosting menerima teks, bukan unggahan berkas. Bentuk teks membuat pemasangan sertifikat cukup dilakukan lewat papan klip.
2. Selamat melewati email dan aplikasi pesan: karena murni ASCII, isinya tidak rusak saat melintasi sistem yang tidak ramah data biner.
3. Bisa diperiksa manusia: Anda dapat mengetahui isi berkas hanya dengan membaca labelnya, tanpa membuka perangkat apa pun.
4. Bisa menampung banyak objek: rantai sertifikat berisi beberapa blok cukup ditulis berurutan dalam satu berkas.
5. Dukungan yang hampir universal: Apache, Nginx, HAProxy, dan mayoritas perangkat lunak server membaca PEM secara bawaan.

Kalau Anda memasang sertifikat SSL lewat panel hosting, kelima poin di atas menjelaskan kenapa yang diminta selalu isi berkas dalam bentuk teks, bukan berkasnya sendiri. Langkah lengkapnya kami bahas terpisah di panduan cara instalasi SSL certificate.

Kelemahan dan Hal yang Perlu Anda Pertimbangkan

Kepraktisan PEM datang bersama beberapa konsekuensi yang perlu Anda sadari:

1. Kunci privat berlabel PRIVATE KEY sama sekali tidak terenkripsi. Base64 hanya pengkodean, bukan pengamanan. Siapa pun yang memegang berkas itu memegang kunci Anda secara utuh. Perlindungan baru ada kalau labelnya ENCRYPTED PRIVATE KEY, dan itu pun bergantung pada kekuatan kata sandinya. Pembahasan lebih dalam soal beda pengkodean dan enkripsi kami tulis di artikel tersendiri.
2. Ukuran berkas bertambah sekitar 33 persen dibanding DER. Untuk satu sertifikat, selisihnya tidak terasa. Untuk sistem yang memuat ribuan sertifikat ke memori, selisih itu mulai dihitung.
3. Penamaan label tidak seragam antar-perangkat lunak. Berkas yang diterima satu server bisa ditolak server lain hanya karena perbedaan PKCS#1 dan PKCS#8.
4. Ekstensi yang ambigu memancing kesalahan. Berkas .crt berisi DER yang ditempel ke kolom yang mengharapkan PEM akan gagal tanpa pesan kesalahan yang jelas.
5. Urutan blok dalam rantai sertifikat berpengaruh. Sertifikat domain harus berada di posisi pertama, diikuti sertifikat perantara. Urutan yang terbalik masih diterima sebagian browser modern, tetapi ditolak klien yang lebih ketat seperti pustaka HTTP di aplikasi seluler.

Cara Membuka dan Memeriksa Isi Berkas PEM

Berkas PEM bisa dibuka dengan penyunting teks apa pun, termasuk Notepad. Namun yang terlihat di sana hanya labelnya. Untuk membaca isi sebenarnya, gunakan OpenSSL.

Perintah berikut menampilkan detail sertifikat — pemilik, penerbit, masa berlaku, dan daftar domain yang dicakup — tanpa mengubah berkasnya:

openssl x509 -in cert.pem -noout -text

Opsi -noout menahan OpenSSL agar tidak mencetak ulang blok Base64-nya, sehingga keluarannya hanya berisi keterangan yang terbaca. Bagian yang paling sering dicari ada di baris Not After (tanggal kedaluwarsa) dan Subject Alternative Name (daftar domain).

Untuk kunci privat, gunakan openssl pkey yang mendukung semua jenis kunci:

openssl pkey -in key.pem -noout -text

Sedangkan untuk memeriksa isi CSR sebelum mengirimkannya ke penerbit sertifikat:

openssl req -in request.csr -noout -text

Satu pemeriksaan yang menghemat banyak waktu adalah memastikan sertifikat dan kunci privat benar-benar sepasang. Caranya dengan menarik kunci publik dari masing-masing berkas, lalu membandingkan sidik jarinya:

openssl x509 -in cert.pem -noout -pubkey | openssl md5
openssl pkey -in key.pem -pubout | openssl md5

Kedua perintah harus menghasilkan hash yang sama persis. Bila berbeda, berkas yang Anda pegang berasal dari dua permintaan sertifikat yang berlainan, dan server akan menolak memuatnya. Cara ini berlaku untuk semua jenis kunci, termasuk ECDSA — berbeda dengan perbandingan modulus yang hanya bekerja pada kunci RSA.

Membaca Pesan Kesalahan yang Sering Muncul

OpenSSL cukup terus terang saat berkas yang disodorkan tidak sesuai, asalkan Anda tahu cara membacanya. Dua pesan berikut mencakup mayoritas kasus.

Saat Anda menyodorkan berkas kunci privat ke perintah yang menunggu sertifikat, keluarannya berbunyi:

Could not find certificate from key.pem
error:1608010C:STORE routines:ossl_store_handle_load_result:unsupported

Artinya berkasnya terbaca dengan baik, hanya isinya bukan sertifikat. Periksa labelnya, lalu pakai perintah yang sesuai.

Sedangkan bila baris penanda rusak — misalnya tanda hubungnya kurang satu — pesannya menyebut proses pembacaan yang gagal:

error:1E08010C:DECODER routines:OSSL_DECODER_from_bio:unsupported:
No supported data to decode. Input structure: Certificate

Pada kasus ini berkasnya yang cacat, bukan isinya. Penyebab tersering adalah proses salin-tempel yang memotong sebagian baris penanda atau menambahkan spasi tersembunyi di ujung baris. Versi OpenSSL yang lebih lama menuliskan pesan berbeda untuk kondisi yang sama, tetapi maknanya tetap: pembungkusnya tidak dikenali.

Sejak OpenSSL 3.x, perintah pembaca seperti openssl x509 mengenali DER maupun PEM secara otomatis tanpa -inform. Jadi bila perintah di atas berhasil membaca berkas .crt Anda, itu belum tentu berarti berkasnya berformat PEM.

Cara Mengonversi Berkas PEM ke Format Lain

Konversi dibutuhkan ketika perangkat lunak tujuan hanya menerima format tertentu. Semua perintah di bawah tidak mengubah berkas sumber.

Dari DER, CRT, atau CER ke PEM

Dipakai saat Anda menerima sertifikat dari penerbit berbasis Windows dan panel hosting menolak berkasnya:

openssl x509 -inform der -in cert.der -out cert.pem

Dari PEM ke DER

Sebagian perangkat jaringan dan aplikasi Java meminta bentuk biner:

openssl x509 -in cert.pem -outform der -out cert.der

Dari PEM ke PFX untuk IIS

PFX menggabungkan sertifikat, rantai perantara, dan kunci privat dalam satu berkas berkata sandi:

openssl pkcs12 -export -out cert.pfx -inkey key.pem -in cert.pem -certfile chain.pem

OpenSSL akan meminta kata sandi baru. Simpan kata sandi tersebut, karena IIS akan menanyakannya saat berkas diimpor.

Dari PKCS#1 ke PKCS#8

Bila server menolak kunci berlabel RSA PRIVATE KEY, ubah ke bentuk yang lebih umum:

openssl pkcs8 -topk8 -nocrypt -in key-pkcs1.pem -out key-pkcs8.pem

Untuk arah sebaliknya, perintah openssl rsa menyediakan flag -traditional yang memaksa keluaran PKCS#1.

Dari PEM ke PPK dan sebaliknya

Ini kebutuhan paling umum bagi pengguna Windows. Kunci privat VPS yang diunduh dari panel penyedia berbentuk .pem, sementara PuTTY hanya menerima format .ppk miliknya sendiri.

Untuk mengubah .pem menjadi .ppk, buka PuTTYgen, tekan tombol Load, pilih berkas .pem Anda — ubah penyaring berkas ke All Files karena bawaannya hanya menampilkan .ppk. PuTTYgen akan menampilkan peringatan bahwa kunci yang dimuat bukan format aslinya, lalu Anda bisa menyimpannya lewat Save private key.

Untuk arah sebaliknya, muat berkas .ppk lalu pilih menu Conversions, kemudian Export OpenSSH key. Tersedia pula pilihan Export OpenSSH key (force new file format) bila Anda memerlukan perlindungan kata sandi yang lebih baru.

Menyimpan Berkas PEM dengan Aman

Kunci privat dalam format PEM adalah berkas paling sensitif yang Anda pegang. Beberapa aturan konkret:

1. Setel izin berkas ke 400. Klien SSH menolak memakai kunci yang bisa dibaca pengguna lain. AWS menegaskan hal ini di dokumentasinya untuk kunci .pem bawaan EC2: jalankan chmod 400 nama-kunci.pem, atau koneksi akan ditolak dengan kesalahan unprotected private key file. Di Windows, matikan pewarisan izin pada properti berkas dan sisakan akses hanya untuk akun Anda.
2. Jangan pernah memasukkan kunci privat ke repositori Git. Tambahkan pola *.pem dan *.key ke .gitignore sejak awal proyek. Kunci yang sudah pernah masuk riwayat commit harus dianggap bocor dan diganti, bukan sekadar dihapus.
3. Enkripsi kunci sebelum memindahkannya. Bila kunci harus dikirim antar-mesin, ubah dulu menjadi ENCRYPTED PRIVATE KEY dengan kata sandi minimal 16 karakter acak.
4. Pisahkan penyimpanan sertifikat dan kunci privat. Sertifikat bersifat publik dan boleh dibagikan; kunci privat tidak. Menyimpan keduanya dalam satu berkas gabungan memang praktis untuk sebagian perangkat lunak, tetapi berisiko saat berkas tersebut dicadangkan atau dibagikan ke pihak lain.
5. Ganti kunci secara berkala. Untuk akses server, siklus 12 bulan adalah titik yang wajar. Panduan penggantiannya ada di artikel cara memasang SSH key.

Pertanyaan yang Sering Muncul

Apakah berkas .pem sama dengan .key? Tidak selalu. .key adalah konvensi penamaan untuk berkas berisi kunci privat, dan isinya hampir selalu PEM. Sebaliknya, .pem bisa berisi kunci privat, sertifikat, CSR, atau ketiganya sekaligus. Labelnya yang menentukan, bukan ekstensinya.

Bolehkah sertifikat dan kunci privat digabung dalam satu berkas? Boleh, dan sebagian perangkat lunak seperti HAProxy justru mengharapkannya. Tulis saja blok kunci privat dan blok sertifikat berurutan dalam satu berkas. Namun berkas gabungan itu harus diperlakukan sebagai kunci privat dari sisi keamanannya.

Kenapa berkas .pem dari AWS EC2 tidak bisa dipakai PuTTY? Karena PuTTY memakai format kunci sendiri berekstensi .ppk. Konversi lewat PuTTYgen seperti dijelaskan di atas, atau gunakan klien OpenSSH bawaan Windows yang menerima .pem secara langsung.

Apakah berkas PEM bisa dibuka di Notepad? Bisa, karena isinya teks biasa. Yang terlihat hanya label dan Base64-nya. Hindari menyimpan ulang berkas dari Notepad versi lama, sebab perubahan penanda akhir baris dapat membuat sebagian perangkat lunak menolak berkas tersebut.

Apa bedanya PEM dengan Base64 biasa? Base64 adalah metode pengkodeannya, PEM adalah kesepakatan pembungkusnya. PEM menambahkan baris BEGIN dan END berisi label, serta mengatur panjang baris tepat 64 karakter. Tanpa pembungkus itu, perangkat lunak tidak tahu jenis data yang sedang dibacanya.

Kesimpulan

PEM adalah pembungkus, bukan isi. Yang menentukan sebuah berkas berisi sertifikat, kunci privat, atau permintaan sertifikat adalah label pada baris BEGIN dan END — bukan ekstensi berkasnya, yang sepenuhnya bersifat konvensi. Karena itu, langkah pertama saat menghadapi berkas kriptografi yang tidak jelas asal-usulnya selalu sama: buka dengan penyunting teks dan baca labelnya.

Konversi baru diperlukan ketika perangkat lunak tujuan meminta bentuk lain — DER untuk perangkat jaringan, PFX untuk IIS, PPK untuk PuTTY. Selebihnya, PEM diterima hampir di mana saja. Dan apa pun formatnya, perlakukan berkas kunci privat dengan izin 400 dan jauhkan dari repositori kode. Untuk memahami protokol yang memakai sertifikat tersebut, Anda bisa melanjutkan ke pembahasan SSL dan TLS.

Semoga artikel ini membantu.