Mengaktifkan HTTPS di server Anda

Chris Palmer
Chris Palmer

Halaman ini memberikan panduan untuk menyiapkan HTTPS di server, termasuk langkah-langkah berikut:

  • Membuat pasangan kunci publik/privat RSA 2048-bit.
  • Membuat permintaan penandatanganan sertifikat (CSR) yang akan menyematkan kunci publik Anda.
  • Membagikan CSR Anda bersama Otoritas Sertifikat (CA) untuk menerima sertifikat final atau rantai sertifikat.
  • Menginstal sertifikat final Anda di tempat yang tidak dapat diakses web seperti /etc/ssl (Linux dan Unix) atau di mana saja yang diperlukan oleh IIS (Windows).

Membuat kunci dan permintaan penandatanganan sertifikat

Bagian ini menggunakan program command line openssl, yang disertakan dengan sebagian besar sistem Linux, BSD, dan Mac OS X, untuk membuat kunci pribadi dan publik serta CSR.

Membuat pasangan kunci publik/pribadi

Untuk memulai, buat pasangan kunci RSA 2.048 bit. Kunci yang lebih pendek dapat dipecahkan oleh serangan tebakan brute force, dan kunci yang lebih panjang menggunakan resource yang tidak perlu.

Gunakan perintah berikut untuk membuat pasangan kunci RSA:

openssl genrsa -out www.example.com.key 2048

Tindakan ini akan memberikan output berikut:

Generating RSA private key, 2048 bit long modulus
.+++
.......................................................................................+++
e is 65537 (0x10001)

Membuat permintaan penandatanganan sertifikat

Dalam langkah ini, Anda menyematkan kunci publik dan informasi tentang organisasi serta situs Anda ke dalam permintaan penandatanganan sertifikat atau CSR. Perintah openssl akan meminta metadata yang diperlukan.

Dengan menjalankan perintah berikut:

openssl req -new -sha256 -key www.example.com.key -out www.example.com.csr

Output-nya adalah sebagai berikut:

You are about to be asked to enter information that will be incorporated
into your certificate request

What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:CA
State or Province Name (full name) [Some-State]:California
Locality Name (for example, city) []:Mountain View
Organization Name (for example, company) [Internet Widgits Pty Ltd]:Example, Inc.
Organizational Unit Name (for example, section) []:Webmaster Help Center Example
Team
Common Name (e.g. server FQDN or YOUR name) []:www.example.com
Email Address []:webmaster@example.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Untuk memastikan validitas CSR, jalankan perintah ini:

openssl req -text -in www.example.com.csr -noout

Responsnya akan terlihat seperti ini:

Certificate Request:
    Data:
        Version: 0 (0x0)
        Subject: C=CA, ST=California, L=Mountain View, O=Google, Inc.,
OU=Webmaster Help Center Example Team,
CN=www.example.com/emailAddress=webmaster@example.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:ad:fc:58:e0:da:f2:0b:73:51:93:29:a5:d3:9e:
                    f8:f1:14:13:64:cc:e0:bc:be:26:5d:04:e1:58:dc:
                    ...
                Exponent: 65537 (0x10001)
        Attributes:
            a0:00
    Signature Algorithm: sha256WithRSAEncryption
         5f:05:f3:71:d5:f7:b7:b6:dc:17:cc:88:03:b8:87:29:f6:87:
         2f:7f:00:49:08:0a:20:41:0b:70:03:04:7d:94:af:69:3d:f4:
         ...

Mengirimkan CSR Anda ke otoritas sertifikat

Certificate authority (CA) yang berbeda mewajibkan Anda untuk mengirimkan CSR kepada mereka dengan cara yang berbeda. Hal ini dapat mencakup penggunaan formulir di situs mereka atau pengiriman CSR melalui email. Beberapa CA, atau reseller-nya, bahkan dapat mengotomatiskan sebagian atau semua proses, termasuk, dalam beberapa kasus, pembuatan pasangan kunci dan CSR.

Kirim CSR ke CA Anda dan ikuti petunjuknya untuk menerima sertifikat final atau rantai sertifikat Anda.

