Panduan praktis penyimpanan sertifikat Windows — masukkan ke pengguna atau ke komputer?

“Setelah perangkat konfirmasi kualifikasi daring diganti, sertifikat klien dipasang ulang ke PC baru, lalu koneksi gagal.” “Di mesin pengembangan API bank tersambung, tetapi setelah dijadikan layanan Windows muncul ‘sertifikat tidak ditemukan’.” “Sertifikat yang terlihat di certmgr.msc dan yang terlihat di certlm.msc — mana yang asli, tidak jelas.” Konsultasi semacam ini rutin datang ketika kami mengerjakan integrasi Web API bersertifikat klien sebagai proyek kustom.

Konfirmasi kualifikasi daring di fasilitas medis, pengajuan elektronik, API perbankan, EDI dengan mitra. Sertifikat klien yang dulu hanya disentuh staf infrastruktur perusahaan besar, kini ditangani staf TI usaha kecil-menengah dan pengembang aplikasi bisnis. Insiden seputar sertifikat pun sebenarnya mengerucut ke beberapa pola. Salah tempat memasang, lupa izin kunci privat, lupa masa berlaku — tiga itu.

Artikel ini ditujukan kepada pengembang aplikasi bisnis yang memakai sertifikat klien, dan kepada staf TI yang diminta mengganti sertifikat. Porosnya adalah keputusan “masukkan ke penyimpanan pengguna atau penyimpanan komputer?” Dari situ artikel merangkai sekaligus struktur penyimpanan sertifikat Windows, pemberian izin kunci privat, inventaris masa berlaku dengan PowerShell, sampai kode pemakaian dari .NET. Isi merujuk informasi primer Microsoft Learn per Agustus 2026.

1. Kesimpulan dulu

• Penyimpanan sertifikat Windows ada dua jalur: pengguna (CurrentUser) dan komputer (LocalMachine). Penyimpanan pengguna berbeda per akun (di bawah registri HKEY_CURRENT_USER). Penyimpanan komputer bersama untuk seluruh PC (di bawah HKEY_LOCAL_MACHINE).¹²
• Alat pengelolanya juga dua. certmgr.msc membuka store pengguna saat ini; certlm.msc membuka store komputer lokal. Dari PowerShell: Cert:\CurrentUser dan Cert:\LocalMachine.³⁴
• Masukkan ke mana ditentukan oleh akun yang menjalankan program pemakai sertifikat itu. Aplikasi pengguna interaktif: penyimpanan pengguna. Eksekusi tanpa pengawasan di layanan Windows, IIS, atau Penjadwal Tugas: penyimpanan komputer, sebagai prinsip (tabel keputusan di bab 3).
• Penyebab “di pengembangan jalan, setelah dijadikan layanan tidak ditemukan” hampir selalu satu. Sertifikat yang pengembang pasang di penyimpanan penggunanya sendiri tidak terlihat dari CurrentUser layanan yang berjalan dengan akun lain (bab 3).
• Sertifikat dan kunci privat adalah dua hal berbeda. Hanya memasang ke penyimpanan komputer biasanya tidak membuat akun layanan dapat membaca kunci privat. Beri izin baca kepada akun eksekusi lewat Kelola kunci privat di certlm.msc.⁵
• Saat impor pfx, kunci privat secara default tidak dapat diekspor. Import-PfxCertificate mengambil kunci privat dalam bentuk tidak dapat diekspor ulang kecuali -Exportable ditetapkan. Ini bukan insiden, melainkan default yang memang diinginkan.⁶
• Kedaluwarsa dicegah dengan otomatisasi inventaris. Sertifikat yang kedaluwarsa dalam jumlah hari yang ditetapkan dapat diekstrak secara mekanis, misalnya Get-ChildItem Cert:\LocalMachine\My -ExpiringInDays 60.⁴
• Jika sidik jari (thumbprint) di-hardcode di kode atau konfigurasi, setiap pembaruan sertifikat akan membuatnya gagal. Sidik jari sertifikat baru pasti berubah. Mengeluarkannya ke konfigurasi plus periode paralel lama-baru adalah dasar desain (bab 5 dan 7).

Pada diagram, garis utuh menunjukkan relasi yang selalu berlaku dan garis putus-putus menunjukkan relasi bersyarat (syaratnya ada pada penjelasan masing-masing relasi di halaman rincian). Daftar lengkap relasi (total 41, beserta bukti dan tingkat kepastian) serta definisi konsep utama dikumpulkan di halaman rincian peta pengetahuan (dalam bahasa Jepang). Data: JSON-LD / Turtle

