File PFX Adalah: Isi, Password, dan Cara Membuatnya

Setiap kali sebuah sertifikat SSL selesai diterbitkan, yang Anda terima biasanya bukan satu berkas, melainkan beberapa. Ada sertifikat untuk domain Anda, satu atau dua sertifikat perantara, dan kunci privat yang dibuat lebih dulu di server. Di Apache maupun Nginx, ketiganya memang ditunjuk terpisah lewat baris konfigurasi yang berbeda.

Kesulitan muncul ketika berkas yang sama harus dipasang di tempat lain. IIS pada Windows Server tidak menyediakan tiga kolom untuk tiga berkas, dan panel sertifikat di banyak layanan cloud hanya punya satu tombol unggah. Perangkat lunak semacam itu membutuhkan seluruh isi tadi dikemas menjadi satu.

File PFX adalah kemasan tersebut: satu berkas biner berkata sandi yang memuat kunci privat, sertifikat, dan rantai penerbitnya sekaligus. Artikel ini membedah isinya, menjelaskan kenapa berkas ini sebenarnya memiliki dua kata sandi, lalu masuk ke cara membuat, membongkar, memeriksa, dan memperbaiki berkas PFX yang ditolak server.

Apa Itu File PFX?

PFX adalah singkatan dari Personal Information Exchange, sebuah format wadah untuk memindahkan identitas kriptografis dari satu mesin ke mesin lain. Identitas yang dimaksud adalah kunci privat beserta sertifikat yang memasangkannya dengan sebuah nama. Nama resminya di dunia standar bukan PFX, melainkan PKCS #12, anggota kedua belas dari seri Public Key Cryptography Standards yang disusun RSA Laboratories.

Kendali atas standar itu sekarang dipegang IETF. Pada Juli 2014 terbit RFC 7292, PKCS #12: Personal Information Exchange Syntax v1.1, yang merepublikasi spesifikasi RSA tersebut sekaligus memindahkan kewenangan perubahannya — dan dokumen itulah rujukan yang berlaku hari ini.

Ada satu hal yang perlu diluruskan sejak awal: PFX bukan jenis sertifikat, melainkan cara membungkus. Sertifikat di dalamnya tetap sertifikat X.509 biasa, sama persis dengan yang dipasang di Apache. Karena itu pertanyaan "sertifikat saya PFX atau bukan" sebenarnya keliru; yang tepat adalah "sertifikat saya sedang dibungkus PFX atau tidak".

Berbeda dengan format PEM yang berisi teks dan bisa dibuka di penyunting teks mana pun, PFX adalah berkas biner. Membukanya dengan Notepad hanya menampilkan karakter rusak; isinya baru terbaca setelah didekripsi dengan kata sandi yang benar.

Apa Saja yang Tersimpan di Dalam Berkas PFX

RFC 7292 menyebut isi berkas PFX sebagai kumpulan bag atau kantong, dan mendefinisikan enam jenis kantong yang boleh ada di dalamnya. Pada berkas yang Anda temui sehari-hari, hanya tiga jenis yang benar-benar terpakai:

1. Kunci privat: disimpan sebagai PKCS8ShroudedKeyBag, artinya kunci privat yang sudah terenkripsi. Standar sebenarnya juga mengizinkan kunci privat polos tanpa enkripsi lewat KeyBag, tetapi perangkat lunak modern praktis tidak pernah menghasilkannya.
2. Sertifikat: disimpan sebagai CertBag. Satu berkas PFX bisa memuat beberapa CertBag sekaligus — biasanya sertifikat domain Anda ditambah sertifikat perantara penerbitnya.
3. Atribut pendamping: yang paling sering terlihat adalah friendly name, nama panggilan yang muncul di kolom nama pada Certificate Manager Windows.

Tiga jenis kantong lain — untuk daftar pencabutan sertifikat, rahasia bebas, dan kantong bersarang — tersedia di standar tetapi jarang dipakai perangkat lunak umum.

