Cara Membuat CSR untuk Sertifikat Code Signing melalui MMC

Snap-in Certificates di Microsoft Management Console (MMC) dapat membuat permintaan sertifikat PKCS #10 di komputer Windows tanpa perangkat lunak tambahan apa pun. Panduan ini membahas wizard tersebut layar demi layar untuk sertifikat code signing, dan dimulai dengan bagian yang paling sering dilewatkan oleh instruksi-instruksi lama: aturan untuk private key code signing berubah pada 1 Juni 2023, dan aturan itulah yang menentukan apakah permintaan dari MMC bisa digunakan sama sekali.

Bacalah persyaratan itu sebelum Anda membuka wizard. Sisa panduan ini mengasumsikan Anda sudah tahu jalur mana yang berlaku untuk pesanan Anda.

Kunci code signing harus dibuat pada perangkat keras

Berdasarkan CA/Browser Forum Code Signing Baseline Requirements, yang berlaku sejak 1 Juni 2023, private key untuk setiap sertifikat code signing yang dipercaya secara publik harus dibuat, disimpan, dan digunakan dalam modul kripto perangkat keras yang tersertifikasi setidaknya FIPS 140-2 Level 2, Common Criteria EAL 4+, atau standar setara. Ini mencakup baik sertifikat standar (Organization Validation dan Individual Validation) maupun Extended Validation. EV code signing sudah bekerja dengan cara ini sebelumnya; perubahan tahun 2023 memperluas aturan yang sama ke produk-produk standar.

Persyaratan tersebut juga menetapkan ketentuan untuk kunci itu sendiri. Kunci RSA harus berukuran setidaknya 3072 bit, kunci ECDSA harus menggunakan NIST P-256, P-384, atau P-521, dan SHA-1 tidak diperbolehkan untuk sertifikat code signing.

Sama pentingnya, Certificate Authority harus membuktikan bahwa kunci tersebut benar-benar berada di perangkat keras, menggunakan salah satu metode yang tercantum dalam persyaratan. Dalam praktiknya, ini adalah metode-metode yang akan Anda temui:

• CA mengirimkan token perangkat keras kepada Anda yang sudah berisi pasangan kunci yang dibuat oleh CA pada perangkat tersebut.
• Anda menandatangani ulang permintaan tersebut dengan sertifikat dari produsen, yang inilah yang dimaksud dengan key attestation: bukti bahwa kunci dibuat dengan cara yang tidak dapat diekspor di dalam perangkat yang memenuhi standar.
• Anda menggunakan kombinasi pustaka kripto dan modul perangkat keras yang ditentukan oleh CA.
• Anda menyediakan audit TI, laporan dari layanan perlindungan kunci berbasis cloud, atau perjanjian yang Anda tanda tangani melalui layanan penandatanganan yang memenuhi standar.

Tidak satu pun dari itu terpenuhi oleh permintaan yang dibuat MMC terhadap Microsoft Software Key Storage Provider. Penyedia tersebut membuat kunci di penyimpanan perangkat lunak Windows, sehingga permintaan yang dihasilkan akan ditolak untuk sertifikat code signing yang dipercaya secara publik, tidak peduli bagaimana bagian lain dari wizard diisi. Certificate Authority juga sudah berhenti menawarkan pembuatan kunci berbasis browser dan pengiriman file .pfx yang dapat diunduh untuk produk-produk ini pada waktu yang sama.

Jika tujuan Anda adalah sertifikat yang dipercaya secara publik, jalur yang ditempuh ditentukan saat Anda memesan. Entah CA membuat kunci pada token dan mengirimkannya kepada Anda melalui surat, yang dalam hal ini tidak ada CSR yang perlu Anda buat, atau Anda membuat kunci pada perangkat keras yang sudah Anda miliki dan mengirimkan attestation bersama permintaan tersebut. Panduan metode pengiriman sertifikat code signing membandingkan kedua cara tersebut, dan langkah-langkah khusus untuk perangkat ada di sini:

• YubiKey 5 FIPS: pembuatan CSR dan attestation
• Luna Network Attached HSM v7.x: panduan CSR dan attestation

Di mana MMC masih cocok digunakan

Wizard ini tidak usang. Justru penyedia yang Anda pilih di dalamnya yang menentukan di mana kunci itu “lahir”, dan ada tiga situasi di mana wizard ini tetap menjadi alat yang tepat.