2. Gambaran penyimpanan sertifikat — dua lokasi dan store logis

2.1. Dua jalur: pengguna dan komputer

Penyimpanan sertifikat Windows terbagi besar ke dua “lokasi”.¹

• Penyimpanan sertifikat komputer (komputer lokal, LocalMachine): satu per PC, bersama untuk semua pengguna dan layanan di PC itu. Wujudnya di bawah registri HKEY_LOCAL_MACHINE\Software\Microsoft\SystemCertificates.²
• Penyimpanan sertifikat pengguna (pengguna saat ini, CurrentUser): berbeda per akun pengguna. Wujudnya di bawah HKEY_CURRENT_USER\Software\Microsoft\SystemCertificates, yaitu bagian dari profil pengguna.²

Selain itu ada juga store per akun layanan³, wujudnya kunci registri per nama layanan.² Yang perlu dipegang dulu di praktik adalah dua yang pertama.

Ada satu spesifikasi penting. Setiap store logis di penyimpanan pengguna, kecuali Pribadi, mewarisi isi store bernama sama di penyimpanan komputer dan menampilkannya.¹ Misalnya, jika sertifikat CA internal dipasang ke Otoritas Sertifikasi Akar Tepercaya di penyimpanan komputer, sertifikat itu juga muncul di Otoritas Sertifikasi Akar Tepercaya setiap pengguna. Sebaliknya, hanya store Pribadi yang tidak diwariskan, jadi sertifikat klien (yang memang dipasang ke store Pribadi) mengharuskan Anda sendiri memutuskan “siapa yang perlu melihatnya”. Asimetri inilah inti artikel ini.

flowchart TB
    subgraph LM["Komputer (LocalMachine)<br/>satu per PC · bersama semua pengguna dan layanan"]
        LMMY["Pribadi (My)"]
        LMROOT["Otoritas Sertifikasi Akar Tepercaya (Root)"]
        LMCA["Otoritas Sertifikasi Perantara (CA)"]
        LMTP["Penerbit Tepercaya (TrustedPublisher)"]
    end
    subgraph CU["Pengguna (CurrentUser)<br/>berbeda per akun"]
        CUMY["Pribadi (My)<br/>※ tidak diwariskan = Anda sendiri yang menentukan tempat memasang"]
        CUROOT["Otoritas Sertifikasi Akar Tepercaya (Root)"]
        CUCA["Otoritas Sertifikasi Perantara (CA)"]
        CUTP["Penerbit Tepercaya (TrustedPublisher)"]
    end
    LMROOT -.->|"isi diwariskan lalu terlihat"| CUROOT
    LMCA -.->|"diwariskan"| CUCA
    LMTP -.->|"diwariskan"| CUTP

2.2. Store logis utama

Di dalam tiap lokasi, store terbagi menurut peran. Folder yang terlihat di certmgr.msc / certlm.msc adalah itu; dari PowerShell atau perintah, nama internal bahasa Inggris yang dipakai.²⁴

2.3. Tiga jendela — certmgr.msc / certlm.msc / drive Cert:

Ada tiga cara melihat store yang sama.³⁴

• certmgr.msc: konsol pengelolaan yang membuka store pengguna saat ini.
• certlm.msc: konsol pengelolaan yang membuka store komputer lokal.
• Drive Cert: di PowerShell: store dapat dioperasikan seperti sistem berkas dalam hierarki Cert:\CurrentUser\... dan Cert:\LocalMachine\.... Sertifikat diidentifikasi dengan sidik jari.

Jika snap-in sertifikat ditambahkan secara manual ke mmc.exe, sasarannya dipilih dari tiga jenis: akun pengguna, akun komputer, akun layanan. Pengguna yang bukan administrator hanya dapat mengelola store akun penggunanya sendiri.³

Langkah pertama investigasi gangguan adalah menyamakan “store mana yang dilihat aplikasi” dengan “store mana yang Anda lihat”. Mengamati certmgr.msc sambil menelusuri gangguan layanan tidak akan pernah menjawab, karena yang dilihat berbeda.

3. Masukkan ke mana — tabel keputusan menurut bentuk eksekusi program

Kriterianya satu. Program pemakai sertifikat itu berjalan dengan akun siapa.

Jika ragu: yang berjalan tanpa pengawasan ke penyimpanan komputer, yang dioperasikan orang ke penyimpanan pengguna.

3.1. Anatomi insiden klasik — “di pengembangan jalan, setelah dijadikan layanan tidak ditemukan”

