Windows Server 2025 / Mengatur HTTPS IIS dan memeriksa sertifikat dari klien
HTTPS pada IIS memerlukan sertifikat yang cocok dengan nama permintaan, kunci privat terkait pada server, dan binding HTTPS yang memakai sertifikat itu. Periksa juga kepercayaan klien, masa berlaku, kondisi pemeriksaan pencabutan, dan sertifikat yang benar-benar disajikan, terutama setelah pembaruan.
Periksa nama, kunci, kepercayaan, dan binding secara terpisah
HTTPS melindungi lalu lintas HTTP melalui Transport Layer Security (TLS), protokol keamanan transportasi. Server menyajikan sertifikat yang menghubungkan identitas dengan kunci publik; klien memeriksa nama, masa berlaku, dan rantai kepercayaan. Kunci privat tetap di server untuk membuktikan kepemilikan kunci terkait. Subject Alternative Name (SAN) adalah ekstensi yang memuat nama yang diizinkan; pada latihan ini harus mencakup web.lab.example.test.
| Komponen | Pemeriksaan lab |
|---|---|
| Nama | web.lab.example.test dalam Subject Alternative Name (SAN). |
| Penyimpanan | WEB1 → Local Computer → Personal. |
| Kunci | Kunci privat terkait tersedia dan dapat digunakan layanan. |
| Kepercayaan | CLIENT1 mempercayai rantai yang ditentukan pada konteks pengguna yang dipakai. |
| Binding | LabSite / HTTPS / 8443 / sertifikat berdasarkan sidik jari. |
Mengakses IP berbeda dari mengakses nama. Sertifikat dengan DNS SAN web.lab.example.test tidak otomatis mencakup 172.24.50.30. Standar identitas layanan TLS RFC 9525 memakai identitas SAN; kecocokan Common Name saja bukan bukti yang cukup. Nama .test digunakan untuk lab internal ini; layanan nyata membutuhkan nama yang dikendalikan organisasi dan otoritas sertifikat (CA) yang sesuai. Panduan HTTPS IIS memisahkan sertifikat dan binding. Contoh SSL lama di sana bukan anjuran mengaktifkan protokol usang.
Buat sertifikat untuk pengujian terisolasi
Pastikan dahulu LabSite dan nama web.lab.example.test berfungsi, mengarah ke 172.24.50.30, serta menampilkan halaman HTTP yang diharapkan. Gunakan hanya WEB1 dan CLIENT1 terisolasi tanpa publikasi layanan. Sertifikat self-signed ditandatangani sendiri: penerbit dan subjeknya merujuk sertifikat yang sama, dan klien tidak otomatis mempercayainya. Ini bukan pengganti penerbitan, validasi, atau pengelolaan kunci produksi. Catat binding, aturan, dan keadaan kedua penyimpanan sertifikat sebelum perubahan.
Jalankan setiap baris secara lokal pada WEB1 dengan Windows PowerShell berhak administrator. Jika pembuatan gagal, berhenti dan jangan memakai nilai lama yang mungkin tersisa di labCertificate. Catat Thumbprint, sidik jari objek baru, di luar sesi tersebut. Masa berlaku satu bulan dipilih untuk lab; AddMonths(1) berarti satu bulan kalender, bukan kebijakan CA atau selalu 30 hari. New-SelfSignedCertificate menjelaskan DNS SAN dan penyimpanan komputer:
$labCertificate = New-SelfSignedCertificate -DnsName 'web.lab.example.test' -CertStoreLocation 'Cert:\LocalMachine\My' -FriendlyName 'LabSite HTTPS test' -NotAfter (Get-Date).AddMonths(1)
$labCertificate | Select-Object Subject,Thumbprint,NotAfter,HasPrivateKey
Pada WEB1 buka certlm.msc → Personal → Certificates dan cari sidik jari yang dicatat dengan tepat. Periksa SAN, tujuan autentikasi server, penerbit, tanggal, dan kunci privat terkait. HasPrivateKey diharapkan True, tetapi hanya menunjukkan keterkaitan kunci, bukan bahwa layanan dapat memakainya. Pengelolaan penyimpanan sertifikat Windows membedakan Local Computer dari Current User. Sebelum mengulang latihan, tinjau objek yang ada agar tidak menumpuk salinan bernama sama. Friendly name bukan identitas unik sertifikat.
Tambahkan binding HTTPS pada port 8443
- Di IIS Manager → WEB1 → Server Certificates segarkan tampilan dan temukan sertifikat baru. Cocokkan dengan sidik jari serta tanggal yang dicatat, bukan friendly name saja.
- Buka LabSite → Bindings → Add, pilih https, IP 172.24.50.30, dan port 8443. Periksa dahulu konflik kombinasi atau layanan yang sudah ada.
- Isi web.lab.example.test dan pilih Require Server Name Indication. Jangan tertukar dengan nama StatusSite.
- Pilih LabSite HTTPS test dan konfirmasi kesesuaian sidik jari WEB1. Jika tidak muncul atau kuncinya tidak ada, periksa penyimpanan dan objeknya, bukan memilih nama yang mirip.
- Periksa kombinasi lengkap, duplikasi, dan status situs. Pertahankan binding HTTP 8080 tanpa perubahan selama percobaan untuk membedakan kedua akses.
- Setelah memastikan profil Domain pada WEB1, buat Lab-IIS-HTTPS-8443 hanya jika belum ada: wf.msc → Inbound Rules → New Rule → Port → TCP local port 8443 → Allow → hanya Domain. Pada Properties → Scope batasi remote IP ke 172.24.50.0/24. Periksa aturan serta kebijakan lain, tanpa memperluas profil atau mematikan firewall.
Server Name Indication (SNI), indikasi nama server, memungkinkan klien menyampaikan nama yang diminta selama negosiasi TLS dan membantu memilih sertifikat saat berbagi IP serta port. Tinjau atribut binding dan SNI. Port 8443 memisahkan latihan dari HTTP 8080; port HTTPS biasa adalah 443. SNI tidak menambah kepercayaan atau mengubah SAN. Klien yang tidak mendukung kebutuhan tersebut bukan alasan menonaktifkan validasi sertifikat.
Validasi kepercayaan dan sertifikat aktual dari CLIENT1
Dari CLIENT1 buka https://web.lab.example.test:8443/. Sebelum kepercayaan ditambahkan, peringatan diharapkan untuk sertifikat self-signed ini, tetapi peringatan juga dapat menandakan masalah lain. Jangan melewatinya untuk menyatakan berhasil dan jangan memasukkan kredensial. Jika browser mengizinkan melihat sertifikat tanpa melanjutkan, bandingkan sidik jari, nama, dan masa berlaku dengan catatan WEB1. Jika sidik jari berbeda atau sertifikat tidak dapat diidentifikasi, berhenti dan periksa binding sebelum menambah kepercayaan.
- Pada WEB1, certlm.msc → Personal → Certificates, pilih sertifikat uji berdasarkan sidik jari → All Tasks → Export. Pilih No, do not export the private key dan file publik .cer dengan nama serta jalur baru tanpa menimpa file lain.
- Pindahkan .cer itu ke CLIENT1 melalui jalur lab tepercaya. Jangan membuat atau menyebarkan PFX yang memuat kunci privat; klien membutuhkan sertifikat publik, bukan kunci server.
- Buka file publik dan bandingkan sidik jarinya dengan catatan WEB1 melalui saluran tepercaya yang independen dari file asal tak dikenal. Periksa juga nama dan masa berlaku. Jika berbeda, jangan impor.
- Pada CLIENT1 sebagai pengguna yang akan menguji, buka certmgr.msc → Trusted Root Certification Authorities → Certificates → All Tasks → Import. Pilih hanya .cer terverifikasi dan pastikan Current User serta penyimpanan tersebut. Catat sidik jari dan cakupannya untuk penghapusan nanti. Jangan impor ke perangkat produksi atau lewat kebijakan domain.
- Tutup dan buka lagi browser pengguna yang sama, lalu kunjungi https://web.lab.example.test:8443/. Pastikan tanpa peringatan, sidik jari sesuai, dan isi halaman benar; tab terbuka saja tidak cukup.
Menambahkan sertifikat root mengubah apa yang dipercaya dalam konteks itu. Impor hanya sertifikat uji yang dibuat dan diverifikasi sendiri, bukan sertifikat tak dikenal untuk menghilangkan peringatan. Jika tetap gagal, periksa SAN, waktu klien dan server, masa berlaku, sidik jari yang benar-benar disajikan, serta kebijakan browser atau organisasi. Current User berlaku untuk konteks pengguna tersebut; hasilnya tidak membuktikan pengguna lain atau layanan memakai penyimpanan yang sama. Jangan menyebarkannya lewat kebijakan domain atau mengganti ke penyimpanan global agar latihan berhasil.
Test-NetConnection -ComputerName web.lab.example.test -Port 8443
TcpTestSucceeded: True hanya membuktikan koneksi TCP pada 8443, bukan negosiasi TLS, nama, rantai, atau isi halaman. Di browser periksa sertifikat aktual dan jalur sertifikasinya, sidik jari yang sama dengan catatan, serta konten LabSite yang diharapkan. Koneksi tanpa peringatan beserta pemeriksaan tersebut berbeda dari melanjutkan setelah mengabaikan peringatan. Sertifikat uji ini juga tidak membuktikan pemeriksaan pencabutan CA nyata bekerja.
Periksa binding saat pembaruan dan pembersihan
Menerbitkan atau mengimpor sertifikat pengganti ke penyimpanan belum memastikan IIS menyajikannya. Periksa kunci baru yang dapat digunakan, nama, rantai, tujuan, serta masa berlaku; perbarui binding situs yang dituju dan konfirmasi sidik jari baru serta halaman dari klien terpisah. Catat binding dan sidik jari lama terlebih dahulu. Pertahankan sertifikat lama sampai ketergantungan dan kebutuhan pemulihan dipahami; sertifikat kedaluwarsa atau dicabut bukan tujuan rollback yang sah. Jangan mengganti semua binding berdasarkan friendly name yang sama.
- Tetapkan penanggung jawab, metode pembaruan, dan peringatan kegagalan penerbitan atau penerapan, bukan hanya pengingat kedaluwarsa.
- Sediakan waktu sebelum berakhir untuk persetujuan, pemasangan, pembaruan binding, dan validasi klien. Peringatan tanpa penanggung jawab tindakan belum melengkapi proses.
- Untuk sertifikat dan kebijakan yang membutuhkan pemeriksaan pencabutan, pastikan lokasi daftar pencabutan atau respons status yang benar dapat dijangkau. Jangan mengarang endpoint tersebut untuk sertifikat self-signed ini atau menonaktifkan pemeriksaan global guna menyembunyikan masalah.
- Jika pembaruan diotomatisasi, pantau juga penetapan binding dan sertifikat yang benar-benar disajikan. Objek baru di penyimpanan belum membuktikan lalu lintas memakai objek itu.
Untuk pembersihan, hapus hanya binding HTTPS tambahan LabSite dan aturan Lab-IIS-HTTPS-8443. Periksa ketergantungan binding atau layanan lain sebelum menghapus sertifikat uji pada WEB1 → Local Computer → Personal berdasarkan sidik jarinya. Pada CLIENT1 buka certmgr.msc dan hapus hanya entri yang ditambahkan latihan di Current User → Trusted Root Certification Authorities dengan sidik jari yang sama. Periksa cakupan jika suatu tampilan mewarisi entri dari penyimpanan lain; jangan menghapus root lain atau sertifikat bernama mirip. Tentukan terpisah apakah mempertahankan HTTP 8080 atau merancang pengalihan HTTPS yang sudah diverifikasi. Menambah HTTPS tidak otomatis mengalihkan atau menghapus HTTP.