Konsekuensi dari daftar di atas sering diremehkan. Karena PFX memuat kunci privat, berkas ini harus diperlakukan seperti kunci privat itu sendiri, bukan seperti sertifikat. Satu berkas PFX yang bocor berarti seluruh identitas server ikut bocor, dan sertifikatnya harus dicabut lalu diterbitkan ulang.

Rantai perantara yang ikut terbawa justru menjadi kelebihan praktisnya. Pada Apache atau Nginx, rantai sertifikat yang tidak lengkap adalah penyebab klasik sertifikat yang normal di browser tetapi ditolak aplikasi seluler. Dengan PFX, rantai tersebut ikut dikemas sejak awal sehingga risiko lupa memasangnya berkurang.

PFX dan P12: Dua Nama, Satu Format

Pertanyaan yang hampir selalu muncul begitu orang berhadapan dengan berkas ini adalah bedanya .pfx dan .p12. Jawabannya singkat: tidak ada bedanya. Keduanya adalah berkas PKCS #12 dengan struktur biner yang identik. Yang berbeda hanya kebiasaan penamaan.

Ekstensi berkas (file extension) .pfx berasal dari tradisi Microsoft, sedangkan .p12 merupakan singkatan nama standarnya. Mengganti nama sertifikat.p12 menjadi sertifikat.pfx tidak mengubah apa pun, karena perangkat lunak membaca strukturnya, bukan namanya. Pembuktiannya ada di byte pertama berkas:

xxd -l 16 sertifikat.pfx

Keluarannya kira-kira seperti ini:

00000000: 3082 0da0 0201 0330 820d 4e06 092a 8648

Tiga byte 02 01 03 di posisi kelima sampai ketujuh adalah bilangan bulat bernilai 3, yaitu nomor versi struktur PFX menurut RFC 7292. Byte itu ada di setiap berkas PKCS #12, apa pun ekstensinya.

Perintah file pada macOS dan Linux tidak membantu di sini — berkas PFX hanya dilaporkan sebagai data. Cara paling andal mengenali berkas PKCS #12 adalah mencoba membacanya dengan openssl pkcs12, seperti dibahas di bagian pemeriksaan nanti.

Di Indonesia, ekstensi .p12 justru lebih sering ditemui daripada .pfx, karena sertifikat elektronik dari Direktorat Jenderal Pajak diterbitkan dalam bentuk berkas Personal Information Exchange berekstensi tersebut. Berkas yang dipakai wajib pajak untuk menandatangani faktur pajak secara elektronik itu adalah berkas PKCS #12 yang sama persis dengan yang dipasang di server web.

Dua Kata Sandi yang Sebenarnya Ada di Dalam PFX

Ketika membuat berkas PFX, Anda hanya diminta mengetik satu kata sandi. Standarnya sendiri sebenarnya mengenal dua, dan memahami pembagian ini menjelaskan banyak perilaku yang tampak aneh.

RFC 7292 memisahkan dua peran:

1. Kata sandi privasi (privacy password): menurunkan kunci simetris yang mengenkripsi isi berkas.
2. Kata sandi keutuhan (integrity password): menghasilkan MAC (Message Authentication Code), sidik pengaman yang membuktikan berkas tidak diubah orang lain di tengah jalan.

Standar itu menyatakan kedua kata sandi tersebut boleh sama, boleh juga berbeda. Dalam praktik hampir semua perangkat lunak mengisi keduanya dengan nilai sama, sehingga pengguna merasa hanya memasukkan satu kata sandi.

Pembagian peran ini terlihat saat kata sandi salah. Pesan yang muncul bukan keluhan soal dekripsi:

Mac verify error: invalid password?

Yang gagal lebih dulu adalah pemeriksaan MAC, bukan pembongkaran isi — perangkat lunak memeriksa keutuhan berkas sebelum mendekripsi apa pun, persis seperti urutan yang dirancang standarnya.