Permintaan yang didukung oleh penyedia perangkat keras. Daftar Cryptographic Service Provider di wizard menampilkan setiap penyedia yang terpasang di komputer, bukan hanya penyedia perangkat lunak milik Microsoft. Setelah driver token atau minidriver smart card terpasang, penyedianya juga akan muncul di sana. Perbedaannya terletak pada di mana pasangan kunci itu “lahir”: penyedia perangkat lunak membuatnya di komputer Anda, sementara penyedia berbasis perangkat keras, seperti smart card atau penyedia token, memerintahkan perangkat untuk membuat pasangan kunci tersebut, dan perangkat itu kemudian menyimpan private key serta mengontrol aksesnya. Pilih penyedia perangkat keras dan MMC akan menghasilkan permintaan untuk kunci yang tidak pernah ada dalam bentuk perangkat lunak.

Ada dua catatan sebelum Anda mengandalkan hal itu. MMC hanya menghasilkan permintaan PKCS #10 dan tidak lebih, sehingga tidak membuat file key attestation yang diinginkan oleh sebagian besar Certificate Authority sebagai pelengkap. File tersebut berasal dari perangkat lunak bawaan perangkat itu sendiri. Dan CA yang menentukan metode verifikasi mana yang akan diterima, dengan banyak yang menetapkan utilitas mereka sendiri untuk tugas ini. Tanyakan kepada CA Anda jalur mana yang mereka dukung sebelum Anda membuat apa pun, karena kunci yang Anda buat dengan alat yang salah tidak dapat dipindahkan setelahnya.

CA internal atau enterprise. Baseline Requirements mengatur sertifikat yang dipercaya secara publik. Sertifikat yang diterbitkan oleh CA Active Directory Certificate Services milik Anda sendiri untuk penandatanganan internal berada di luar cakupan tersebut, sehingga kebijakan Anda sendiri yang menentukan bagaimana kunci disimpan, dan penyedia perangkat lunak merupakan pilihan yang sah. Ingatlah apa yang Anda dapatkan: kode yang ditandatangani dengan cara ini hanya dipercaya pada mesin-mesin yang sudah mempercayai root internal Anda, dan di tempat lain Windows tetap memperlakukan penerbit sebagai tidak dikenal.

Penandatanganan uji coba dan persiapan. Permintaan perangkat lunak sudah cukup baik untuk sertifikat uji coba, dan untuk menyusun nilai-nilai subject yang tepat yang akan Anda gunakan kembali saat membuat permintaan sesungguhnya terhadap perangkat keras Anda.

Langkah 1: Buka snap-in Certificates

Tekan tombol Windows + R, ketik mmc, lalu tekan Enter. Anda juga dapat mengetik mmc di kotak pencarian taskbar dan membukanya dari sana. Terima permintaan User Account Control. Jendela Console1 yang kosong akan terbuka.

Klik File, lalu Add/Remove Snap-in. Pada daftar Available snap-ins, pilih Certificates dan klik Add.

Windows kemudian menanyakan store sertifikat mana yang harus dikelola oleh snap-in: My user account, Service account, atau Computer account. Pilihan ini lebih penting untuk sertifikat code signing dibandingkan sertifikat server web, karena menentukan di mana kunci itu berada dan store mana yang dicari oleh alat penandatanganan Anda:

• My user account menempatkan kunci di personal store milik pengguna yang sedang masuk. Ini adalah pilihan umum ketika seorang developer melakukan penandatanganan secara interaktif, karena signtool dari Microsoft secara default membuka store My milik pengguna saat ini.
• Computer account menempatkan kunci di machine store, yang cocok untuk build server tempat penandatanganan dijalankan di bawah akun layanan. Alat penandatanganan perlu diberi tahu agar mencari di sana: signtool menggunakan opsi /sm untuk machine store.

Jika Anda memilih My user account, klik Finish. Jika Anda memilih Computer account, klik Next, biarkan Local computer (the computer this console is running on) tetap terpilih, lalu klik Finish. Bagaimanapun caranya, klik OK untuk menutup jendela Add or Remove Snap-ins.

Ada dua jalan pintas yang melewati langkah snap-in sepenuhnya jika Anda tidak memerlukan console tersimpan: certmgr.msc langsung membuka store sertifikat pengguna saat ini, dan certlm.msc membuka store komputer lokal. Jika Anda menyusun console secara manual dan berencana kembali ke sana, gunakan File lalu Save untuk menyimpannya.

Langkah 2: Mulai permintaan khusus

