it-swarm-id.com

Daftar periksa untuk membangun Otoritas Sertifikat Menengah & Menengah (CA)

Microsoft mengizinkan CA untuk menggunakan Cryptography Next Generation (CNG) dan menyarankan masalah ketidakcocokan untuk klien yang tidak mendukung suite ini.

Berikut adalah gambar pengaturan kriptografi default untuk 2008 R2 CA. Mesin ini adalah Standalone CA yang terhubung dengan non-domain:

Default Cryptography settings

Berikut adalah penyedia yang diinstal. Penyedia CNG ditandai dengan tanda #

enter image description here

Maksud saya adalah memiliki Root-CA offline untuk keperluan umum dan beberapa CA perantara yang melayani tujuan tertentu (khusus MSFT vs Unix vs SmartCard dll)

Apa pengaturan ideal untuk Root Certificate dengan masa berlaku 5, 10, dan 15 tahun?

  1. CSP
  2. Sertifikat Penandatanganan
  3. Panjang Karakter Kunci

Karena ini adalah RootCA, lakukan salah satu parameter yang memengaruhi CPU (perangkat seluler) berdaya rendah

25

Catatan: Ini adalah ringkasan (sangat sangat panjang) dari berbagai rekomendasi dan tindakan yang Microsoft, NIST, dan para ahli PKI dan kriptografi terkenal lainnya mengatakan. Jika Anda melihat sesuatu yang memerlukan revisi sekecil apa pun, beri tahu saya.

Sebelum saya mengkonfigurasikan CA dan subsnya, ada baiknya mengetahui bahwa meskipun CryptoAPI MSFT membutuhkan root yang ditandatangani sendiri, beberapa perangkat lunak non-MSFT dapat mengikuti RFC 3280 dan memungkinkan CA mana pun menjadi root tepercaya untuk keperluan validasi. Salah satu alasannya mungkin karena perangkat lunak non-MSFT lebih memilih panjang kunci yang lebih rendah.

Berikut adalah beberapa catatan & panduan konfigurasi tentang pengaturan CA ROOT dan Subs:

Menyimpan Kunci Pribadi CA

Panjang Kunci

Kedaluwarsa

Algoritma & Panjang kunci dapat mempengaruhi seberapa lama Anda ingin sertifikat valid, karena mereka secara efektif menentukan berapa lama waktu yang diperlukan penyerang retak, yaitu semakin kuat kriptografi, semakin lama Anda dipersiapkan untuk memiliki sertifikat yang valid untuk

Salah satu pendekatan adalah menetapkan apa validitas terpanjang yang akan Anda perlukan untuk sertifikat entitas akhir, gandakan untuk penerbitan ca, dan kemudian gandakan lagi untuk root ca (dalam dua tingkat). Dengan pendekatan ini Anda akan secara rutin memperbarui setiap sertifikat ca ketika setengah dari masa pakainya tercapai - ini karena ca tidak dapat menerbitkan sertifikat dengan tanggal kedaluwarsa setelah sertifikat ca itu sendiri.

Nilai yang sesuai hanya dapat benar-benar ditentukan oleh organisasi & kebijakan keamanan Anda, tetapi biasanya root ca akan memiliki masa berlaku sertifikat 10 atau 20 tahun.

Jika Anda mengkhawatirkan kompatibilitas, tetapkan tanggal kedaluwarsa di bawah 2038. Ini karena sistem yang menyandikan data sebagai detik sejak 1 Januari 1970 melalui bilangan bulat 32 bit yang ditandatangani. Baca lebih lanjut tentang masalah ini di sini.

Memilih Hash

Terutama:

  • Windows 2003 dan klien XP mungkin perlu tambalan untuk Algoritma SHA2 yang mencakup SHA256, SHA384, dan SHA512. Lihat informasi teknis lainnya

  • Authenticode dan S/MIME dengan hashing SHA2 tidak didukung pada XP atau 2003

  • "Mengenai dukungan SHA-224, SHA-224 menawarkan keamanan yang lebih sedikit daripada SHA-256 tetapi membutuhkan jumlah sumber daya yang sama. Juga SHA-224 pada umumnya tidak digunakan oleh protokol dan aplikasi. Standar N Suite B juga tidak memasukkannya." sumber

  • "Jangan menggunakan suite SHA2 dimanapun dalam hirarki CA jika Anda berencana untuk memiliki XP baik mempercayai sertifikat, memvalidasi sertifikat, menggunakan sertifikat dalam validasi berantai, atau menerima sertifikat dari CA. Meskipun XP SP3 memungkinkan validasi sertifikat yang menggunakan SHA2 dalam hirarki CA, dan KB 968730 memungkinkan pendaftaran terbatas sertifikat yang ditandatangani oleh CA menggunakan SHA2, setiap penggunaan tanda tangan diskrit menghalangi = XP seluruhnya. "( sumber )

Memilih Penyedia Kriptografi