Ada satu jebakan lain sebelum Anda menentukan kata sandi. RFC 7292 mengharuskan kata sandi diperlakukan sebagai BMPString berpenutup NULL, sehingga setiap karakter dikodekan menjadi dua byte. Contoh dari standar itu sendiri: kata sandi "Beavis" yang berisi enam karakter diproses sebagai rangkaian 14 byte. Aturan ini pernah diterapkan berbeda-beda antar perangkat lunak, dan akibatnya kata sandi berisi karakter di luar ASCII kadang diterima satu program tetapi ditolak program lain.

Rekomendasi praktisnya konkret: minimal 16 karakter, isinya dibatasi pada huruf, angka, dan tanda baca ASCII. Hindari huruf beraksen, emoji, serta simbol mata uang. Panjang 16 karakter dipilih karena berkas PFX bisa ditebak kata sandinya secara luring tanpa batas percobaan, seperti dibahas di bagian kelemahan nanti.

Empat Situasi yang Membuat Anda Membutuhkan File PFX

Penerbit sertifikat umumnya menyerahkan berkas dalam bentuk PEM. Pengemasan ke PFX hampir selalu dilakukan sendiri oleh pemilik sertifikat, biasanya karena salah satu dari empat alasan berikut.

1. Memasang sertifikat di IIS dan Windows Server. Wizard impor sertifikat pada IIS meminta satu berkas berkata sandi, bukan tiga berkas terpisah. Inilah pemakaian PFX yang paling umum, dan alasan kenapa hampir semua panduan pembuatan PFX berujung di Windows.
2. Mengunggah sertifikat ke layanan terkelola. Sebagian layanan aplikasi berbasis cloud dan load balancer terkelola hanya menyediakan satu kolom unggah, dan format yang diminta adalah PFX. Alasannya, kunci privat harus ikut terkirim agar layanan itu bisa menyelesaikan jabat tangan TLS atas nama Anda. Azure App Service salah satu contohnya. Layanan lain seperti AWS dan Cloudflare justru meminta PEM, jadi periksa dokumentasinya sebelum mengemas.
3. Menandatangani kode dan dokumen. Sertifikat penandatanganan kode dan dokumen didistribusikan sebagai PFX, sebab alat penanda tangan membutuhkan kunci privat dan sertifikatnya sekaligus.
4. Sertifikat elektronik di layanan pemerintah. Sertifikat elektronik pajak diterbitkan sebagai berkas .p12 dengan masa berlaku dua tahun. Kata sandinya, yang di lingkungan perpajakan disebut passphrase, ditentukan sendiri oleh pemohon saat mengajukan. Bila kata sandi itu terlupa, tidak ada mekanisme pemulihan: permohonan sertifikat elektronik harus diajukan ulang dari awal.

Perhatikan bahwa yang dikemas selalu berkas dari penerbit. Sertifikatnya sendiri harus diterbitkan lebih dulu — lewat layanan SSL berbayar atau penerbit gratis seperti Let's Encrypt — dan pengemasan ke PFX baru dilakukan setelah berkasnya di tangan.

Beda PFX dengan PEM, CRT, DER, P7B, dan JKS

Kebingungan seputar berkas sertifikat sebagian besar berasal dari tercampurnya dua hal yang berbeda: nama format dan nama ekstensi. Format menentukan bagaimana data disusun; ekstensi hanyalah kebiasaan penamaan yang tidak menjamin apa pun.

Dua baris terakhir adalah sumber kekeliruan paling sering. Berkas .crt bisa berisi PEM maupun DER, dan tidak ada cara mengetahuinya selain membuka berkasnya. Pembahasan lebih rinci soal cara membaca isi berkas teks tersebut ada di artikel tentang format PEM.

Perbandingan PFX dengan JKS layak diberi catatan tersendiri. JKS adalah format keystore khas Java yang dahulu menjadi bawaan. Sejak JDK 9, lewat perubahan berjudul Create PKCS12 Keystores by Default, keystore baru yang dibuat Java memakai format PKCS #12 — format yang sama dengan PFX. Artinya untuk aplikasi Java modern, konversi dari PFX ke JKS umumnya sudah tidak diperlukan lagi.

