Mengapa Windows 2012 R2 tidak mempercayai sertifikat yang saya tandatangani sendiri?


9

Dalam lingkungan pengujian, saya saat ini sedang terhambat dari pengujian beberapa hal yang perlu segera dikerahkan (sebenarnya sudah, tetapi Anda tahu bagaimana tenggat waktu pergi ...) karena Windows menolak untuk mempercayai sertifikat yang ditandatangani sendiri yang kami miliki di kami lingkungan pengujian terisolasi. Meskipun saya hanya bisa melangkah ke samping masalah dengan sertifikat "nyata" dan beberapa trik DNS, untuk alasan keamanan / kompartementalisasi saya tidak mengatakan sertifikat.

Saya mencoba untuk terhubung ke server email berbasis Linux bernama Zimbra; itu menggunakan sertifikat OpenSSL yang ditandatangani sendiri yang dibuat secara otomatis. Sementara halaman yang muncul di Google merujuk secara khusus ke situs web IIS dengan sertifikat yang ditandatangani sendiri oleh IIS, saya tidak berpikir metode menghasilkannya benar-benar penting.

Menurut instruksi yang saya temukan di sini dan di sini , ini seharusnya menjadi masalah sederhana dengan menginstal sertifikat ke toko Otoritas Sertifikasi Rumput Akar Terpercaya komputer lokal. Yang telah saya lakukan, juga secara manual menyalin sertifikat dan mengimpornya langsung melalui snap-in MMC. Logout dan reboot tidak mengubah apa pun.

Inilah kesalahan sertifikat yang saya dapatkan setiap kali: masukkan deskripsi gambar di sini

Dan inilah Jalur Sertifikasi (spoiler: itu hanya sertifikat itu sendiri): masukkan deskripsi gambar di sini

Akhirnya, inilah sertifikat yang tersimpan dengan aman di toko sertifikat komputer lokal, persis seperti instruksi yang saya temukan mengatakan seharusnya: masukkan deskripsi gambar di sini

Instruksi ini secara khusus merujuk Vista (well, yang kedua tidak menyebutkan OS) dan IIS, sementara saya menggunakan Server 2012 R2 yang terhubung ke server berbasis Linux; ada beberapa perbedaan dalam panduan impor (seperti saya memiliki opsi untuk mengimpor untuk pengguna saat ini atau sistem lokal, meskipun saya sudah mencoba keduanya), jadi mungkin ada sesuatu yang berbeda yang harus saya lakukan di sini? Pengaturan di suatu tempat yang belum saya temukan yang harus diubah untuk membuatnya benar-benar mempercayai sertifikat yang sudah saya perintahkan untuk dipercaya?

Apa cara yang benar untuk membuat Windows Server 2012 R2 mempercayai sertifikat yang ditandatangani sendiri?


Tidak dapat mereproduksi masalah Anda. Jika Anda menggunakan IIS "Buat Sertifikat yang Ditandatangani Sendiri" dan pilih untuk menginstalnya di toko Pribadi (juga mencoba toko Web Hosting), tidak ada masalah sama sekali. Bagaimana Anda membuat sertifikat? Dari IIS atau dari Otoritas Sertifikasi MMC snapin?

Sudahkah Anda mencoba memilih toko tujuan secara eksplisit (mengimpor dari dalam konsol mmc)?
JoaoCC

@SujaySarma Ini bukan untuk situs web IIS, tetapi untuk aplikasi Linux bernama Zimbra. Ini adalah sertifikat yang ditandatangani sendiri OpenSSL.
Kromey

@ user1703840 Ya, saya telah menetapkan toko tujuan secara eksplisit, serta mengizinkan Windows untuk memilihnya secara otomatis, melalui MMC dan panduan impor sertifikat di IE. Hasil yang sama juga, yang tidak ada.
Kromey

Hah? Dari mana Linux berasal? Seluruh pertanyaan Anda dan tautan yang Anda poskan (termasuk tangkapan layar) berurusan dengan Windows Server 2012 R2 dan IIS. Mohon klarifikasi.

Jawaban:


1

Kesalahan yang Anda terima bukan karena bukan sertifikat root tepercaya, tetapi tidak dapat memverifikasi rantai ke sertifikat tepercaya. Jika ada bagian dari rantai rusak, tidak dipercaya, atau hilang, Anda akan menerima kesalahan seperti itu. Kesalahan yang saya dapatkan dengan root yang tidak dapat dipercaya dan ditandatangani sendiriapakah ini: Sertifikat root CA ini tidak tepercaya. Untuk mengaktifkan kepercayaan, instal sertifikat ini di toko Otoritas Sertifikasi Root Tepercaya. Tetapi bagi Anda, katanya tidak dapat memverifikasi hingga sertifikat root tepercaya. Ini mungkin bahwa selama proses penandatanganan sendiri, Anda mungkin telah memberi tahu openssl untuk menandatangani sertifikat dengan root yang berbeda (bukan self-sign), atau itu mungkin belum ditetapkan sebagai root CA. Jika ini yang pertama, Anda harus memercayai root yang sudah ditandatanganinya. Jika itu yang terakhir, itu masalah pengaturan beberapa properti di openssl.conf.