Aktifkan pembuatan nomor seri acak

Pada 2012, ini diperlukan jika Anda menggunakan MD5 sebagai hash. Ini masih ide bagus jika SHA1 atau lebih besar digunakan. Lihat juga Windows 2008R2 ini "how to" untuk informasi lebih lanjut.

Buat Pernyataan Praktik Sertifikat

Pernyataan praktik sertifikat adalah pernyataan praktik yang TI gunakan untuk mengelola sertifikat yang dikeluarkannya. Ini menjelaskan bagaimana kebijakan sertifikat organisasi ditafsirkan dalam konteks arsitektur sistem organisasi dan prosedur operasinya. Departemen TI bertanggung jawab untuk mempersiapkan dan memelihara pernyataan praktik sertifikat. ( sumber )

CATATAN: Dalam beberapa situasi, seperti ketika tanda tangan digital digunakan pada kontrak yang mengikat, pernyataan praktik sertifikat juga dapat dianggap sebagai pernyataan hukum tentang tingkat keamanan yang disediakan dan perlindungan yang digunakan untuk menetapkan dan mempertahankan tingkat keamanan .

Untuk bantuan menulis pernyataan CPS, di sini adalah "Job Aid" yang diproduksi Microsoft

Praktik Terbaik: Meskipun dimungkinkan untuk menempatkan teks bentuk bebas ke bidang ini (lihat notice di bawah), solusi ideal adalah menggunakan URL. Ini memungkinkan kebijakan diperbarui tanpa mengeluarkan kembali sertifikat, itu juga mencegah kembung yang tidak dibutuhkan dari toko sertifikat.

[LegalPolicy]
OID = 1.3.6.1.4.1.311.21.43
Notice = "Legal policy statement text"
URL = "http://www.example.Microsoft.com/policy/isspolicy.asp"

Kebijakan Sertifikat

Juga dikenal sebagai kebijakan penerbitan, atau kebijakan jaminan (dalam MSFT), ini adalah definisi sendiri OID yang menggambarkan jumlah kepercayaan yang harus dimasukkan ke dalam sertifikat Anda (tinggi, med, rendah, dll) . Lihat jawaban StackExchange ini untuk cara menggunakan bidang ini dengan benar.

Pastikan Kebijakan Aplikasi dan Kebijakan EKU cocok

Kebijakan Aplikasi adalah konvensi Microsoft opsional. Jika Anda mengeluarkan sertifikat yang menyertakan kebijakan aplikasi dan ekstensi EKU, pastikan kedua ekstensi tersebut berisi pengidentifikasi objek yang identik.

Aktifkan pemeriksaan CRL

Biasanya, Windows Server 2003 CA akan selalu memeriksa pencabutan semua sertifikat dalam hirarki PKI (kecuali sertifikat CA root) sebelum mengeluarkan sertifikat entitas akhir. Untuk menonaktifkan fitur ini, gunakan perintah berikut pada CA, dan kemudian restart layanan CA:

 certutil –setreg ca\CRLFlags +CRLF_REVCHECK_IGNORE_OFFLINE  

Titik Distribusi CRL

Bimbingan Khusus untuk Root CAs

  • Ini opsional di Root CA, dan jika dilakukan secara tidak benar ini dapat mengekspos kunci pribadi Anda .

  • Semua publikasi CRL dilakukan secara manual dari RootCA offline ke semua sub-CA lainnya. Alternatifnya adalah gunakan kabel audio untuk memfasilitasi komunikasi satu arah dari Root ke Sub CA's

  • Sangat bisa diterima jika Root CA mengeluarkan lokasi CRL yang berbeda untuk setiap sertifikat yang dikeluarkan kepada bawahan CA.

  • Memiliki CRL pada dasarnya adalah praktik terbaik jika dua PKI saling mempercayai dan pemetaan kebijakan dilakukan. Ini memungkinkan sertifikat untuk dicabut.

Mendapatkan CRL "benar" cukup penting karena tergantung pada setiap aplikasi untuk melakukan pemeriksaan CRL. Misalnya, kartu pintar masuk pada pengontrol domain selalu memberlakukan pemeriksaan pencabutan dan akan menolak acara masuk jika pemeriksaan pencabutan tidak dapat dilakukan atau gagal.