Pada pohon console, perluas Certificates dan klik kanan folder Personal (atau folder Certificates di bawahnya, jika store tersebut sudah memiliki sertifikat). Pilih All Tasks, lalu Advanced Operations, lalu Create Custom Request. Perintah yang sama juga tersedia di menu Action jika Anda lebih suka menggunakannya.

Wizard Certificate Enrollment akan terbuka pada halaman Before You Begin. Klik Next.

Pada halaman Select Certificate Enrollment Policy, lihat di bawah judul Custom Request dan pilih Proceed without enrollment policy, lalu klik Next. Ini memberi tahu Windows untuk membuat permintaan mandiri untuk CA eksternal, bukan mendaftar terhadap template Active Directory.

Halaman Custom request memiliki tiga pengaturan:

• Template. Pilih (No template) CNG key. Ini menggunakan Key Storage Provider, yang merupakan cara penyedia perangkat keras modern mendaftarkan dirinya. (No template) Legacy key menggunakan penyedia CryptoAPI lama dan hanya diperlukan ketika perangkat atau aplikasi tertentu mengharuskannya.
• Suppress default extensions. Biarkan tidak tercentang kecuali Anda bermaksud hanya mengirimkan ekstensi yang Anda atur secara manual.
• Request format. Pilih PKCS #10. Setiap CA menerimanya. CMC digunakan untuk permintaan yang ditujukan pada sistem yang secara khusus memintanya.

Klik Next. Pada halaman Certificate Information, Anda akan melihat satu baris berlabel Custom request dengan status Available. Klik panah Details di sebelah kanan baris tersebut untuk memperluasnya, lalu klik tombol Properties yang muncul. Dialog Certificate Properties akan terbuka dengan empat tab: General, Subject, Extensions, dan Private Key.

Langkah 3: Masukkan detail subject

Pada tab General, ketikkan Friendly name dan, jika Anda mau, Description. Keduanya adalah label lokal yang membantu Anda menemukan sertifikat di store nantinya. Tidak satu pun merupakan bagian dari permintaan, dan tidak satu pun divalidasi.

Beralihlah ke tab Subject. Di sinilah identitas yang akan muncul sebagai penerbit perangkat lunak disusun. Di bawah Subject name, pilih entri dari drop-down Type, ketikkan teks yang sesuai pada kotak Value, lalu klik Add >. Setiap entri akan berpindah ke daftar di sebelah kanan, di mana Windows menampilkannya dalam bentuk singkat (CN=, O=, OU=, L=, S=, C=). Ulangi untuk masing-masing berikut ini:

• Common name (CN): nama terdaftar organisasi Anda, atau nama lengkap resmi individu untuk sertifikat individu. Ini adalah identitas yang dilihat pengguna ketika Windows menyebutkan nama penerbit.
• Organization (O): nama organisasi terdaftar yang menjadi pemilik sertifikat. Jika nama mengandung simbol seperti tanda “&”, tuliskan secara lengkap atau hilangkan, karena karakter semacam ini tidak diterima di kolom tersebut. “AB & C Corporation” menjadi “AB and C Corporation” atau “ABC Corporation”.
• Organizational unit (OU): departemen yang menangani pendaftaran, misalnya IT. Opsional.
• Locality (L): kota tempat organisasi terdaftar.
• State (S): provinsi atau negara bagian, ditulis lengkap. Gunakan Florida, bukan FL.
• Country (C): kode negara ISO dua huruf dari tempat organisasi terdaftar, misalnya US.

Masukkan detail yang sesuai persis dengan catatan resmi Anda, karena CA akan memvalidasinya terhadap sumber-sumber publik dan resmi sebelum menerbitkan apa pun. Ketidaksesuaian adalah alasan paling umum mengapa pesanan code signing terhenti.

Biarkan kotak Alternative name kosong. Subject Alternative Names mengidentifikasi server berdasarkan nama host, sedangkan sertifikat code signing mengidentifikasi penerbit, bukan mesin, sehingga tidak membawa entri DNS.

Langkah 4: Pilih penyedia, ukuran kunci, dan hash

Buka tab Private Key. Tab ini memuat beberapa grup yang dapat diperluas: Cryptographic Service Provider, Key options, Select Hash Algorithm, Select Signature Format, dan Key permissions. Klik sebuah judul untuk memperluasnya.