Tangkapan layar menunjukkan bahwa sertifikat tersebut dipasang di CA Root Tepercaya, dan juga menunjukkan bahwa seluruh rantai adalah sertifikat itu sendiri - itu adalah root, dan karenanya berada di Root Root Tepercaya CA sudah cukup. Pertanyaannya adalah mengapa bukan?
Kromey

Saya mengatakan itu mungkin bukan root, bukan bahwa itu tidak ditambahkan ke toko root tepercaya. Kesalahannya adalah apa yang aneh tentang hal itu - tidak seharusnya mengatakan itu tidak dapat memverifikasi hingga CA tepercaya, jika itu seharusnya menjadi CA - itulah sebabnya saya menyarankan bahwa itu sebenarnya bukan root, tetapi ditandatangani dengan sertifikat lain.
Flashbang

coba jalankan perintah ini pada kotak Anda mencoba mendapatkan sertifikat untuk: openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 30 -sha256 -nodesdan mengimpor sertifikat itu ke toko root CA tepercaya. (dan juga mengkonfigurasinya menjadi sertifikat dan kunci yang digunakan oleh Zimbra, tentu saja).
flashbang

Oh, aku mengerti maksudmu. Maaf, saya salah paham. Tetapi jika itu bukan root, bukankah seharusnya itu muncul di jendela Jalur Sertifikasi? Bagaimanapun, sayangnya, saya tidak dapat benar-benar menguji ini lebih jauh - saya berhasil mendapatkan sertifikat resmi kami, dan bersama dengan sedikit peretasan dalam hostsfile membuatnya berfungsi seperti itu.
Kromey

Sertifikat Anda berasal dari CA root, berdasarkan tangkapan layar. Jika Anda melihat detail sertifikat untuk idp.godaddy.com seluruh jalur disajikan dan Anda dapat menggunakannya sebagai perbandingan. Jika Anda melihat properti sertifikat di MMC, apakah itu menyertakan otentikasi server dalam tujuan sertifikat? (Klik kanan pada sertifikat di tangkapan layar kedua dan pilih properti).
John Auld

1

dari apa yang saya bisa kerjakan Anda perlu menambahkan zmaster sebagai sumber Tepercaya CA karena otoritas penerbitan, WS2k12 sedang mencoba memverifikasi sertifikat terhadap host yang tidak tahu apa-apa tentang itu. Anda benar karena metode pembuatannya tidak penting tetapi sumber yang dapat diverifikasi itu. Ini memiliki efek yang Anda alami: bahwa WS2k12 tidak mempercayai sertifikat hanya karena memiliki nama $ Random_issuing_authority, ia harus dapat memverifikasi sertifikat.


Ini adalah sertifikat yang ditandatangani sendiri - dengan menempatkan sertifikat di toko CA Root Tepercaya, Anda secara definisi memercayai penerbit.
Chris McKeown

Kecuali jika saya melewatkan sesuatu, itulah yang telah saya lakukan - lihat tangkapan layar ketiga yang menunjukkan sertifikat zmaster di dalam toko CA Root Tepercaya.
Kromey

0

Saya memiliki masalah yang sama, ternyata solusi saya adalah memperbarui file .crt dan .key untuk server mail seperti yang digunakan oleh dovecot. Exim4 pada surat memiliki set cert / key yang diperbarui, tetapi dovecot masih menunjuk ke set cert / key yang lama.

Pasangan sertifikat / kunci yang lama berfungsi dengan baik pada sebagian besar situasi, tetapi tidak dengan outlook.com atau dengan MS Outlook 2013.

Masalah dengan outlook.com menyebabkan saya memutakhirkan sertifikat exim4 baru-baru ini - sekarang dovecot [dan server webmail] juga menggunakan file cert (dan kunci) baru. Server e-mail itu sendiri juga baru-baru ini ditingkatkan [dari squeeze-lts Debian lama ke wheezy], setup lama baik-baik saja dengan set sertifikat / kunci lama, tetapi setelah upgrade, saya perlu membuat set sertifikat / kunci baru sebelum Produk MS akan berfungsi dengan baik dengan server mail.


0

Saya pikir masalahnya adalah bagaimana Anda mengakses sumber daya. Untuk jaringan lokal Anda, Anda mungkin menggunakan nama host alih-alih nama domain lengkap. Namun, sertifikat Anda dikeluarkan terhadap nama domain lengkap.


Pertanyaan ini sudah memiliki jawaban yang diterima.
BE77Y

-1

Instal sertifikat ke Otoritas Sertifikasi Root Tepercaya dan Penerbit Tepercaya.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.