Insiden ini dapat direproduksi persis dengan langkah berikut.

1. Pengembang mengimpor pfx dengan mengklik ganda di PC-nya. Default wizard adalah “pengguna saat ini”, jadi sertifikat masuk ke penyimpanan pengguna akun pengembang.
2. Aplikasi saat pengembangan dijalankan dari Visual Studio, yaitu dengan akun pengembang, jadi membuka StoreLocation.CurrentUser menemukan sertifikat. Jalan.
3. Di server produksi didaftarkan sebagai layanan Windows. Layanan berjalan sebagai NETWORK SERVICE atau akun khusus.
4. CurrentUser yang dibuka kode layanan adalah penyimpanan pengguna akun eksekusi layanan. Itu kosong. “Sertifikat tidak ditemukan.”

flowchart TB
    subgraph DEV["Mesin pengembangan"]
        D1["Impor pfx dengan klik ganda<br/>default wizard: pengguna saat ini"] --> D2["Masuk ke penyimpanan pengguna<br/>akun pengembang"]
        D2 --> D3["Dijalankan dari Visual Studio<br/>= berjalan dengan akun pengembang"]
        D3 --> D4["Membuka CurrentUser: ketemu<br/>→ jalan"]
    end
    subgraph PROD["Server produksi"]
        P1["Didaftarkan sebagai layanan Windows<br/>akun eksekusi: NETWORK SERVICE, dll."] --> P2["CurrentUser yang dibuka kode adalah<br/>penyimpanan pengguna akun layanan"]
        P2 --> P3["Itu kosong<br/>→ 'sertifikat tidak ditemukan'"]
    end
    D4 -.->|"program yang sama dipasang"| P1

Intinya: penyimpanan pengguna “ada sebanyak jumlah akun”. Meski administrator membuka certmgr.msc dan mengonfirmasi “sudah terpasang, kan?”, itu store administrator sendiri, bukan store akun layanan. Penanganannya bukan salinan dadakan, melainkan memasang ulang ke penyimpanan komputer, dan menyamakan kode ke StoreLocation.LocalMachine. Pemberian izin di bab berikutnya termasuk satu paket.

4. Kunci privat dan hak akses — insiden klasik kedua

4.1. Sertifikat dan kunci privat adalah dua hal berbeda

Yang terlihat di daftar penyimpanan sertifikat adalah sertifikat (informasi publik), bukan kunci privat itu sendiri. Yang benar-benar diperlukan untuk autentikasi klien adalah pemrosesan tanda tangan dengan kunci privat, jadi “terlihat di daftar” dan “dapat dipakai” adalah masalah berbeda. Jika keduanya dicampur, gangguan yang tampilannya sulit dipahami muncul: “sertifikat ada tetapi handshake TLS gagal”, “error internal jenis Access Denied”.

4.2. Praktik impor pfx — dapat diekspor atau tidak adalah keputusan