Perluas Cryptographic Service Provider terlebih dahulu, karena inilah pengaturan yang diaktifkan oleh Baseline Requirements. Daftar tersebut menampilkan setiap penyedia yang terpasang di komputer, masing-masing dengan kotak centang. Pastikan hanya penyedia yang benar-benar Anda inginkan yang tercentang:

• Untuk sertifikat code signing yang dipercaya secara publik, pilih penyedia yang termasuk milik token atau HSM Anda. Penyedia ini hanya muncul dalam daftar setelah driver atau minidriver perangkat terpasang, jadi hubungkan perangkat dan pasang perangkat lunaknya terlebih dahulu.
• RSA, Microsoft Software Key Storage Provider adalah opsi perangkat lunak. Gunakan hanya untuk CA internal atau sertifikat uji coba.
• Daftar tersebut juga memuat entri ECDSA seperti ECDSA_P256, Microsoft Software Key Storage Provider. Pastikan CA Anda mendukung ECDSA untuk code signing sebelum memilihnya, karena tidak semua produk mendukungnya.

Perluas Key options. Atur Key size menjadi 3072 atau 4096. RSA 3072 adalah batas minimum untuk code signing, dan permintaan yang dibuat dengan 2048 akan ditolak. Jika drop-down tidak menawarkan 3072 untuk penyedia yang Anda pilih, gunakan 4096.

Pada grup yang sama, biarkan Make private key exportable tidak tercentang. Ini adalah koreksi paling penting terhadap instruksi MMC yang lama. Kunci yang dapat diekspor dapat disalin keluar dari mesin sebagai file .pfx, yang justru merupakan hal yang ingin dicegah oleh persyaratan perangkat keras, dan jalur attestation secara eksplisit mensertifikasi bahwa kunci dibuat dengan cara yang tidak dapat diekspor. Satu-satunya alasan untuk mencentangnya adalah pengaturan penandatanganan internal di mana Anda harus memindahkan sertifikat dan kunci ke mesin lain, dan bahkan dalam kasus itu pun hal ini melemahkan kunci tersebut. Biarkan Allow private key to be archived juga tidak tercentang. Strong private key protection bersifat opsional dan membuat Windows meminta konfirmasi setiap kali kunci digunakan, yang masuk akal untuk kunci penandatanganan pada workstation bersama.

Perluas Select Hash Algorithm dan atur Hash Algorithm menjadi sha256. SHA-1 tidak diperbolehkan untuk sertifikat code signing.

Tab Extensions layak diperhatikan jika Anda mendaftar terhadap CA internal. Perluas Key usage dan tambahkan Digital signature, lalu perluas Extended Key Usage (application policies) dan tambahkan Code Signing. CA publik membangun sertifikat berdasarkan produk yang Anda pesan, bukan berdasarkan ekstensi dalam permintaan Anda, sehingga untuk pesanan publik tab ini tidak mengubah apa pun. CA internal mungkin mempertimbangkannya.

Klik OK untuk menutup Certificate Properties, lalu klik Next.

Langkah 5: Simpan permintaan

Wizard akan menanyakan Where do you want to save the offline request? Klik Browse, pilih folder yang Anda kelola, beri nama file seperti codesigning.req, dan konfirmasi. Selalu jelajahi (browse) ke folder daripada mengetik nama file kosong: tanpa jalur, permintaan akan mendarat di folder mana pun tempat console tersebut kebetulan sedang berjalan, yang jarang menjadi tempat yang Anda inginkan dan sulit ditemukan kembali.

Pada bagian File format, biarkan Base 64 tetap terpilih. Itu adalah bentuk teks yang ditempelkan oleh CA ke dalam kotak pendaftaran. Binary menulis DER mentah, yang ditolak oleh sebagian besar formulir pemesanan. Klik Finish.

Buka file tersebut di editor teks biasa mana pun, seperti Notepad, dan salin seluruh blok termasuk baris pertama dan terakhir:

-----BEGIN NEW CERTIFICATE REQUEST-----
MIIEbDCCA1QCAQAwZDELMAkGA1UEBhMCVVMx...
...base64 encoded request...
-----END NEW CERTIFICATE REQUEST-----

Alat pendaftaran Windows biasanya menulis susunan kata yang lebih panjang seperti ditunjukkan di atas, dengan kata NEW pada baris penanda, sementara OpenSSL menulis BEGIN CERTIFICATE REQUEST dan END CERTIFICATE REQUEST. Jika file Anda menggunakan bentuk yang lebih singkat, tidak ada yang salah: isinya adalah permintaan PKCS #10 yang sama dan Certificate Authority menerima keduanya. Salin persis apa yang Anda lihat dan jangan menulis ulang baris penanda.

