Inventarisasi hostname, dependensi, dan kepemilikan
Daftar setiap hostname yang digunakan pengunjung atau integrasi: apex, www, subdomain, API, host aset, portal, dan nama regional. Untuk masing-masing, catat tempat TLS berakhir, siapa yang dapat mengubahnya, cakupan dan kedaluwarsa sertifikat, metode perpanjangan, dan dependensi yang menghasilkan URL. Sertifikat harus mencakup hostname yang diminta dalam daftar Subject Alternative Name-nya. Sertakan CMS, CDN, tag manager, penyimpanan objek, penyedia pembayaran, template email, dan embed pihak ketiga; ini sering memperkenalkan URL HTTP setelah rilis HTTPS pertama.
Pilih hostname kanonis seperti www atau apex dan arahkan alternatifnya langsung ke sana lewat HTTPS.
Terapkan sertifikat dan versi TLS yang mutakhir
Konfigurasikan server web, reverse proxy, CDN, atau load balancer yang menjawab permintaan publik. Pasang sertifikat dan rantai yang diperlukan, kaitkan ke nama yang dimaksud, dan verifikasi dari luar jaringan hosting. Browser memeriksa rantai, hostname, dan tanggal; peringatan publik adalah pemblokir rilis. Default ke TLS 1.3 dan pertahankan TLS 1.2 hanya jika kompatibilitas membutuhkannya. Nonaktifkan SSL dan TLS 1.0 serta 1.1. Gunakan panduan platform yang dipelihara daripada menyalin daftar cipher lama, dan selalu patch server serta pustaka TLS.
Batasi akses ke kunci privat dan catat setiap sistem yang berbagi kunci tersebut sehingga penggantian menjangkau semuanya.
Alihkan HTTP sekali dan jadikan HTTPS kanonik
Kembalikan pengalihan sisi-server permanen, biasanya 301 atau 308, dari setiap URL HTTP ke URL HTTPS yang setara. Hindari rantai: itu menambah penundaan dan titik kegagalan. Publikasikan URL HTTPS kanonik dalam tautan internal, tag canonical, sitemap, data terstruktur, tag sosial, email, dan tautan absolut yang dibuat aplikasi. Uji halaman beranda, halaman dalam, URL dengan query, rute error, dan varian hostname. Ketika TLS berakhir di proxy, konfigurasikan penanganan forwarded-protocol yang tepercaya sehingga aplikasi tidak berputar antara HTTP dan HTTPS.
HTTP boleh tetap tersedia hanya untuk mengalihkan atau menyelesaikan tantangan sertifikat, bukan untuk melayani situs publik terpisah.
Temukan dan perbaiki mixed content dari sumbernya
Mixed content adalah halaman HTTPS yang meminta sumber daya lewat HTTP atau protokol tidak aman lain. Browser mungkin meng-upgrade beberapa media, tetapi mereka memblokir banyak permintaan berisiko, termasuk skrip, stylesheet, frame, panggilan fetch, dan font. Ganti setiap referensi dengan URL HTTPS yang telah diuji, URL relatif untuk konten sendiri, atau alternatif yang disetujui. Crawl template representatif dan inspeksi alat pengembang sambil menyelesaikan alur utama. Periksa CSS, JavaScript, blok CMS, manifest aset, entri tag-manager, unduhan, dan embed vendor. Halaman yang aman tidak boleh menawarkan unduhan HTTP.
Peningkatan otomatis oleh browser mungkin tetap meninggalkan dependensi pihak ketiga yang tidak tersedia atau tidak didukung; perbaiki URL yang tersimpan.
Otomatiskan perpanjangan sertifikat sebelum kedaluwarsa
Perlakukan perpanjangan sebagai deployment otomatis, bukan pengingat kalender. Sertifikat harus memperpanjang, dideploy ke setiap lapisan penyaji, dan memuat ulang layanan dengan aman. Uji rute validasi yang sama sebelum kedaluwarsa produksi. Let's Encrypt, misalnya, merekomendasikan memperpanjang sertifikat 90 hari setiap 60 hari; ikuti siklus hidup untuk penerbit dan platform Anda. Simpan nama sertifikat, akun penerbit, metode tantangan, otomasi, lokasi kunci, target, dan kontak darurat dalam inventaris. Verifikasi tanggal dari endpoint publik setelah deployment.
Untuk perpanjangan yang gagal, periksa DNS, routing tantangan, izin, akses penerbit, batas laju, dan deployment CDN-ke-origin.
Gunakan HSTS hanya setelah seluruh lingkungan HTTPS siap
HTTP Strict Transport Security (HSTS) adalah header respons HTTPS yang memberi tahu browser untuk menggunakan HTTPS pada kunjungan berikutnya ke host. Browser kemudian tidak menawarkan pengunjung opsi bypass untuk kesalahan sertifikat. Kirim hanya lewat HTTPS dan pertahankan pengalihan HTTP karena HSTS dipelajari setelah respons yang aman kecuali preload list berlaku. Mulailah dengan max-age terbatas dan perpanjang setelah membuktikan perpanjangan dan rute yang diperlukan. Jangan tambahkan includeSubDomains sampai setiap subdomain saat ini dan di masa depan dapat menyajikan HTTPS valid. Preload bukan bagian dari spesifikasi HSTS dan memerlukan tinjauan komitmen jangka panjang tersendiri.
max-age=0 bekerja hanya setelah browser mencapai respons HTTPS yang valid; ia tidak dapat memperbaiki host aman yang tidak dapat dijangkau.
Rilis, uji, dan rollback tanpa melemahkan transport
Simpan konfigurasi sertifikat, edge, dan pengalihan yang diketahui baik sebelum perubahan. Definisikan siapa yang menyetujui rollback, lakukan staging bila memungkinkan, dan ubah satu kelas kontrol pada satu waktu. Segera periksa endpoint publik dari lebih dari satu jaringan, ikuti pengalihan, inspeksi sertifikat, dan selesaikan tindakan pengunjung penting. Uji browser dan grup klien yang relevan untuk audiens Anda. Untuk alur pembayaran atau yang diatur, minta penyedia pembayaran dan profesional keamanan yang memenuhi syarat meninjau persyaratan yang berlaku. Jika perubahan mematahkan HTTPS, pulihkan konfigurasi aman yang telah tervalidasi; jangan menjadikan halaman pelanggan HTTP sebagai solusi sementara.
Tangkap hostname, waktu, klien, error, perubahan, dan hasil sehingga perpanjangan atau migrasi berikutnya lebih mudah didiagnosis.