CA yang berbeda mengenakan biaya yang berbeda untuk layanan penjaminan kunci publik Anda.

Ada juga opsi untuk memetakan kunci Anda ke lebih dari satu nama DNS, termasuk beberapa nama yang berbeda (misalnya semua example.com, www.example.com, example.net, dan www.example.net) atau nama "karakter pengganti" seperti *.example.com.

Salin sertifikat ke semua server front-end Anda di tempat yang tidak dapat diakses dari web seperti /etc/ssl (Linux dan Unix) atau di mana pun IIS (Windows) memerlukannya.

Mengaktifkan HTTPS di server

Mengaktifkan HTTPS di server merupakan langkah penting dalam memberikan keamanan untuk halaman web Anda.

  • Gunakan alat Server Configuration dari Mozilla untuk menyiapkan server bagi dukungan HTTPS.
  • Uji situs Anda secara rutin dengan SSL Server Test dari Qualys dan pastikan Anda mendapatkan nilai minimal A atau A+.

Pada tahap ini, Anda harus membuat keputusan operasi yang sangat penting. Pilih salah satu opsi berikut:

  • Khususkan alamat IP berbeda ke setiap nama host yang digunakan server web Anda untuk menyajikan konten.
  • Gunakan hosting virtual berbasis nama.

Jika Anda telah menggunakan alamat IP yang berbeda untuk setiap nama host, Anda dapat mendukung HTTP dan HTTPS untuk semua klien. Namun, sebagian besar operator situs menggunakan hosting virtual berbasis nama untuk mempertahankan alamat IP dan karena lebih praktis secara umum.

Jika belum memiliki layanan HTTPS yang tersedia di server Anda, aktifkan sekarang (tanpa mengalihkan HTTP ke HTTPS. Lihat Mengalihkan HTTP ke HTTPS untuk informasi selengkapnya). Konfigurasikan server web Anda untuk menggunakan sertifikat yang telah Anda beli dan instal. Mungkin pembuat konfigurasi Mozilla berguna.

Jika Anda memiliki banyak nama host atau subdomain, masing-masing harus menggunakan sertifikat yang tepat.

Sekarang, dan secara rutin selama masa aktif situs Anda, periksa konfigurasi HTTPS dengan SSL Server Test dari Qualys. Situs Anda harus mendapatkan skor A atau A+. Anggaplah semua yang menyebabkan nilai lebih rendah sebagai bug, dan tetaplah waspada, karena serangan baru terhadap algoritme dan protokol selalu dikembangkan.

Membuat URL intrasitus relatif

Karena sekarang Anda melayani situs di HTTP maupun HTTPS, segala sesuatunya perlu bekerja semulus mungkin, apa pun protokolnya. Faktor penting adalah menggunakan URL relatif untuk link intrasitus.

Pastikan URL intrasitus dan URL eksternal tidak bergantung pada protokol tertentu. Gunakan jalur relatif atau hapus protokol seperti di //example.com/something.js.

Menayangkan halaman yang berisi resource HTTP menggunakan HTTPS dapat menyebabkan masalah. Saat menemukan halaman yang aman menggunakan resource yang tidak aman, browser akan memperingatkan pengguna bahwa halaman tersebut tidak sepenuhnya aman, dan beberapa browser menolak memuat atau menjalankan resource HTTP, yang akan merusak halaman. Namun, Anda dapat menyertakan resource HTTPS dengan aman di halaman HTTP. Untuk panduan selengkapnya tentang cara memperbaiki masalah ini, lihat Memperbaiki Konten Campuran.