Cara Membuat File PFX

Cara paling langsung adalah lewat OpenSSL, yang tersedia di Linux, macOS, maupun Windows. Seluruh perintah di bagian ini diuji pada OpenSSL 3.6.

Langkah #1: Kumpulkan Tiga Berkas yang Dibutuhkan

Siapkan tiga berkas berikut dalam satu direktori:

• key.pem — kunci privat, dibuat di server bersamaan dengan permintaan sertifikat
• cert.pem — sertifikat untuk domain Anda dari penerbit
• chain.pem — sertifikat perantara, sering dinamai ca-bundle atau intermediate

Nama berkasnya boleh apa saja, termasuk berakhiran .crt atau .key. Yang penting isinya berformat PEM, dan itu dipastikan dengan membukanya di penyunting teks lalu mencari baris -----BEGIN.

Langkah #2: Jalankan Perintah Ekspor

Perintah berikut menggabungkan ketiganya menjadi satu berkas PFX:

openssl pkcs12 -export \
  -out sertifikat.pfx \
  -inkey key.pem \
  -in cert.pem \
  -certfile chain.pem \
  -name "contoh.co.id"

OpenSSL akan meminta kata sandi dua kali, dan nilai itulah yang nanti diminta saat berkas diimpor. Opsi -name mengisi friendly name yang tadi dibahas, sehingga kolom nama di daftar sertifikat Windows terbaca alih-alih menampilkan deretan karakter acak.

Jangan menuliskan kata sandi langsung di baris perintah lewat -passout pass:... pada mesin bersama. Perintah yang Anda ketik tersimpan di riwayat shell dan terlihat pengguna lain lewat daftar proses.

Langkah #3: Periksa Hasilnya Sebelum Dikirim

Sebelum berkas dipasang atau dikirim, pastikan isinya memang lengkap:

openssl pkcs12 -in sertifikat.pfx \
  -info -nokeys -nocerts

Keluaran dari berkas yang dibuat OpenSSL 3.6 dengan perintah di atas terlihat seperti ini:

MAC: sha256, Iteration 2048
PKCS7 Encrypted data: PBES2, PBKDF2, AES-256-CBC,
  Iteration 2048, PRF hmacWithSHA256
Certificate bag
Certificate bag
Shrouded Keybag: PBES2, PBKDF2, AES-256-CBC,
  Iteration 2048, PRF hmacWithSHA256

Dua baris Certificate bag menandakan sertifikat domain dan sertifikat perantara berhasil masuk, sedangkan Shrouded Keybag menandakan kunci privat ikut terkemas. Kalau salah satu baris itu tidak muncul, berkas Anda belum lengkap dan akan ditolak server. Perhatikan juga nama algoritma yang tercetak, karena bagian tentang pesan error nanti bertumpu pada informasi ini.

Membuat PFX dari Windows Tanpa OpenSSL

Kalau sertifikatnya memang sudah berada di penyimpanan sertifikat Windows — misalnya karena permintaan sertifikat dibuat lewat IIS — Anda tidak membutuhkan OpenSSL sama sekali. PowerShell sudah menyediakan perintahnya:

$sandi = ConvertTo-SecureString -AsPlainText `
  -String 'KataSandiAnda' -Force
$sidik = '<thumbprint-sertifikat>'
Get-ChildItem Cert:\LocalMachine\My\$sidik |
  Export-PfxCertificate `
  -FilePath C:\sertifikat.pfx -Password $sandi

Variabel $sidik diisi nilai thumbprint sertifikat, yang terlihat dengan menjalankan Get-ChildItem Cert:\LocalMachine\My tanpa argumen lain.

Dua parameter berikut berguna tetapi jarang dipakai:

• -ChainOption: menentukan sertifikat mana yang ikut diekspor. Nilai bawaannya BuildChain, yang menyertakan seluruh rantai. Pakai EndEntityCertOnly bila Anda hanya ingin sertifikat domain saja.
• -ProtectTo: mengikat berkas PFX ke akun atau grup domain tertentu sehingga dapat diimpor tanpa kata sandi oleh akun tersebut, dan membutuhkan pengendali domain Windows Server 2012 ke atas. Salah satu dari -Password atau -ProtectTo wajib diisi.

Perlu dicatat, Export-PfxCertificate memakai nilai bawaan yang berbeda dari OpenSSL, dan perbedaan itu adalah biang salah satu pesan error yang dibahas beberapa bagian lagi.

Kenapa Sebaiknya Tidak Memakai Konverter SSL Online

Banyak situs menawarkan konversi sertifikat lewat peramban: unggah tiga berkas, ketik kata sandi, unduh berkas PFX. Langkah itu memang cepat, tetapi salah satu berkas yang Anda unggah adalah kunci privat.

Begitu kunci privat meninggalkan server Anda, tidak ada cara membuktikan bahwa ia tidak disimpan di sisi penyedia layanan. Satu-satunya respons yang benar terhadap kunci privat yang pernah lepas dari kendali adalah mencabut sertifikatnya lalu menerbitkan yang baru — jauh lebih lama daripada menjalankan satu perintah openssl pkcs12 di mesin sendiri. Bila OpenSSL tidak ada di komputer Anda, jalankan perintahnya di server tempat sertifikat akan dipasang.

Membongkar Isi PFX Menjadi Berkas Terpisah

Arah sebaliknya sama seringnya dibutuhkan: Anda menerima berkas PFX, tetapi server tujuannya berjalan di Apache, Nginx, atau HAProxy yang meminta berkas PEM terpisah. Tiga perintah berikut mengeluarkan masing-masing bagian.

Mengambil sertifikat domain saja:

openssl pkcs12 -in sertifikat.pfx \
  -clcerts -nokeys -out cert.pem

Mengambil sertifikat perantara:

openssl pkcs12 -in sertifikat.pfx \
  -cacerts -nokeys -out chain.pem

Mengambil kunci privat tanpa kata sandi tambahan:

openssl pkcs12 -in sertifikat.pfx \
  -nocerts -nodes -out key.pem

Opsi -nodes berarti kunci privat ditulis dalam keadaan tidak terenkripsi. Berkas hasilnya harus segera dibatasi izin aksesnya:

chmod 400 key.pem

Bila server tujuan mendukung kunci privat berkata sandi, hilangkan -nodes supaya kunci tetap terlindungi. Konsekuensinya, layanan meminta kata sandi setiap kali dijalankan ulang — menyulitkan mulai ulang otomatis.

Cara Memeriksa Berkas PFX Sebelum Dipasang

Memasang sertifikat lalu menunggu apakah situs terbuka adalah cara paling mahal untuk mengetahui ada yang salah. Tiga pemeriksaan berikut memakan waktu kurang dari satu menit.

Memastikan kata sandi benar. Jalankan perintah -info di atas. Bila kata sandinya salah, pesan Mac verify error: invalid password? muncul seketika tanpa merusak berkas. Ini juga cara aman mengecek kata sandi berkas PFX kiriman orang lain.

Memastikan kunci privat berpasangan dengan sertifikatnya. Kunci dan sertifikat yang tidak sepasang adalah penyebab klasik layanan gagal dijalankan. Bandingkan sidik ringkas dari modulus keduanya:

openssl pkcs12 -in sertifikat.pfx \
  -clcerts -nokeys \
  | openssl x509 -noout -modulus \
  | openssl sha256

openssl pkcs12 -in sertifikat.pfx \
  -nocerts -nodes \
  | openssl rsa -noout -modulus \
  | openssl sha256

Kedua perintah harus menghasilkan nilai yang sama persis, misalnya 4601937f3ef20ff4.... Bila berbeda, berkas PFX itu memuat kunci milik sertifikat lain dan tidak akan pernah bekerja.