Pasangan sertifikat dan kunci privat diserahterimakan sebagai berkas pfx (PKCS #12), dan dapat diambil ke store dengan Import-PfxCertificate.⁶

$pwd = Get-Credential -UserName '(masukkan kata sandi di bawah)' -Message 'Kata sandi PFX'
Import-PfxCertificate -FilePath C:\certs\client.pfx `
    -CertStoreLocation Cert:\LocalMachine\My -Password $pwd.Password

Yang penting di sini: kecuali -Exportable ditambahkan, kunci privat yang diambil tidak dapat diekspor ulang — itu perilaku default.⁶ Memasang semuanya sebagai dapat diekspor “agar nanti bisa dimigrasikan” adalah menambah satu jalur pengeluaran kunci privat. Operasikan dengan menyimpan pfx asli secara aman, dan kunci privat di store pada dasarnya tidak dapat diekspor — itu rekomendasi kami. Catatan: justru pfx asli dan kata sandinya yang sering dibiarkan teks biasa. Cara berpikirnya dirangkum di “Penyimpanan rahasia aplikasi Windows — menghindari pengaturan teks biasa dengan DPAPI” dan “Penanganan kredensial yang aman di PowerShell”.

4.3. Pemberian izin kunci privat kepada akun layanan

Kunci privat sertifikat yang dipasang di penyimpanan komputer biasanya secara default tidak dapat dibaca selain oleh administrator dan SYSTEM. Karena itu, layanan yang berjalan sebagai LocalSystem dapat membaca kunci privat dengan default, tetapi jika dijalankan dengan akun selain itu — NETWORK SERVICE, akun layanan khusus, identitas kumpulan aplikasi IIS — beri izin baca secara eksplisit kepada akun eksekusi. Langkahnya dapat dilakukan dari UI snap-in sertifikat.⁵

1. Buka certlm.msc (atau snap-in sertifikat yang sasarannya akun komputer).
2. Di Pribadi → Sertifikat, klik kanan sertifikat sasaran, lalu dari Semua tugas buka Kelola kunci privat.
3. Di tab Keamanan, tambahkan akun eksekusi (NETWORK SERVICE, akun layanan khusus, identitas kumpulan aplikasi IIS, dan semacamnya) dan izinkan Baca.⁵

Full Control tidak perlu. Jika hanya untuk tanda tangan, baca sudah cukup. Sebaliknya, memberi Full Control kepada Everyone karena tidak jalan adalah menurunkan kunci privat ke perlakuan setara kata sandi teks biasa, jadi mutlak dihindari. Penempatan ke penyimpanan komputer dan pemberian izin kunci privat selalu satu paket — cukup menuliskan ini di prosedur, insiden jenis ini hilang.

5. Mencegah insiden kedaluwarsa — inventaris, penggantian, buku besar

5.1. Inventaris dengan PowerShell

Masa berlaku sertifikat ada di properti NotAfter. Inventaris mekanis dapat dilakukan dengan Get-ChildItem terhadap drive Cert:.⁴

# Daftar store Pribadi di penyimpanan komputer, diurutkan menurut masa berlaku
Get-ChildItem Cert:\LocalMachine\My |
    Sort-Object NotAfter |
    Format-Table Thumbprint, Subject, NotAfter

# Hanya yang kedaluwarsa dalam 60 hari (0 mengeluarkan yang sudah kedaluwarsa)
Get-ChildItem -Path Cert:\LocalMachine\My -ExpiringInDays 60

-ExpiringInDays adalah parameter yang mengembalikan “sertifikat yang kedaluwarsa dalam jumlah hari yang ditetapkan”; 0 mengeluarkan sertifikat yang sudah kedaluwarsa.⁴ Jadikan ini tugas terjadwal bulanan yang mengelilingi semua server, lalu kumpulkan hasil ke email atau buku besar — hanya itu, insiden jenis “kedaluwarsa, dari Senin pagi konfirmasi kualifikasi tidak lolos” hampir dapat dicegah.

5.2. Langkah penggantian — periode paralel lama-baru dan jebakan sidik jari

Pembaruan sertifikat bukan “hapus lalu pasang”, melainkan “tambahkan dulu, lalu alihkan, konfirmasi, baru hapus”.

1. Impor sertifikat baru (pfx) ke store yang sama. Sidik jarinya berbeda, jadi yang lama dan yang baru dapat hidup bersama di store yang sama.
2. Beri izin kunci privat sertifikat baru (bab 4). Yang mudah dilupakan saat pembaruan adalah ini. Izin menempel per kunci privat sertifikat, jadi setelah sertifikat diganti, pemberian diulang.
3. Pemberitahuan ke sistem mitra (jika API memerlukan pendaftaran sertifikat sebelumnya) diselesaikan lebih dulu sambil terus beroperasi dengan sertifikat lama, dan pastikan periode paralel yang menerima baik yang lama maupun yang baru. Jika peralihan didahulukan, pihak mitra menolak sertifikat baru dan komunikasi produksi berhenti.
4. Alihkan konfigurasi aplikasi ke sertifikat baru, lalu konfirmasi operasi.
5. Setelah periode yang cukup, hapus sertifikat lama.

flowchart LR
    I["1. Impor pfx baru ke store yang sama<br/>(lama dan baru hidup bersama)"] --> P["2. Beri izin kunci privat<br/>sertifikat baru"]
    P --> R["3. Daftarkan sebelumnya ke mitra<br/>(lanjutkan operasi dengan sertifikat lama)"]
    R --> SW["4. Tulis ulang sidik jari di konfigurasi,<br/>alihkan, konfirmasi operasi"]
    SW --> DEL["5. Setelah periode paralel,<br/>hapus sertifikat lama"]

Jebakan terbesar saat ini adalah sidik jari yang tertulis di berkas konfigurasi atau kode. Sidik jari unik per sertifikat, jadi pasti berubah jika diperbarui. Jika satu tempat pun masih merujuk sidik jari lama, “sertifikat sudah diperbarui tetapi tidak bisa tersambung” terjadi. Yang pasti adalah mengelola di buku besar di mana sidik jari tertulis (konfigurasi aplikasi, pengikatan IIS, skrip, pemberitahuan ke mitra).

5.3. Anjuran buku besar sertifikat

Buku besar pun, pertama-tama satu lembar Excel sudah cukup. Minimal, buat kolom kegunaan / penerbit / subjek / sidik jari / tempat terpasang (nama server + store) / akun yang punya izin kunci privat / masa berlaku / tautan ke prosedur pembaruan / penanggung jawab, lalu cocokkan dengan hasil inventaris 5.1. Kenyataan insiden sertifikat bukan masalah teknis melainkan masalah “tidak seorang pun punya daftar”, jadi buku besar paling manjur.

6. Membaca verifikasi dan kegagalan — rantai dan distribusi akar

6.1. Dasar verifikasi rantai dan certutil

Error jenis “sertifikat ini tidak dipercaya” adalah keadaan rantai (jalur sertifikasi) dari sertifikat ujung sampai CA akar terputus di suatu tempat. Untuk mengisolasi masalah, certutil berguna.⁷

flowchart TB
    LEAF["Sertifikat ujung<br/>(sertifikat klien · sertifikat server)"] --> INT["Sertifikat CA perantara<br/>tempat: store Otoritas Sertifikasi Perantara (CA)"]
    INT --> ROOT["Sertifikat CA akar<br/>tempat: Otoritas Sertifikasi Akar Tepercaya (Root)"]
    INT -.->|"tidak dapat diperoleh<br/>(tidak dari penyajian, AIA, maupun store)"| E1["rantai tidak dapat disusun<br/>(penyebab klasik 1)"]
    ROOT -.->|"tidak didistribusikan"| E2["error 'tidak dipercaya'<br/>(penyebab klasik 2)"]
    LEAF -.->|"kedaluwarsa"| E3["error masa berlaku<br/>(penyebab klasik 3)"]

:: Bangun dan verifikasi rantai berkas sertifikat (sekaligus ambil URL pemeriksaan pencabutan)
certutil -urlfetch -verify client.cer

:: Jika aplikasi sasaran memakai penyimpanan pengguna, tambahkan -user agar konteks verifikasi sama
certutil -user -urlfetch -verify client.cer

:: Dump isi store (tambahkan -user untuk penyimpanan pengguna)
certutil -store My
certutil -user -store My

certutil -verify memverifikasi sertifikat, CRL, dan rantai; jika CACertFile tidak ditetapkan, ia menyusun rantai lengkap lalu memverifikasi.⁷ Keluarannya panjang, tetapi dapat dibaca di lapisan mana kepercayaan terputus, dan apakah informasi pencabutan diperoleh. Penyebab khas ada tiga: (1) sertifikat CA perantara tidak dapat diperoleh (mitra TLS tidak mengirimkannya, tidak dapat diambil dari informasi AIA sertifikat, dan tidak ada di store Otoritas Sertifikasi Perantara), (2) akar CA internal tidak didistribusikan ke Otoritas Sertifikasi Akar Tepercaya, (3) sertifikat itu sendiri kedaluwarsa. CA perantara juga dapat terselesaikan lewat penyajian dari mitra atau pengambilan otomatis via AIA, jadi penempatan ke store dipandang sebagai “salah satu cara memastikan”.

6.2. Distribusi akar CA internal dan self-signed dengan GPO/Intune

Jika memakai CA internal atau sertifikat self-signed untuk validasi, sertifikat akar itu perlu didistribusikan ke tiap PC. Bukan memasang manual satu per satu, melainkan menaikkan ke mekanisme distribusi.

• Lingkungan Active Directory (GPO): mengimpor sertifikat ke Otoritas Sertifikasi Akar Tepercaya di Konfigurasi Komputer\Kebijakan\Pengaturan Windows\Pengaturan Keamanan\Kebijakan Kunci Publik Kebijakan Grup akan mendistribusikannya ke PC sasaran.⁸
• Lingkungan yang dikelola Intune: distribusikan sertifikat CA akar/perantara dengan profil Sertifikat tepercaya. Di Windows, store tujuan distribusi (akar/perantara komputer, perantara pengguna) dapat dipilih.⁹

Seperti dinyatakan di 2.1, jika dipasang ke akar penyimpanan komputer, dipercaya dari semua pengguna.¹ Karena itu, risiko sebaliknya juga harus dilihat langsung. Operasi memasang sertifikat self-signed ke Otoritas Sertifikasi Akar Tepercaya adalah menanam titik kepercayaan baru di PC itu. Jika kunci privatnya bocor, itu menjadi pijakan untuk menerbitkan sertifikat yang menyamar sebagai situs atau perangkat lunak mana pun. Jika dijadikan operasi permanen, yang masuk akal adalah mendirikan CA internal yang melindungi kunci privat dengan tepat, atau mendekat ke sertifikat CA publik; akar self-signed prinsipnya “hanya lingkungan validasi, dengan batas waktu”.

7. Sudut pandang pengembang — memakai store dengan benar dari .NET

7.1. Mencari sidik jari dengan X509Store

Dari .NET, buka store dengan X509Store dan ambil sertifikat dengan Find.¹⁰¹¹

using System.Security.Cryptography.X509Certificates;

static X509Certificate2 GetClientCertificate(string thumbprint)
{
    using var store = new X509Store(StoreName.My, StoreLocation.LocalMachine);
    store.Open(OpenFlags.ReadOnly | OpenFlags.OpenExistingOnly);

    var found = store.Certificates.Find(
        X509FindType.FindByThumbprint, thumbprint, validOnly: true);

    if (found.Count == 0)
        throw new InvalidOperationException(
            $"Sertifikat tidak ditemukan: sidik jari={thumbprint}, " +
            $"lokasi={store.Location}\\{store.Name}");

    var cert = found[0];
    if (!cert.HasPrivateKey)
        throw new InvalidOperationException(
            $"Sertifikat ada, tetapi kunci privat tidak terhubung (misalnya impor " +
            $"dari .cer): sidik jari={thumbprint}, lokasi={store.Location}\\{store.Name}");

    return cert;
}

Keputusan bab 3 langsung tersambung ke sini. Kode yang berjalan sebagai layanan: StoreLocation.LocalMachine. Aplikasi interaktif: StoreLocation.CurrentUser. Satu lagi, perhatikan argumen ketiga Find, validOnly. true mengembalikan hanya sertifikat sah yang lolos verifikasi.¹¹ Itu asuransi agar tidak memegang sertifikat kedaluwarsa, tetapi sertifikat self-signed uji yang rantainya tidak dipercaya juga jatuh ke sisi “tidak ditemukan”, jadi saat “sudah terpasang tetapi tidak ditemukan” curigai juga di sini. Selain itu, pesan error saat tidak ditemukan, seperti contoh di atas, selalu sertakan store mana yang dicari. Waktu investigasi insiden bab 3 berubah drastis.

7.2. Memuat sertifikat klien ke HttpClient

Sertifikat yang diambil ditambahkan ke HttpClientHandler.ClientCertificates dan disajikan ke server. Koleksi ini adalah himpunan sertifikat yang disajikan ke server pada autentikasi klien berbasis sertifikat.¹²

var handler = new HttpClientHandler();
handler.ClientCertificates.Add(GetClientCertificate(thumbprint));

var client = new HttpClient(handler);
// Selanjutnya dipakai sebagai HttpClient biasa

Selain itu, di seri .NET Core, jika sertifikat punya atribut Key Usage, dokumentasi menyatakan secara eksplisit bahwa ia tidak dipakai untuk pengiriman permintaan kecuali mencakup “Digital Signature”.¹² Jika Anda berada di posisi meminta penerbitan sertifikat klien, sampaikan kegunaan (autentikasi klien) dengan benar. HttpClient juga menimbulkan kehabisan soket dan masalah mengikuti DNS jika pola pembuatannya salah. Desain membuat handler berumur panjang dibahas di “Jangan bungkus HttpClient dalam using”.

7.3. Masalah sidik jari yang di-hardcode gagal saat penggantian

Pencarian sidik jari pasti, tetapi jika sidik jari ditanam di kode, setiap pembaruan sertifikat memerlukan build dan rilis. Penanganan di desain ada tiga tahap berikut.

• Minimum: keluarkan sidik jari ke berkas konfigurasi (appsettings, dan semacamnya) agar dapat diganti tanpa rilis. Tempat konfigurasi dicatat di buku besar 5.3.
• Satu langkah maju: cari menurut nama subjek atau penerbit, kombinasikan dengan validOnly: true, dan pilih “yang saat ini sah dengan nama itu, NotAfter paling jauh”. Pada periode paralel lama-baru, otomatis beralih ke sertifikat baru. Namun ada risiko memegang sertifikat tidak disengaja bernama sama, jadi pasangkan konfirmasi penerbit dan keluaran log. Selain itu, peralihan otomatis ini hanya terbentuk jika mitra tidak memerlukan pendaftaran sertifikat sebelumnya. Pada API yang memerlukan pendaftaran sebelumnya (5.2), dapat beralih sendiri ke sertifikat yang baru diimpor tetapi belum terdaftar dan komunikasi berhenti, jadi tetaplah pada cara mengeluarkan ke konfigurasi yang beralih setelah konfirmasi pendaftaran selesai.
• Secara operasional: pada cara apa pun, sisakan di log saat mulai “sertifikat mana (sidik jari, masa berlaku) yang dipilih”. Baik investigasi gangguan maupun pencocokan buku besar, satu baris ini manjur.

8. Hubungan dengan sertifikat penandatanganan kode — store Penerbit Tepercaya

Yang ditangani sampai di sini adalah sertifikat untuk komunikasi (TLS), tetapi di penyimpanan sertifikat hidup dunia lain lagi — penandatanganan kode. Store Penerbit Tepercaya (TrustedPublisher) yang muncul di tabel 2.2 adalah titik temunya: tempat mendaftarkan sertifikat penerbit perangkat lunak bertanda tangan sebagai tepercaya. Ada di lokasi pengguna maupun komputer¹⁰, dan dipakai untuk operasi seperti mendistribusikan penerbit aplikasi distribusi internal ke TrustedPublisher tiap PC dengan GPO.

Bagi yang sebagai pihak yang mendistribusikan aplikasi memerlukan penanganan penandatanganan kode dan peringatan SmartScreen (“Windows telah melindungi PC Anda”), dirangkum di artikel terpisah “Alasan munculnya ‘Windows telah melindungi PC Anda’ di Windows”. Pengetahuan artikel ini (dua jalur store, distribusi akar) dapat dipakai apa adanya sebagai prasyarat.

9. Ringkasan

• Penyimpanan sertifikat ada dua jalur: pengguna (CurrentUser) dan komputer (LocalMachine). certmgr.msc / certlm.msc / drive Cert: adalah tiga jendela melihat hal yang sama. Langkah pertama investigasi adalah menyamakan “store mana yang sedang dibicarakan”.
• Tempat memasang ditentukan oleh akun yang menjalankan program. Eksekusi tanpa pengawasan (layanan, IIS, tugas) ke penyimpanan komputer; aplikasi interaktif ke penyimpanan pengguna, sebagai prinsip.
• “Di pengembangan jalan, di produksi tidak ditemukan” disebabkan penyimpanan pengguna pengembang dan penyimpanan pengguna akun layanan adalah dua hal berbeda. Diselesaikan dengan menyamakan ke penyimpanan komputer + StoreLocation.LocalMachine.
• Penempatan ke penyimpanan komputer dan pemberian izin baca di Kelola kunci privat adalah satu paket. Jangan lupa pemberian ulang saat pembaruan.
• Impor pfx secara default tidak dapat diekspor. -Exportable hanya saat benar-benar diperlukan. Sertakan juga penyimpanan pfx asli dan kata sandinya ke desain.
• Kedaluwarsa dicegah dengan inventaris berkala Get-ChildItem Cert: ... -ExpiringInDays dan buku besar sertifikat. Penggantian dalam urutan “tambah → alihkan → konfirmasi → hapus”; waspadai sidik jari di konfigurasi yang lupa diperbarui.
• Isolasi rantai dengan certutil -urlfetch -verify. Akar CA internal didistribusikan dengan GPO/Intune; operasi memasang self-signed ke akar hanya lingkungan validasi, dengan batas waktu.
• Di kode, keluarkan sidik jari ke konfigurasi, dan sisakan sertifikat yang dipilih di log. Hanya itu, penanganan gangguan akibat sertifikat jadi jauh berbeda.

Artikel terkait

• Alasan munculnya “Windows telah melindungi PC Anda” di Windows
• Penyimpanan rahasia aplikasi Windows — menghindari pengaturan teks biasa dengan DPAPI
• Penanganan kredensial yang aman di PowerShell — mengusir kata sandi teks biasa dari skrip
• Jangan bungkus HttpClient dalam using — komunikasi HTTP praktis aplikasi bisnis C#
• Apa yang terjadi saat kartu asuransi My Number disentuhkan — membaca konfirmasi kualifikasi daring dan integrasi rececon dari kode sumber ORCA

Area konsultasi terkait

KomuraSoft LLC menangani pengembangan aplikasi bisnis yang menyematkan integrasi Web API bersertifikat klien (API perbankan, konfirmasi kualifikasi daring, dan semacamnya), investigasi gangguan jenis “sertifikat tidak ditemukan” / “setelah diperbarui tidak bisa tersambung”, dan penataan prosedur penggantian sertifikat. Tidak apa-apa berkonsultasi dari tahap belum tahu store mana yang harus dilihat.

• Pengembangan aplikasi Windows
• Investigasi bug dan analisis penyebab
• Konsultasi teknis dan tinjauan desain
• Hubungi kami

Tautan referensi

Artikel terkait

Artikel terbaru dengan tag yang sama untuk mendalami topik-topik terdekat.

Topik terkait

Halaman-halaman ini menempatkan topik dalam konteks layanan dan keputusan yang lebih luas.

Layanan yang terkait dengan topik ini

Artikel ini berkaitan langsung dengan layanan berikut.

Pertanyaan yang sering diajukan

Pertanyaan yang sering muncul dalam konsultasi tentang topik artikel ini.

Apa perbedaan certmgr.msc dan certlm.msc?

Sasarannya berbeda. certmgr.msc membuka penyimpanan sertifikat pengguna yang sedang logon (pengguna saat ini, CurrentUser). certlm.msc membuka penyimpanan sertifikat komputer (komputer lokal, LocalMachine). Penyimpanan komputer dipakai bersama oleh semua pengguna dan layanan di PC itu, dan pengelolaannya memerlukan hak administrator. Pengguna yang bukan administrator hanya dapat mengelola penyimpanan penggunanya sendiri. Isi keduanya terbagi ke store logis seperti Pribadi dan Otoritas Sertifikasi Akar Tepercaya. Dari PowerShell, struktur yang sama terlihat sebagai Cert:\CurrentUser dan Cert:\LocalMachine.

Sertifikat klien sebaiknya masuk ke penyimpanan pengguna atau komputer?

Tentukan dari akun yang menjalankan program pemakai sertifikat itu. Aplikasi desktop yang diluncurkan pengguna interaktif: dasar adalah penyimpanan pengguna orang yang memakainya (Cert:\CurrentUser\My). Program yang berjalan tanpa pengawasan sebagai layanan Windows, kumpulan aplikasi IIS, atau Penjadwal Tugas: masukkan ke penyimpanan komputer (Cert:\LocalMachine\My), lalu beri izin baca kunci privat kepada akun eksekusi. Penyimpanan pengguna berbeda per akun, jadi sertifikat yang pengembang pasang di penyimpanan penggunanya sendiri tidak terlihat dari layanan yang berjalan dengan akun lain. Itu penyebab klasik insiden "di pengembangan jalan, di produksi tidak ditemukan".

Jika layanan Windows tidak menemukan atau tidak dapat memakai sertifikat, apa yang harus diperiksa?

Pemeriksaan dua tahap. Pertama, store mana yang dibuka. Jika kode membuka StoreLocation.CurrentUser, itu penyimpanan pengguna akun eksekusi layanan — bukan store administrator yang terlihat di certmgr.msc. Pindahkan sertifikat ke penyimpanan komputer, dan samakan kode ke StoreLocation.LocalMachine. Kedua, apakah kunci privat dapat dibaca. Terlihat di daftar sertifikat dan dapat memakai kunci privat adalah dua hal berbeda. Kunci privat di penyimpanan komputer biasanya secara default hanya dapat diakses administrator dan SYSTEM. Dari certlm.msc, buka Kelola kunci privat pada sertifikat sasaran, lalu beri Baca kepada akun eksekusi layanan (NETWORK SERVICE, dan semacamnya).

Bagaimana menemukan sertifikat yang akan kedaluwarsa lebih dulu dengan PowerShell?

Inventaris dengan Get-ChildItem terhadap drive Cert:. Contohnya Get-ChildItem Cert:\LocalMachine\My | Sort-Object NotAfter | Format-Table Thumbprint, Subject, NotAfter menampilkan store Pribadi di penyimpanan komputer menurut masa berlaku. Parameter -ExpiringInDays mengekstrak hanya sertifikat yang kedaluwarsa dalam jumlah hari yang ditetapkan; 0 mengeluarkan yang sudah kedaluwarsa. Jadikan operasi bulanan di semua server, lalu cocokkan hasilnya dengan buku besar sertifikat. Insiden jenis "kedaluwarsa, dari pagi tidak bisa tersambung" hampir dapat dicegah.

Profil penulis

Halaman perkenalan penulis artikel.

Go Komura

Direktur KomuraSoft LLC

Berspesialisasi dalam pengembangan perangkat lunak Windows, konsultasi teknis, dan investigasi bug, terutama pada proyek dengan sistem yang sudah ada dan bug yang sulit direproduksi.