Mengikuti link berbasis HTTP ke halaman lain di situs Anda juga dapat mendowngrade pengalaman pengguna dari HTTPS ke HTTP. Untuk memperbaikinya, buat URL intrasitus Anda serelatif mungkin, dengan membuatnya protokol-relatif (tidak memiliki protokol, dimulai dengan //example.com) atau host-relatif (dimulai dengan jalur saja, seperti /jquery.js).

Anjuran
<h1>Welcome To Example.com</h1>
<script src="/jquery.js"></script>
<link rel="stylesheet" href="/assets/style.css"/>
<img src="/images/logo.png"/>;
<p>A <a href="/2014/12/24">new post on cats!</a></p>
 Gunakan URL intrasitus relatif.
Anjuran
<h1>Welcome To Example.com</h1>
<script src="//example.com/jquery.js"></script>
<link rel="stylesheet" href="//assets.example.com/style.css"/>
<img src="//img.example.com/logo.png"/>;
<p>A <a href="//example.com/2014/12/24/">new post on cats!</a></p>
 Atau, gunakan URL intrasitus yang protokol-relatif.
Anjuran
<h1>Welcome To Example.com</h1>
<script src="/jquery.js"></script>
<link rel="stylesheet" href="/assets/style.css"/>
<img src="/images/logo.png"/>;
<p>A <a href="/2014/12/24">new post on cats!</a></p>
<p>Check out this <a href="https://foo.com/"><b>other cool site.</b></a></p>
 Gunakan URL HTTPS untuk link ke situs lain jika memungkinkan.

Perbarui tautan Anda dengan skrip, bukan dengan tangan, untuk menghindari kesalahan. Jika konten situs Anda ada dalam database, uji skrip Anda di salinan pengembangan database. Jika konten situs Anda hanya terdiri dari file sederhana, uji skrip Anda pada salinan pengembangan file tersebut. Kirim perubahan ke production hanya setelah perubahan lulus QA, seperti biasa. Anda dapat menggunakan skrip Bram van Damme atau yang serupa untuk mendeteksi konten campuran di situs Anda.

Saat menautkan ke situs lain (bukan menyertakan resource dari sana), jangan ubah protokol. Anda tidak memiliki kontrol atas cara beroperasi situs tersebut.

Untuk membuat proses migrasi lebih mulus bagi situs besar, sebaiknya gunakan URL protokol-relatif. Jika Anda belum yakin apakah bisa menerapkan HTTPS sepenuhnya, memaksa situs Anda untuk menggunakan HTTPS bagi semua sub-resource malah akan merugikan. Mungkin ada periode waktu ketika HTTPS masih baru dan aneh bagi Anda, dan situs HTTP harus tetap berfungsi seperti biasa. Seiring waktu, Anda akan menyelesaikan migrasi dan mengunci HTTPS (lihat dua bagian berikutnya).

Jika situs Anda bergantung pada skrip, gambar, atau resource lainnya yang dilayani dari pihak ketiga, seperti CDN atau jquery.com, Anda memiliki dua opsi:

  • Gunakan URL protokol-relatif untuk resource ini. Jika pihak ketiga tidak melayani HTTPS, mintalah mereka melakukannya. Sebagian besar sudah melakukannya, termasuk jquery.com.
  • Layani resource dari server yang Anda kontrol, yang menawarkan HTTP dan HTTPS. Sering kali ini merupakan ide bagus, karena nanti Anda memiliki kontrol yang lebih baik atas tampilan, performa, dan keamanan situs, dan tidak perlu mempercayai pihak ketiga untuk menjaga keamanan situs Anda.

Mengalihkan HTTP ke HTTPS

Untuk memberi tahu mesin telusur agar menggunakan HTTPS agar dapat mengakses situs Anda, tempatkan link kanonis di awal setiap halaman menggunakan tag <link rel="canonical" href="https://…"/>.

Mengaktifkan Strict Transport Security dan cookie aman

Pada tahap ini, Anda siap untuk "mengunci" penggunaan HTTPS:

  • Gunakan HTTP Strict Transport Security (HSTS) untuk menghindari biaya pengalihan 301.
  • Selalu setel flag Secure pada cookie.

Pertama, gunakan Strict Transport Security untuk memberi tahu klien bahwa mereka harus selalu terhubung ke server Anda menggunakan HTTPS, bahkan saat mengikuti referensi http://. Tindakan ini akan mengalahkan serangan seperti SSL Stripping, dan menghindari biaya bolak-balik 301 redirect yang kita aktifkan di Redirect HTTP to HTTPS.

Untuk mengaktifkan HSTS, tetapkan header Strict-Transport-Security. Halaman HSTS OWASP berisi link ke petunjuk untuk berbagai jenis software server.

Sebagian besar server web menawarkan kemampuan yang serupa untuk menambahkan header kustom.

Anda juga harus memastikan klien tidak pernah mengirim cookie (misalnya untuk autentikasi atau preferensi situs) melalui HTTP. Misalnya, jika cookie autentikasi pengguna ditampilkan dalam teks biasa, jaminan keamanan untuk seluruh sesinya akan dihapus, meskipun Anda telah melakukan langkah lainnya dengan benar.

Untuk menghindari hal ini, ubah aplikasi web Anda agar selalu menyetel flag Secure pada cookie yang ditetapkan. Halaman OWASP ini menjelaskan cara menyetel flag Secure di beberapa framework aplikasi. Setiap framework aplikasi memiliki cara untuk menyetel flag.

Sebagian besar server web menawarkan fitur pengalihan sederhana. Gunakan 301 (Moved Permanently) untuk menunjukkan kepada mesin telusur dan browser bahwa versi HTTPS bersifat kanonis, dan mengalihkan pengguna ke versi HTTPS situs Anda dari HTTP.

Menelusuri peringkat

Google menggunakan HTTPS sebagai indikator kualitas penelusuran positif. Google juga memublikasikan panduan cara mentransfer, memindahkan, atau memigrasikan situs Anda dengan tetap mempertahankan peringkat penelusurannya. Bing juga memublikasikan pedoman untuk webmasters.

Performa

Jika lapisan konten dan aplikasi disesuaikan dengan baik (lihat buku Steve Souders untuk mendapatkan saran), masalah performa TLS yang tersisa umumnya kecil dibandingkan dengan biaya keseluruhan aplikasi. Anda juga dapat mengurangi dan menyusutkan biaya tersebut. Untuk mendapatkan saran tentang optimalisasi TLS, lihat High Performance Browser Networking oleh Ilya Grigorik, serta OpenSSL Cookbook dan Bulletproof SSL And TLS oleh Ivan Ristic.

Dalam beberapa kasus, TLS dapat meningkatkan performa, terutama karena memungkinkan HTTP/2. Untuk informasi selengkapnya, lihat presentasi Chris Palmer tentang performa HTTPS dan HTTP/2 di Chrome Dev Summit 2014.

Header perujuk

Saat pengguna mengikuti link dari situs HTTPS ke situs HTTP lain, agen pengguna tidak akan mengirim header Perujuk. Jika ini masalahnya, ada beberapa cara untuk mengatasinya:

  • Situs lainnya harus bermigrasi ke HTTPS. Jika situs penerima rujukan menyelesaikan bagian Mengaktifkan HTTPS di server Anda dalam panduan ini, Anda dapat mengubah link di situs Anda ke situs penerima rujukan dari http:// menjadi https:// atau menggunakan link protokol-relatif.
  • Untuk mengatasi beragam masalah pada header Referer, gunakan standar Kebijakan Referrer baru.

Pendapatan iklan

Operator situs yang memonetisasi situsnya dengan menampilkan iklan ingin memastikan migrasi ke HTTPS tidak mengurangi tayangan iklan. Namun, karena masalah keamanan konten campuran, <iframe> HTTP tidak berfungsi di halaman HTTPS. Sebelum pengiklan memublikasikan melalui HTTPS, operator situs tidak dapat bermigrasi ke HTTPS tanpa kehilangan pendapatan iklan; tetapi sebelum operator situs bermigrasi ke HTTPS, pengiklan memiliki sedikit motivasi untuk memublikasikan HTTPS.

Anda dapat memulai proses untuk mengatasi kebuntuan ini dengan menggunakan pengiklan yang menawarkan layanan iklan melalui HTTPS, dan meminta pengiklan yang sama sekali tidak menggunakan HTTPS untuk setidaknya menjadikannya sebagai opsi. Anda mungkin perlu menunda penyelesaian Membuat URL IntraSitus relatif hingga cukup banyak pengiklan yang melakukan interoperasi dengan benar.