Catatan Jika ada sertifikat dalam rantai tidak dapat divalidasi atau ditemukan dicabut, seluruh rantai mengambil status dari satu sertifikat itu.

  • Root CA yang ditandatangani sendiri tidak boleh mencantumkan CDP apa pun. Sebagian besar aplikasi windows tidak mengaktifkan flag CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT dan karenanya mengabaikan CDP ( ini adalah mode validasi default ). Jika flag diaktifkan, dan CDP kosong untuk sertifikat root yang ditandatangani sendiri, tidak ada kesalahan yang dikembalikan.

  • Jangan gunakan HTTPS dan LDAPS. URL ini tidak lagi didukung sebagai referensi titik distribusi. Alasannya adalah bahwa HTTPS dan LDAPS URL menggunakan sertifikat yang mungkin atau mungkin tidak dicabut. Proses pemeriksaan pencabutan dapat menghasilkan loop pencabutan ketika HTTPS atau LDAPS URL digunakan. Untuk menentukan apakah sertifikat dicabut, CRL harus diambil. Namun, CRL tidak dapat diambil kecuali status pencabutan sertifikat yang digunakan oleh HTTPS atau LDAPS ditentukan.

  • Pertimbangkan untuk menggunakan HTTP alih-alih LDAP- Meskipun AD DS memungkinkan publikasi CRL ke semua pengontrol domain di hutan, implementasikan HTTP alih-alih LDAP untuk publikasi informasi pencabutan. Hanya HTTP yang memungkinkan penggunaan ETag dan Cache-Control: Max-age header memberikan dukungan yang lebih baik untuk proxy dan informasi pencabutan yang lebih tepat waktu. Selain itu, HTTP memberikan dukungan heterogen yang lebih baik karena HTTP didukung oleh sebagian besar klien perangkat Linux, UNIX, dan jaringan.

  • Alasan lain untuk tidak menggunakan LDAP adalah karena jendela pencabutan menjadi lebih kecil. Saat menggunakan AD LDAP untuk mereplikasi informasi CA, jendela pencabutan tidak kurang dari waktu untuk semua situs dalam AD untuk mendapatkan pembaruan CA. Seringkali replikasi ini dapat memakan waktu hingga 8 jam ... yaitu 8 jam hingga akses pengguna kartu pintar dicabut. 'Todo: waktu refresh CRL baru yang disarankan adalah: ????? `

  • Jadikan semua URL sangat tersedia (alias tidak menyertakan LDAP untuk host eksternal). Windows akan memperlambat proses validasi hingga 20 detik dan coba lagi koneksi yang gagal berulang kali setidaknya setiap 30 menit. Saya menduga bahwa Pre-fetching akan menyebabkan ini terjadi bahkan jika pengguna tidak secara aktif menggunakan situs ini.

  • Pantau ukuran CRL Anda. Jika objek CRL begitu besar sehingga CryptoAPI tidak dapat mengunduh objek dalam ambang batas waktu maksimum yang diberikan, kesalahan "pencabutan offline" dikembalikan dan objek pengunduhan dihentikan.

Catatan: Distribusi CRL melalui HTTP dengan Dukungan ETAG dapat menyebabkan masalah dengan IE6 saat menggunakan Windows 2003/IIS6, di mana koneksi TCP terus reset.

  • (Opsional) Aktifkan CRL Terkini : Ekstensi tidak kritis ini mencantumkan penerbit dan lokasi untuk mengambil CRL delta. Jika atribut “CRL segar” tidak ada dalam CRL atau dalam sertifikat, maka CRL dasar akan diperlakukan sebagai CRL biasa, bukan sebagai bagian dari pasangan CRL base/delta CRL.

Microsoft CA tidak memasukkan ekstensi "CRL segar" ke dalam sertifikat yang dikeluarkan. Namun, dimungkinkan untuk menambahkan ekstensi "CRL segar" ke sertifikat yang diterbitkan. Anda harus menulis kode untuk menambahkannya ke permintaan, menulis modul kebijakan khusus, atau menggunakan certutil –setextension atas permintaan yang tertunda. Untuk informasi lebih lanjut tentang pendaftaran sertifikat tingkat lanjut, lihat dokumentasi "Pendaftaran dan Manajemen Sertifikat Tingkat Lanjut" di situs Web Microsoft

Peringatan Jika delta CRL diaktifkan di CA, CRL dasar dan delta CRL harus diperiksa untuk menentukan status pencabutan sertifikat. Jika salah satu dari keduanya, atau keduanya, tidak tersedia, mesin rantai akan melaporkan bahwa status pencabutan tidak dapat ditentukan, dan aplikasi dapat menolak sertifikat.

Ukuran dan pemeliharaan CRL (Partisi CRL)

CRL akan bertambah 29 byte untuk setiap sertifikat yang dicabut. Dengan demikian, sertifikat yang dicabut akan dihapus dari CRL ketika sertifikat mencapai tanggal kedaluwarsa aslinya.

Karena memperbarui sertifikat CA menyebabkan CRL baru/kosong dihasilkan, Penerbit CA dapat mempertimbangkan memperbarui CA dengan kunci baru setiap sertifikat 100-125K untuk mempertahankan ukuran CRL yang wajar. Nomor penerbitan ini didasarkan pada asumsi bahwa sekitar 10 persen dari sertifikat yang diterbitkan akan dicabut sebelum tanggal kedaluwarsanya. Jika tingkat pencabutan aktual atau yang direncanakan lebih tinggi atau lebih rendah untuk organisasi Anda, sesuaikan strategi pembaruan kunci yang sesuai. Info lebih lanjut