Satu hal yang tidak dihasilkan oleh wizard adalah file private key yang bisa Anda simpan atau salin, dan panduan-panduan lama yang menyuruh Anda menyimpan file public key dan private key dengan aman sebenarnya sedang mendeskripsikan alat yang berbeda. MMC menyimpan private key baru di dalam Windows key store, di bawah akun yang Anda pilih pada langkah 1, hanya di komputer tersebut. Permintaan yang tertunda biasanya muncul di snap-in di bawah Certificate Enrollment Requests. Ada tiga konsekuensi yang mengikuti:

• Jangan menghapus permintaan yang tertunda sambil menunggu penerbitan. Menghapusnya akan membuang kunci, dan sertifikat yang diterbitkan kemudian menjadi tidak berguna.
• Selesaikan pesanan di komputer yang sama, dalam konteks akun yang sama. Permintaan yang dibuat di user store tidak dapat diselesaikan di machine store, atau sebaliknya.
• Jangan membangun ulang atau melakukan re-image pada mesin di antara pembuatan permintaan dan pemasangan sertifikat.

Langkah 6: Periksa permintaan sebelum mengirimkannya

Permintaan tidak dapat diedit setelah dibuat, jadi periksa sekarang daripada menemukan kesalahan ketik setelah validasi dimulai. Windows dapat membacanya kembali tanpa perangkat lunak tambahan apa pun. Buka Command Prompt di folder yang menyimpan file tersebut dan jalankan:

certutil -dump codesigning.req

Jika OpenSSL terpasang, perintah ini membaca file yang sama sekaligus memeriksa tanda tangan permintaan:

openssl req -noout -text -verify -in codesigning.req

Pastikan empat hal dalam output tersebut: subject mencantumkan negara, provinsi, kota, organisasi, dan common name persis seperti yang Anda maksudkan; public key berukuran 3072 bit atau lebih, atau menggunakan kurva ECDSA yang disetujui; algoritma tanda tangan adalah SHA-256; dan, dengan perintah OpenSSL, muncul baris verify OK, yang mengonfirmasi bahwa permintaan tersebut ditandatangani oleh private key yang sesuai. Anda juga dapat menempelkan blok tersebut ke CSR decoder untuk membacanya di browser.

Jika ada yang salah, buat permintaan baru mulai dari langkah 2. Untuk melihat penyedia mana saja yang tersedia di mesin, termasuk penyedia perangkat keras yang telah Anda pasang, jalankan:

certutil -csplist

Langkah 7: Pasang sertifikat yang diterbitkan pada mesin yang sama

Kirimkan blok Base 64 saat memesan sertifikat, selesaikan validasi yang diminta oleh CA, dan unduh sertifikat yang diterbitkan setelah tiba. Karena private key tetap berada di Windows key store, sertifikat tersebut harus dikembalikan ke store yang sama agar dapat digunakan.

Pada snap-in yang sama, klik kanan Personal, pilih All Tasks, lalu Import, dan arahkan wizard ke file tersebut. Windows akan mencocokkan sertifikat dengan kunci yang disimpan dari permintaan tersebut, dan entri yang tertunda di bawah Certificate Enrollment Requests akan hilang. Buka sertifikat setelahnya dan periksa apakah tab General menyatakan bahwa Anda memiliki private key yang sesuai dengan sertifikat ini. Jika baris tersebut tidak muncul, artinya penyandingan tidak terjadi, dan Anda dapat menautkannya kembali dengan nomor seri sertifikat:

certutil -repairstore My <serial-number>

Tambahkan opsi -user jika sertifikat tersebut milik pengguna saat ini, bukan milik mesin:

certutil -user -repairstore My <serial-number>

Dari sana, alat penandatanganan Anda akan mengambil sertifikat dari store tersebut. Ingatlah store yang Anda pilih pada langkah 1: signtool membaca store My milik pengguna saat ini kecuali Anda menyertakan opsi /sm untuk machine store.

Cara-cara lain untuk membuat permintaan yang sama dibahas dalam panduan CertReq, OpenSSL, Java Keystore, dan macOS Keychain Access. Anda mungkin juga tertarik dengan tutorial code signing yang lebih luas atau cara-cara lain untuk membuat CSR.

Pertanyaan yang Sering Diajukan