Memastikan masa berlakunya masih panjang. Sertifikat yang sudah kedaluwarsa tetap bisa dikemas ke PFX tanpa keluhan apa pun:

openssl pkcs12 -in sertifikat.pfx \
  -clcerts -nokeys \
  | openssl x509 -noout -subject -enddate

Memasang Berkas PFX di IIS

Setelah isinya dinyatakan lengkap, pemasangan di IIS berjalan dalam dua tahap yang sering tertukar: mengimpor sertifikat ke penyimpanan Windows, lalu mengikatnya ke situs.

Langkah #1: Impor ke Penyimpanan Sertifikat

Buka IIS Manager, pilih nama server di panel kiri, lalu klik dua kali Server Certificates. Di panel Actions sebelah kanan, pilih Import, tunjuk berkas .pfx Anda, dan masukkan kata sandinya.

Satu kotak centang di dialog itu menentukan nasib berkas Anda kelak: Allow this certificate to be exported. Bila tidak dicentang, kunci privat tidak akan pernah bisa dikeluarkan lagi dari server tersebut. Centang bila Anda masih membutuhkan cadangan atau berencana memindahkannya ke server lain.

Lewat PowerShell, langkah yang sama berbunyi:

Import-PfxCertificate `
  -FilePath C:\sertifikat.pfx `
  -CertStoreLocation Cert:\LocalMachine\My `
  -Exportable -Password $sandi

Tanpa -Exportable, kunci privat yang masuk tidak dapat diekspor kembali — perilaku yang persis sama dengan kotak centang tadi.

Langkah #2: Ikat Sertifikat ke Situs

Masih di IIS Manager, buka Sites, pilih situs Anda, lalu klik Bindings di panel Actions. Tambahkan binding bertipe https pada port 443, kemudian pilih sertifikat yang baru diimpor pada kolom SSL certificate.

Sertifikat yang sudah masuk penyimpanan tidak otomatis dipakai sampai binding ini dibuat. Situs yang tetap menolak koneksi HTTPS meski impor dilaporkan berhasil hampir selalu berhenti di langkah ini.

Dua Pesan Error yang Paling Sering Muncul Saat PFX Ditolak

Kegagalan memasang berkas PFX jarang disebabkan salah ketik kata sandi. Penyebab yang jauh lebih sering adalah perbedaan algoritma antara program yang membuat berkas dan program yang membacanya — OpenSSL 3 dan Windows memakai nilai bawaan yang berbeda.

OpenSSL 3 mengenkripsi isi berkas PFX dengan AES-256-CBC dan menurunkan kuncinya lewat PBKDF2, dengan MAC berbasis SHA-256. Sementara itu Export-PfxCertificate di Windows — sampai versi Windows Server 2025 sekalipun — masih memakai nilai bawaan TripleDES_SHA1, yaitu 3DES dengan MAC SHA-1. Dari selisih inilah dua pesan error di bawah lahir.

Pesan "The specified network password is not correct" di Windows

Gejalanya khas: berkas dibuat dengan OpenSSL versi baru, kata sandinya sudah dipastikan benar, berkas terbuka normal di Windows 10 atau 11, tetapi ditolak saat diimpor ke Windows Server yang lebih lama. Laporan di forum dukungan Microsoft menunjukkan pola yang sama, dengan Windows Server 2012 R2 dan 2016 sebagai korban tersering.

Penyebabnya bukan kata sandi, melainkan AES-256 yang tidak dikenali penyimpanan sertifikat Windows versi tersebut. Pesannya menyesatkan karena Windows menerjemahkan kegagalan membuka isi sebagai kegagalan kata sandi.

Perbaikannya adalah membuat ulang berkas PFX dengan algoritma yang lebih tua:

openssl pkcs12 -export \
  -out sertifikat-kompat.pfx \
  -inkey key.pem -in cert.pem \
  -certfile chain.pem \
  -certpbe PBE-SHA1-3DES \
  -keypbe PBE-SHA1-3DES \
  -macalg SHA1

Setelah dijalankan, pemeriksaan -info akan menampilkan pbeWithSHA1And3-KeyTripleDES-CBC dan MAC: sha1 — persis nilai bawaan yang dipakai Windows sendiri, sehingga berkasnya pasti diterima.

Perlu diingat, 3DES dan SHA-1 adalah algoritma tua. Pakai perintah ini hanya ketika server tujuan memang menolak AES-256, lalu hapus berkasnya segera setelah impor selesai.

Pesan "unsupported ... Algorithm (RC2-40-CBC)" di OpenSSL

Kebalikannya terjadi ketika Anda membuka berkas PFX lama — yang dibuat Windows generasi sebelumnya atau alat Java lawas — dengan OpenSSL 3. Keluarannya seperti ini:

PKCS7 Encrypted data: pbeWithSHA1And40BitRC2-CBC,
  Iteration 2048
Error outputting keys and certificates
80E153F901000000:error:0308010C:digital envelope
routines:inner_evp_generic_fetch:unsupported:
Algorithm (RC2-40-CBC : 0), Properties ()

OpenSSL 3 memindahkan algoritma usang seperti RC2 ke legacy provider yang tidak dimuat secara bawaan. Memuatnya cukup dengan menambahkan satu opsi:

openssl pkcs12 -in lama.pfx -legacy \
  -info -nokeys -nocerts

Ada satu anggapan keliru yang perlu diperbaiki di sini: tidak semua berkas PFX lama membutuhkan -legacy. Berkas yang memakai 3DES — termasuk hasil Export-PfxCertificate dengan pengaturan bawaannya — terbaca sempurna oleh OpenSSL 3 tanpa opsi tambahan apa pun. Yang benar-benar memicu galat hanya RC2-40 pada kantong sertifikat. Karena itu, langkah pertama saat menghadapi berkas PFX bermasalah selalu sama: baca dulu nama algoritmanya lewat -info, baru tentukan perlakuannya.

Setelah berhasil dibuka dengan -legacy, kemas ulang berkas itu memakai algoritma modern supaya masalah yang sama tidak berulang.

Kelemahan dan Hal yang Perlu Anda Pertimbangkan

Kemudahan mengemas semuanya dalam satu berkas datang bersama beberapa konsekuensi yang perlu Anda timbang.

1. Kata sandinya bisa ditebak tanpa batas percobaan. RFC 7292 menyatakan terus terang bahwa metode berbasis kata sandi seperti ini memungkinkan pencarian kata sandi secara luring. Siapa pun yang memegang berkas Anda dapat mencoba sebanyak yang ia mau di komputernya sendiri, tanpa ada sistem yang memblokir. Inilah alasan panjang kata sandi jauh lebih menentukan daripada kerumitannya.
2. Tidak ada pemulihan kata sandi. Kata sandi bukan disimpan di dalam berkas, melainkan dipakai menurunkan kunci enkripsinya. Kata sandi yang terlupa berarti isi berkas hilang selamanya. Aturan pada sertifikat elektronik pajak menunjukkan wujud nyatanya: pemohon yang lupa kata sandi harus mengajukan permohonan sertifikat baru dari awal, bukan meminta pemulihan.
3. Satu berkas berarti satu titik kebocoran. Pada Apache, kunci privat berada di berkas terpisah yang izinnya bisa diperketat sendiri. Pada PFX, kunci privat dan sertifikat menyatu dalam satu berkas yang lalu-lalang lewat email, obrolan tim, dan penyimpanan awan.
4. Isinya tidak bisa diperiksa sekilas. Berkas PEM cukup dibuka di penyunting teks untuk diketahui isinya, sedangkan berkas PFX menuntut kata sandi dan perkakas tambahan. Kekeliruan jadi lebih mudah terlewat sampai layanan gagal dijalankan.
5. Pilihan algoritmanya bisa membuat berkas tidak terbaca. Berkas yang sama bisa diterima satu server dan ditolak server lain semata karena algoritma bawaan pembuatnya berbeda.

Menyimpan dan Mengirim Berkas PFX dengan Aman

Empat kebiasaan berikut menutup sebagian besar risiko di atas:

• Batasi izin berkasnya begitu dibuat. Di Linux dan macOS, chmod 400 sertifikat.pfx membuat hanya pemiliknya yang dapat membaca.
• Hapus berkasnya setelah impor selesai. Begitu sertifikat masuk ke penyimpanan Windows atau konfigurasi server, berkas PFX tidak lagi dibutuhkan di direktori kerja. Simpan cadangannya di pengelola kata sandi atau brankas rahasia tim.
• Kirim kata sandi lewat saluran berbeda dari berkasnya. Mengirim berkas PFX beserta kata sandinya dalam satu email membuat enkripsinya kehilangan makna.
• Jangan pernah memasukkannya ke repositori kode. Berkas yang pernah masuk riwayat Git tetap dapat diambil meski dihapus di komit berikutnya, dan satu-satunya perbaikan adalah mencabut sertifikatnya.

Pertanyaan yang Sering Muncul

Bisakah kata sandi berkas PFX diganti tanpa membuat ulang dari awal?

Bisa. Di Windows, gabungan Get-PfxData dan Export-PfxCertificate membaca berkas dengan kata sandi lama lalu menulis ulang dengan kata sandi baru. Di OpenSSL, cara setara adalah membongkar isinya ke PEM lalu mengekspornya kembali. Sertifikat dan kunci di dalamnya tidak berubah, sehingga tidak perlu menerbitkan ulang apa pun.

Apakah berkas PFX boleh dibuat tanpa kata sandi?

Secara teknis boleh, tetapi kunci privat di dalamnya jadi tersimpan nyaris polos. Bila alasannya otomatisasi yang tidak dapat memasukkan kata sandi, pertimbangkan -ProtectTo di Windows yang mengikat berkas ke akun tertentu tanpa mengorbankan perlindungan.

Satu berkas PFX bisa memuat berapa sertifikat?

Tidak ada batas praktis, dan berkas berisi banyak pasangan kunci-sertifikat lazim dipakai sebagai cadangan. Untuk pemasangan di server, sebaiknya satu berkas berisi satu sertifikat domain beserta rantainya saja.

Bagaimana mengetahui sebuah berkas PFX memuat kunci privat atau tidak?

Jalankan openssl pkcs12 -in berkas.pfx -info -nokeys -nocerts dan cari baris Shrouded Keybag. Bila baris itu tidak ada, berkas tersebut hanya berisi sertifikat dan tidak dapat dipakai memasang layanan TLS.

Apakah PFX masih perlu dikonversi ke JKS untuk aplikasi Java?

Umumnya tidak lagi. Sejak JDK 9, keystore baru yang dibuat Java sudah berformat PKCS #12, sehingga berkas PFX dapat ditunjuk langsung sebagai keystore. Konversi baru diperlukan bila aplikasinya berjalan di versi Java yang jauh lebih tua.

Kesimpulan

File PFX adalah wadah berkata sandi yang menyatukan kunci privat, sertifikat, dan rantai penerbitnya dalam satu berkas biner. Ekstensi .pfx dan .p12 menunjuk format yang sama persis, tersusun sebagai kantong-kantong menurut standar PKCS #12. Karena kunci privat ikut di dalamnya, berkas ini adalah rahasia, bukan sertifikat biasa.

Saat berkas PFX ditolak server, dugaan pertama sebaiknya bukan kata sandi yang salah ketik, melainkan algoritma yang tidak cocok. Jalankan openssl pkcs12 -info untuk melihat algoritma yang benar-benar terpakai, lalu kemas ulang mengikuti nilai bawaan yang dikenali sistem tujuan. AES-256 untuk sistem modern, 3DES dengan MAC SHA-1 untuk Windows Server lama. Untuk kata sandinya, panjang minimal 16 karakter ASCII jauh lebih menentukan daripada kerumitan simbol.

Semoga artikel ini membantu.