Juga pertimbangkan mempartisi CRL lebih sering jika kedaluwarsa lebih dari 1 atau dua tahun, karena kemungkinan pencabutan meningkat.

Kelemahan dari ini adalah peningkatan waktu startup, karena setiap sertifikat divalidasi oleh server.

Peringatan Keamanan CRL

Jika menggunakan CRL, jangan menandatangani CRL dengan MD5. Itu juga ide yang bagus untuk tambahkan pengacakan ke kunci penandatanganan CRL.

Akses Informasi Otoritas

Bidang ini memungkinkan subsistem validasi Sertifikat untuk mengunduh sertifikat tambahan sesuai kebutuhan jika tidak ada di komputer lokal.

  • Root CA yang ditandatangani sendiri tidak boleh mencantumkan lokasi AIA ( lihat alasannya di sini )

  • Maksimal lima URL diizinkan dalam ekstensi AIA untuk setiap sertifikat dalam rantai sertifikat. Selain itu, maksimum 10 URL untuk seluruh rantai sertifikat juga didukung. Batasan jumlah URL ini ditambahkan untuk mengurangi potensi penggunaan referensi "Akses Info Otoritas" dalam penolakan serangan layanan.

  • Jangan gunakan HTTP [~ # ~] s [~ # ~] dan LDAP [~ # ~] s [~ # ~] . URL ini tidak lagi didukung sebagai referensi titik distribusi. Alasannya adalah bahwa HTTPS dan LDAPS URL menggunakan sertifikat yang mungkin atau mungkin tidak dicabut. Proses pemeriksaan pencabutan dapat menghasilkan loop pencabutan ketika HTTPS atau LDAPS URL digunakan. Untuk menentukan apakah sertifikat dicabut, CRL harus diambil. Namun, CRL tidak dapat diambil kecuali status pencabutan sertifikat yang digunakan oleh HTTPS atau LDAPS ditentukan.

Aktifkan Validasi OCSP

Responden OCSP secara konvensional berlokasi di: http://<fqdn of the ocsp responder>/ocsp. URL ini perlu diaktifkan di AIA. Lihat instruksi ini untuk Windows.

Ketahuilah bahwa validasi OCSP penuh tidak aktif secara default (meskipun harus "aktif" untuk sertifikat EV sesuai spesifikasi). Selain itu, mengaktifkan pemeriksaan OCSP menambah latensi ke koneksi awal

Lebih banyak sistem yang aman ingin aktifkan pemantauan OCSP di sisi klien atau server

Durasi cache OCSP

Semua tindakan OCSP terjadi melalui protokol HTTP dan karenanya tunduk pada aturan cache proxy HTTP khas.

Khususnya Max-age header menentukan waktu maksimum dimana server proxy atau klien akan menembolok respons CRL atau OCSP sebelum menggunakan GET bersyarat untuk menentukan apakah objek telah berubah. Gunakan informasi ini untuk mengonfigurasi server web untuk mengatur tajuk yang sesuai. Lihat di bagian lain halaman ini untuk perintah khusus AD-IIS untuk ini.

Menentukan kebijakan dalam sertifikat yang diterbitkan

Induk CA menentukan apakah akan mengizinkan kebijakan sertifikat CA dari sub CA. Dimungkinkan untuk menetapkan pengaturan ini ketika penerbit atau kebijakan aplikasi perlu dimasukkan dalam sub CA.

Kebijakan contoh termasuk EKU untuk SmartCard, Otentikasi, atau otentikasi SSL/Server.

  • Waspadalah terhadap sertifikat tanpa Certificate Policies ekstensi karena dapat memperumit Pohon Kebijakan. Lihat RFC 5280 untuk informasi lebih lanjut

  • Ketahuilah bahwa pemetaan kebijakan dapat menggantikan kebijakan lain di jalur

  • Ada kebijakan khusus yang disebut anypolicy yang mengubah pemrosesan

  • Ada ekstensi yang mengubah anypolicy

  • Jika Anda menggunakan kebijakan sertifikat, pastikan untuk menandainya sebagai critical jika tidak dihitung valid_policy_tree menjadi kosong, mengubah kebijakan menjadi komentar yang dimuliakan.

Pantau penegakan panjang DN

Spesifikasi CCITT asli untuk bidang OU mengatakan itu harus dibatasi hingga 64 karakter. Biasanya, CA memberlakukan standar panjang nama x.500 pada ekstensi subjek untuk semua permintaan. Ada kemungkinan bahwa jalur OU yang dalam dapat melebihi batasan panjang normal.

Cross Distribution Distribution Points

Fitur ini membantu ketika lingkungan perlu menginstal dua PKI, satu untuk perangkat keras/lunak lama yang tidak mendukung kriptografi modern, dan PKI lain untuk tujuan yang lebih modern.

Batasi EKU

Berbeda dengan RFC 5280 yang menyatakan "secara umum, [sic] ekstensi EKU hanya akan muncul di sertifikat entitas akhir." Itu ide yang baik untuk dimasukkan kendala pada penggunaan CA Key .

Sertifikat CA yang berdiri sendiri khas akan berisi izin untuk membuat Tanda Tangan Digital, Penandatanganan Sertifikat, dan penandatanganan CRL sebagai nilai kunci. Ini adalah bagian dari masalah dengan masalah keamanan FLAME.

Implementasi kartu pintar MSFT membutuhkan salah satu EKU berikut dan mungkin perbaikan terbar

  • Kartu pintar Microsoft EKU
  • Kriptografi Kunci Publik untuk Klien Otentikasi Awal (PKINIT) EKU, seperti yang didefinisikan dalam PKINIT RFC 4556

Ini juga memiliki kendala menarik seputar memvalidasi EKU (tautan tbd).

Jika Anda tertarik untuk memiliki batasan EKU, Anda akan melihat jawaban ini mengenai OID dan ini terkait sertifikat yang dibatasi

Gunakan hati-hati dengan Kendala Dasar "Path"

Batasan Dasar harus menjelaskan apakah sertifikat merupakan "entitas akhir" atau tidak . Menambahkan kendala jalur ke CA perantara mungkin tidak berfungsi seperti yang diharapkan karena ini merupakan konfigurasi yang tidak umum dan klien mungkin tidak menghargainya.

Subordinasi Berkualitas untuk CA Menengah

  • Untuk membatasi jenis sertifikat, subCA dapat menawarkan lihat tautan ini , dan yang ini

  • Jika subordinasi yang memenuhi syarat dilakukan, mencabut root yang bertanda silang mungkin sulit karena root tidak memperbarui CRL secara rutin.

Pengidentifikasi Kunci Otoritas/Pengidentifikasi Kunci Subjek

Catatan Jika ekstensi AKI sertifikat berisi KeyID, CryptoAPI mengharuskan sertifikat penerbit berisi SKI yang cocok. Ini berbeda dari RFC 3280 di mana pencocokan SKI dan AKI opsional . (todo: Mengapa seseorang memilih untuk menerapkan ini?)

AKI matching to find key parent

Berikan Root dan CA nama yang bermakna

Orang-orang akan berinteraksi dengan sertifikat Anda saat mengimpornya, meninjau sertifikat yang diimpor, dan pemecahan masalah. Praktik yang direkomendasikan MSFT dan persyaratan adalah bahwa root memiliki nama yang bermakna yang mengidentifikasi organisasi Anda dan bukan sesuatu yang abstrak dan umum seperti CA1.

Bagian selanjutnya ini berlaku untuk nama Intermediate/subCA's yang akan dibatasi untuk tujuan tertentu: Otentikasi vs Penandatanganan vs Enkripsi

Anehnya, pengguna akhir dan teknisi yang tidak mengerti nuansa PKI akan berinteraksi dengan nama server yang Anda pilih lebih sering daripada yang Anda pikirkan jika Anda menggunakan S/MIME atau tanda tangan digital (dll).

Saya pribadi berpikir itu ide yang baik untuk mengubah nama sertifikat yang dikeluarkan menjadi sesuatu yang lebih ramah pengguna seperti "Company Signer 1" di mana saya bisa melihat sekilas

  • Siapa tanda tangan yang akan datang (Texas A&M atau saingan mereka)
  • Untuk apa ini digunakan? Enkripsi vs Penandatanganan

Penting untuk mengetahui perbedaan antara pesan yang dienkripsi antara dua pihak, dan satu yang ditandatangani. Salah satu contoh di mana ini penting adalah jika saya bisa membuat penerima mengulangi pernyataan yang saya kirim kepada mereka. Pengguna A dapat memberi tahu pengguna B "A, saya berhutang $ 100" kepada Anda. Jika B menanggapi dengan gema pesan itu dengan kunci yang salah, maka mereka secara efektif diaktakan secara digital (vs hanya mengenkripsi) hutang $ 100 fiktif.

Berikut adalah contoh dialog pengguna untuk S/MIME . Harapkan UI yang serupa untuk sertifikat berbasis Brower. Perhatikan bagaimana nama Penerbit tidak ramah pengguna.

Select a SMIME certificate.. really?

Pengkodean Alternatif

Catatan: Berbicara tentang nama, jika tautan apa pun dalam rantai menggunakan penyandian alternatif, maka klien mungkin tidak dapat memverifikasi bidang penerbit ke subjek. Windows tidak menormalkan string ini selama perbandingan jadi pastikan nama-nama CA identik dari perspektif biner (yang bertentangan dengan rekomendasi RFC).

Name matching to find key parent

Penyebaran B/Keamanan Tinggi/Suite

  • Inilah informasi mengenai algoritme Suite B yang didukung pada Windows 2008 dan R2

    RAHASIA TOP RAHASIA ALGORITMA

    Enkripsi: Standar Lanjutan (AES) 128 bit, 256 bit

    Tanda Tangan Digital: Kurva Elliptic Digital Signature Algorithm (ECDSA) 256 bit. Kurva 384 bit

    Pertukaran Kunci: Kurva 256 bit Elliptic Diffie-Hellman (ECDH). Kurva 384 bit

    Hashing: Secure Hash Algorithm (SHA) SHA-256 SHA-384

  • Untuk kepatuhan Suite B, ECDSA_P384#Microsoft Software Key Service Provider serta 384 ukuran kunci dan SHA384 karena algoritma hash juga dapat dipilih jika tingkat klasifikasi yang diinginkan adalah Rahasia Top. Pengaturan yang sesuai dengan tingkat klasifikasi yang diperlukan harus digunakan. ECDSA_P521 juga tersedia sebagai opsi. Meskipun penggunaan kurva ECC 521 bit dapat melebihi persyaratan kriptografis Suite B, karena ukuran kunci non-standar, 521 bukan bagian dari spesifikasi resmi Suite B.

PKCS # 1 v2.1

Lindungi port Microsoft CA DCOM

Windows Server 2003 CA tidak menerapkan enkripsi pada antarmuka ICertRequest atau ICertAdmin DCOM secara default. Biasanya, pengaturan ini tidak diperlukan kecuali dalam skenario operasional khusus dan tidak boleh diaktifkan. Hanya mesin Windows Server 2003 yang secara default mendukung enkripsi DCOM pada antarmuka ini. Sebagai contoh, Windows XP klien tidak akan secara default memberlakukan enkripsi pada permintaan sertifikat ke Windows Server 2003 CA. sumber

Penyimpanan kunci pribadi CNG vs penyimpanan CSP

Jika Anda mendaftarkan Template Sertifikat v3, kunci pribadi masuk ke penyimpanan kunci pribadi CNG di komputer klien. Jika Anda mendaftarkan Template Sertifikat v2 atau v1, kunci pribadi masuk ke penyimpanan CSP. Sertifikat akan terlihat oleh semua aplikasi dalam kedua kasus, tetapi bukan kunci privatnya - sehingga sebagian besar aplikasi akan menunjukkan sertifikat sebagai tersedia, tetapi tidak akan dapat menandatangani atau mendekripsi data dengan kunci pribadi terkait kecuali mereka mendukung penyimpanan CNG.

Anda tidak dapat membedakan antara penyimpanan CNG dan CSP dengan menggunakan MMC Sertifikat. Jika Anda ingin melihat penyimpanan apa yang digunakan sertifikat tertentu, Anda harus menggunakan CERTUTIL -repairstore my * (atau CERTUTIL -user -repairstore my *) dan lihat bidang Penyedia. Jika dikatakan "... Penyedia Penyimpanan Kunci", maka itu adalah CNG sementara semua penyedia lainnya adalah CSP.

Jika Anda membuat permintaan sertifikat awal secara manual (Buat Permintaan Kustom dalam MMC), Anda dapat memilih antara "CNG Storage" dan "Legacy Key" di mana legacy berarti CSP. Berikut ini adalah daftar berdasarkan pengalaman saya tentang apa yang tidak mendukung CNG - Anda tidak dapat menemukan daftar otoritatif di mana pun, jadi ini muncul dari penyelidikan saya dari waktu ke waktu:

  • EFS Tidak didukung di Windows 2008/Vista, Didukung di Windows 7/2008R2
  • sertifikat enkripsi pengguna
  • Klien VPN/WiFi (EAPTLS, PEAP Client)

  • Windows 2008/7 Tidak didukung dengan otentikasi sertifikat pengguna atau komputer

  • Sertifikat server TMG 2010 tentang pendengar web
  • Sertifikat email pengguna Outlook 2003 untuk tanda tangan atau enkripsi
  • Kerberos Windows 2008/Vista- DC sertifikat
  • Manajer Operasional Pusat Sistem 2007 R2
  • Manajer Konfigurasi Pusat Sistem 2007 R2
  • SQL Server 2008 R2-
  • Forefront Identity Manager 2010 Manajemen Sertifikat

Informasi lebih lanjut tentang kompatibilitas CNG tercantum di sini (dalam bahasa Ceko, meskipun Chrome menangani terjemahan otomatis dengan baik)

Kartu Cerdas & Penerbitan CA

Jika Anda berencana memberi pengguna kartu pintar kedua untuk otentikasi, gunakan CA penerbit kedua untuk itu. Alasan: Persyaratan Windows 7

Gunakan perintah Windows CERTUTIL -viewstore -enterprise NTAuth untuk pemecahan masalah login Smartcard. Toko NTAuth lokal adalah hasil unduhan Kebijakan Grup terakhir dari toko Active Directory NTAuth. Ini adalah toko yang digunakan oleh masuk kartu pintar, jadi melihat toko ini dapat berguna ketika pemecahan masalah kegagalan masuk kartu pintar.

Menonaktifkan Pohon PKI

Jika Anda menggunakan dua pohon PKI, dengan maksud untuk menonaktifkan pohon warisan di beberapa titik (di mana semua perangkat lama menjadi usang atau ditingkatkan) mungkin ide yang baik untuk mengatur bidang Pembaruan Berikutnya CRL ke Null. Ini akan (harus?) Mencegah jajak pendapat berkelanjutan untuk CRLS baru kepada klien. Alasannya adalah bahwa setelah PKI dinonaktifkan, tidak akan ada lagi administrasi, dan tidak ada lagi sertifikat yang dicabut. Semua sertifikat yang tersisa dibiarkan habis masa berlakunya.

Informasi lebih lanjut tentang dekomisioning PKI tersedia di sini

39

Perintah khusus CS AD

Ini adalah daftar perintah yang relevan untuk mengkonfigurasi Server Windows 2008 R2 CA. Saya menghapusnya dari pos lain karena informasi itu terlalu panjang, dan tidak semua perintah berhubungan langsung dengan pengaturan CA.

Ini lebih dari bagian Bagaimana, bukan "apa dan mengapa". Ini juga termasuk perbedaan versi-spesifik antara versi CA (2000 vs 2003, vs 2008)


Sebutkan Bendera Edit Kebijakan Pendaftaran

Beberapa permintaan dari klien mungkin dilucuti secara otomatis berdasarkan pada pengaturan server tersembunyi ini.

C:\Users\ChrisLamont>certutil -getreg

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration:

Keys:
  Secure Email Root v1

Values:
  Active                   REG_SZ = Secure Email Root v1
  DBDirectory              REG_SZ = C:\Windows\system32\CertLog
  DBLogDirectory           REG_SZ = C:\Windows\system32\CertLog
  DBTempDirectory          REG_SZ = C:\Windows\system32\CertLog
  DBSystemDirectory        REG_SZ = C:\Windows\system32\CertLog

  DBSessionCount           REG_DWORD = 64 (100)
  LDAPFlags                REG_DWORD = 0

  DBFlags                  REG_DWORD = b0 (176)
    DBFLAGS_MAXCACHESIZEX100 -- 10 (16)
    DBFLAGS_CHECKPOINTDEPTH60MB -- 20 (32)
    DBFLAGS_LOGBUFFERSHUGE -- 80 (128)

  Version                  REG_DWORD = 40001 (262145) -- 4.1
  SetupStatus              REG_DWORD = 6001 (24577)
    SETUP_SERVER_FLAG -- 1
    SETUP_DCOM_SECURITY_UPDATED_FLAG -- 2000 (8192)
    SETUP_SERVER_IS_UP_TO_DATE_FLAG -- 4000 (16384)
CertUtil: -getreg command completed successfully.

C:\Users\ChrisLamont>certutil -getreg policy\editflags

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\Secur
e Email Root v1\PolicyModules\CertificateAuthority_MicrosoftDefault.Policy\EditF
lags:

  EditFlags REG_DWORD = 83ee (33774)
    EDITF_REQUESTEXTENSIONLIST -- 2
    EDITF_DISABLEEXTENSIONLIST -- 4
    EDITF_ADDOLDKEYUSAGE -- 8        // <--- THIS ENTRY REMOVES A CLIENT'S Key Agreement  
    EDITF_ATTRIBUTEENDDATE -- 20 (32)
    EDITF_BASICCONSTRAINTSCRITICAL -- 40 (64)
    EDITF_BASICCONSTRAINTSCA -- 80 (128)
    EDITF_ENABLEAKIKEYID -- 100 (256)
    EDITF_ATTRIBUTECA -- 200 (512)
    EDITF_ATTRIBUTEEKU -- 8000 (32768)
CertUtil: -getreg command completed successfully.

Solusinya adalah dengan menjalankan perintah certutil -setreg policy\EditFlags -EDITF_ADDOLDKEYUSAGE yang pada gilirannya memperbarui

     Configuration\spatula\PolicyModules\CertificateAuthority_MicrosoftDefault.Policy\EditFlags:

Cara mendefinisikan kebijakan berdasarkan Per CA Dasar

Untuk memasukkan kebijakan dalam sertifikat yang dikeluarkan, masukkan perintah berikut di Prompt perintah:

 certutil -v -setreg policy\EnableRequestExtensionlist "+2.5.29.32"
 certutil –shudown
 net start certsvc

Anda dapat menonaktifkan pengaturan dengan

  certutil -v -setreg policy\EnableRequestExtensionlist      "-2.5.29.32"
  certutil –shudown
  net start certsvc

Cara menentukan durasi cache OCSP

Perintah berikut memungkinkan Anda mengatur, memodifikasi, dan menghapus pengaturan header Max-Age.

  appcmd set config /section:httpProtocol /+customHeaders.[name='cacheControlHeader',value='max-age=604800']

Untuk melihat header kustom httpProtocol saat ini

  appcmd list config /section:httpProtocol

Cara mengimpor sertifikat CA offline ke AD

:
: Root CA certificates
:
certutil -dspublish -f concorp-ca-00_CorporateRootCA.crt RootCA
:
: Sub CA certificate
:
certutil -dspublish -f connoam-ca-00_IntermediateCA1.crt SubCA
:
: Root CA CRLs
: Since these are .NET CA CRLS that have the publication location as
: part of the CRL, the publication location is optional
:
:                                              |-- publication location ---|
:
certutil -dspublish -f CorporateRootCA.crl     concorp-ca-00 CorporateRootCA
:
: Sub CA CRLs
:
certutil -dspublish -f IntermediateCA1.crl     connoam-ca-00 IntermediateCA1

Cara mengaktifkan PKCS # 1 v1.21

Ini diaktifkan ketika file CAPolicy.inf memiliki AlternateSignatureAlgorithm=1. Pastikan Anda mengetahui masalah kompatibilitas.

Akhirnya orang harus tahu bahwa menginstal Layanan Sertifikat AD tidak sesederhana menambahkan peran. Anda harus memeriksa ini skrip Instalasi VBS dan memastikan file CAPolicy.inf harus diedit sesuai kebutuhan untuk lingkungan Anda

Cara mendefinisikan Cross Distribution Distribution Point

Layanan Sertifikat AD Windows memungkinkan ini dalam file CAPolicy.info dengan [CrossCertificateDistributionPointsExtension] masuk

Lain-lain: Perbedaan AIA saat memutakhirkan Windows 2000 CA ke Windows 2003

Perhatikan bahwa ada perubahan perilaku antara Windows 2000 dan 2003 CA. Perpanjangan sertifikat AKI yang dikeluarkan oleh Windows CA berbeda antara Windows 2000 dan Windows Server 2003. Secara default, informasi berikut disimpan dalam ekstensi AIA dari sertifikat yang diterbitkan.

  • Windows 2000 Perpanjangan sertifikat AIA yang dikeluarkan oleh CA mencakup DN LDAP dari CA yang menerbitkan (nama Penerbit), nomor seri sertifikat CA yang mengeluarkan, dan hash kunci dari kunci publik sertifikat CA.

  • Windows Server 2003 Perpanjangan sertifikat AIA yang dikeluarkan oleh CA hanya mencakup hash kunci publik dari CA yang menerbitkan, juga dikenal sebagai ID-Kunci.

Perubahan perilaku ini disebabkan oleh kesalahan rantai yang bisa terjadi ketika sertifikat CA diperbarui. Perilaku Windows 2000 default dapat mengakibatkan rantai tidak lengkap jika sertifikat CA yang digunakan untuk menandatangani sertifikat yang dikeluarkan tidak tersedia untuk klien. Dengan perilaku default Windows Server 2003, jika CA diperbarui dengan pasangan kunci yang sama, sertifikat CA apa pun untuk CA penerbit yang menggunakan pasangan kunci yang sama dapat dimasukkan dalam rantai sertifikat.

Anda bisa meniru perilaku lama dengan menjalankan perintah ini

 certutil -setreg policy\EditFlags -EDITF_ENABLEAKIISSUERNAME
 certutil -setreg policy\EditFlags -EDITF_ENABLEAKIISSUERSERIAL

Daftar sertifikat dalam AD

Perintah ini akan mencantumkan sertifikat yang diterbitkan di Active Directory.

certutil -viewstore "ldap:///CN=Certification Authorities,CN=Public Key Services,CN=Services,CN=Configuration,DC=contoso,DC=com?cACertificate?one?objectClass=certificationAuthority"

ISIS MTT v1.1 PKI Kompatibilitas

Lihat ini Artikel KB untuk prosedur , juga di sini adalah metode CAPolicy.inf alternatif untuk ISIS MTT v1.1

4

satu poin dalam daftar periksa sering terlewatkan:

  • BACKUP
  • BACKUP
  • BACKUP

esp. jika Anda menerapkan CA.

Saya kehabisan ruang pada jawaban saya sebelumnya, tetapi berpikir ini adalah informasi yang valid dan berguna:

Pencabutan

Beberapa bagian berikutnya membahas CRL dan sertifikat, tetapi sebelum Anda melangkah terlalu jauh, saya ingin menarik perhatian Anda pada masalah yang dapat mempengaruhi produksi dan operasi PKI: Jika Anda berpikir PKI Anda akan mencabut dua kali sertifikat yang sama dengan Microsoft PKI (Active Directory Certificate) Layanan), maka tanggal pencabutan akan menjadi tanggal pencabutan kedua, bukan yang pertama. Tetapi jika Anda mengelola sertifikat pada kartu pintar dengan produk FIM CM Microsoft (Forefront Identity Management - Certificate Management), maka Anda akan membuat pencabutan duplikat tersebut. sumber

1