Routeros Mikrotik Tutorial - Mengkonfigurasi HTTPS Server di Nginx

 

Untuk mengkonfigurasi HTTPS server, Anda harus mengaktifkan protokol SSL di blok server, dan menuliskan lokasi dari berkas server certificate dan private key:

server { listen 443; server_name www.nginx.com; ssl on; ssl_certificate www.nginx.com.crt; ssl_certificate_key www.nginx.com.key; ssl_protocols SSLv3 TLSv1; ssl_ciphers HIGH:!ADH:!MD5; ... }

Server certificate ialah entitas publik. Ini akan dikirim ke setiap klien yang terhubung ke server. Sedangkan private key ialah entitas keamanan dan harus disimpan dalam berkas dengan susukan terbatas, tapi walau terbatas harus mampu dibaca oleh master proses nginx. Private key mampu juga disimpan dalam berkas sama sebagai certificate:

ssl_certificate www.nginx.com.cert; ssl_certificate_key www.nginx.com.cert;

yang dalam kasus ini susukan ke berkas juga harus dibatasi. Meskipun akta dan kuncinya disimpan dalam satu berkas, hanya adegan certificate yang akan dikirim ke klien.
Direktif “ssl_protocols” dan “ssl_chipers” mungkin mampu digunakan untuk membatasi koneksi ke versi aman/kuat (strong) protokol SSL dan chipers. Sejak versi 0.8.20, nginx menggunakan “ssl_protocols SSLv3 TLSv1” dan “ssl_chipers HIGH:!ADH:!MD5” pada konfigurasi default, jadi semua itu hanya harus diset kalau menggunakan versi nginx sebelumnya.

Optimasi HTTPS server

Operasi SSL mengkonsumsi sumberdaya CPU lebih banyak. Pada sistem multi prosesor Anda sebaiknya menjalankan beberapa worker processes: tidak lebih sedikit dari jumlah CPU core yang tersedia. Operasi yang paling banyak memakai sumberdaya CPU ialah pada dikala SSL handshake.
Ada dua cara untuk meminimalkan jumlah operasi ini per klien: yang pertama ialah mengaktifkan keepalive connections untuk mengirimkan beberapa request melalui satu koneksi dan yang kedua ialah untuk menggunakan ulang sesi SSL untuk menghindari SSL handshake untuk koneksi parallel dan subsequent connections. Sesi-sesi ini disimpan dalam SSL session cache yang di share antara worker dan dikonfigurasi oleh direktif “ssl_session_cache“. Satu megabyte dari cache mampu menyimpan sekitar 4000 sesi. Nilai default untuk cache timeout ialah 5 menit. Dan bias dinaikkan menggunakan direktif “ssl_session_timeout“.
Berikut ini ialah pola konfigurasi yang sudah dioptimasi untuk sistem quad core dengan 10M shared session cache:

worker_processes 4;   http { ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m;   server { listen 443; server_name www.nginx.com; keepalive_timeout 70;   ssl on; ssl_certificate www.nginx.com.crt; ssl_certificate_key www.nginx.com.key; ssl_protocols SSLv3 TLSv1; ssl_ciphers HIGH:!ADH:!MD5; ...

SSL certifcate chains

Beberapa peramban mungkin komplen wacana akta yang ditandatangani oleh well-kown certificate authority, sementara peramban lainnya mungkin mendapatkan akta tanpa masalah. Hal ini terjadi karena yang mengeluarkan otoritas telah menandatangi akta server menggunakan akta perantara (intermediate certificate) yang tidak tersedia di basis akta dari well-known trusted certificate authorities, tapi dilain sisi akta ini mungkin didistribusikan di sebagian peramban lainnya. Dalam kasus ini si otoritas biasanya menyediakan satu bundle chained certificates yang harus di gabungkan (concatenated) ke akta yang telah ditandatangani. Sertifikat harus muncul sebelum chained certificates pada berkas yang sudah digabung:

$ cat www.nginx.com.crt bundle.crt > www.nginx.com.chained.crt

Berkas yang dihasilkan digunakan dalam direktif “ssl_certificate“:

server { listen 443; server_name www.nginx.com; ssl on; ssl_certificate www.nginx.com.chained.crt; ssl_certificate_key www.nginx.com.key; ... }

Jika sertifikate server dan bunel sudah digabungkan dalam urutan yang salah, nginx akan gagal dijalankan dan akan menampilkan pesan error:

SSL_CTX_use_PrivateKey_file(" ... /www.nginx.com.key") failed (SSL: error:0B080074:x509 certificate routines: X509_check_private_key:key values mismatch)

karena nginx mencoba menggunakan private key dengan certifikat pertama dari bundle dan bukan ke akta server yang seharusnya.
Peramban biasanya menyimpan akta perantara yang mereka terima dan yang ditandatangani oleh otoritas terpercaya, jadi peramban yang sudah digunakan secara aktif mungkin sudah memiliki akta perantara yang diharapkan dan tidak akan komplen wacana akta yang dikirim tanpa bundle. Untuk meyakinkan server mengirimkan certificate chain yang lengkap, Anda mampu menggunakan perintah “openssl“, misalnya:

$ openssl s_client -connect www.godaddy.com:443

... Certificate chain 0 s:/C=US/ST=Arizona/L=Scottsdale/1.3.6.1.4.1.311.60.2.1.3=US /1.3.6.1.4.1.311.60.2.1.2=AZ/O=GoDaddy.com, Inc /OU=MIS Department/CN=www.GoDaddy.com /serialNumber=0796928-7/2.5.4.15=V1.0, Clause 5.(b) i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc. /OU=http://certificates.godaddy.com/repository /CN=Go Daddy Secure Certification Authority /serialNumber=07969287 1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc. /OU=http://certificates.godaddy.com/repository /CN=Go Daddy Secure Certification Authority /serialNumber=07969287 i:/C=US/O=The Go Daddy Group, Inc. /OU=Go Daddy Class 2 Certification Authority 2 s:/C=US/O=The Go Daddy Group, Inc. /OU=Go Daddy Class 2 Certification Authority i:/L=ValiCert Validation Network/O=ValiCert, Inc. /OU=ValiCert Class 2 Policy Validation Authority /CN=http://www.valicert.com//emailAddress=info@valicert.com ...

Di pola ini subject (“s”) dari akta server www.GoDaddy.com #0 ditandatangani oleh issuer (“i”) yang merupakan subject dari akta #1, yang juga ditandatangani oleh issuer yang merupakan subject dari certificate #2, yang ditandatangani oleh well-known issuer ValiCert, Inc. Semua akta itu disimpan di built-in certificate base dari peramban.
Jika Anda tidak menambahkan certificate bundle, Anda hanya akan melihat sertifikate server #0.

A single HTTP/HTTPS server

Merupakan langkah yang baik untuk mengkonfigurasi server secara terpisah untuk protokol HTTP dan HTTPS dari semenjak awal. Meskipun mungkin fungsionalitas mereka terlihat mirip, tapi ini mampu saja berubah secara signifikan di masa yang akan datang dan menggunakan server yang digabung mungkin akan menjadi masalah. Walau demikian, kalau server HTTP dan HTTPS ialah sama, dan Anda tidak ingin berfikir wacana masa yang akan datang, Anda mampu mengkonfigurasi satu server tunggal yang menangani request HTTP dan HTTPS dengan menghapus direktif “ssl on” dan menambahkan parameter “ssl” untuk port *:443

server { listen 80; listen 443 ssl; server_name www.nginx.com; ssl_certificate www.nginx.com.crt; ssl_certificate_key www.nginx.com.key; ... }

Semenjak versi 0.8.21, nginx hanya membolehkan parameter “ssl” di set pada socket yang di listen dengan parameter “default”:

listen 443 default ssl;

Name-based HTTPS servers

Biasanya muncul problem umum ketika mengkonfigurasi dua atau lebih server HTTPS yang listening pada satu alamat IP:

server { listen 443; server_name www.nginx.com; ssl on; ssl_certificate www.nginx.com.crt; ... }   server { listen 443; server_name www.nginx.org; ssl on; ssl_certificate www.nginx.org.crt; ... }

Dengan konfigurasi ini, peramban mendapatkan akta dari default server, misalnya, www.nginx.com tanpa terpengaruh dengan server name yang direquest. Ini disebabkan karena sifat dari protokol SSL. Koneksi SSL terjadi sebelum browser mengirim request HTTP dan nginx tidak akan pernah tahu nama dari server yang direquest. Oleh karena itu, ia hanya akan menyampaikan satu akta dari default server.
Cara lama dan yang paling tokcer untuk mengatasi problem ini ialah dengan membuat alamat IP terpisah untuk setiap HTTPS server:

server { listen 192.168.1.1:443; server_name www.nginx.com; ssl on; ssl_certificate www.nginx.com.crt; ... }   server { listen 192.168.1.2:443; server_name www.nginx.org; ssl on; ssl_certificate www.nginx.org.crt; ... }

Sertifikat SSL dengan beberapa nama

Ada cara lain untuk menyebarkan alamat IP antara beberapa HTTPS server, meskipun demikian, semuanya memiliki kelemahan. Salah satu cara ialah menggunakan akta dengan beberapa nama pada adegan SubjectAltName di sertifikat. Sebagai pola misalnya, www.nginx.com dan www.nginx.org. Tapi, adegan SubjectAltName memiliki panjang yang terbatas.
Cara lain ialah menggunakan akta dengan wildcard name, misalnya, *.nginx.org. Sertifikat ini akan cocok dengan www.nginx.org, tapi tidak akan cocok dengan nginx.org dan www.sub.nginx.org. Dua metode tadi, mampu juga dikombinasikan. Sertifikat mampu saja berisikan exact dan wildcard name pada adegan SubjectAltName, misalnya, nginx.org dan *.nginx.org.
Akan lebih baik untuk menyimpan berkas akta dengan beberapa nama dan berkas kunci privatenya pada level http dari berkas konfigurasi, biar di inherit ke semua server dari satu salinan memori.

ssl_certificate common.crt; ssl_certificate_key common.key;   server { listen 443; server_name www.nginx.com; ssl on; ... }   server { listen 443; server_name www.nginx.org; ssl on; ... }

Server Name Indication

Solusi yang lebih mendasar untuk menjalankan beberapa server HTTPS pada satu alamat IP tunggal ialah menggunakan TLSv1.1 Server Name Indication extension (SNI, RFC3546), dimana ia membolehkan peramban melanjutkan request server name pada dikala SSL handshake, dan selanjutnya, server akan tahu akta yang mana yang harus digunakan untuk koneksi tersebut. Tapi SNI memiliki santunan peramban yang terbatas. Saat ini santunan fitur mulai ada di beberapa versi peramban berikut:
Opera 8.0;
MSIE 7.0 (hanya untuk Windows Vista atau versi lebih tinggi);
Firefox 2.0 dan peramban lain yang menggunakan platform Mozilla Platform rv:1.8.1;
Safari 3.2.1 (Versi Windows mendukung SNI pada Vista atau versi lebih baru);
dan Chrome (Versi Windows mendukung SNI pada Vista atau versi lebih baru).
Untuk menggunakan SNI di nginx, ini harus didukung oleh pustaka OpenSSL yang mana dikala nginx dibangun juga oleh pustakan yang sedang ditautkan secara dinamik dikala dijalankan. OpenSSL sudah mendukung SNI semenjak versi 0.9.8f kalau ia dibangun dengan opsi konfigurasi “--enable-tlsext“. Sejak OpenSSL 0.8.9j opsi ini diaktifkan secara default. Jika nginx sudah dibangun dengan santunan SNI, maka nginx akan menampilkan ini ketika dijalankan dengan pilihan “-V”:

$ nginx -V ... TLS SNI support enabled ...

Akan tetapi, kalau nginx yang sudah diaktifkan SNI nya, tapi ditautkan secara dinamik ke pustaka OpenSSl yang tidak memiliki santunan SNI, ngixn akan menampilkan peringatan:

nginx was built with SNI support, however, now it is linked dynamically to an OpenSSL library which has no tlsext support, therefore SNI is not available

Kompatibilitas

The SNI support status has been shown by the “-V” switch since 0.8.21 and 0.7.62.
The “ssl” parameter of the “listen” directive has been supported since 0.7.14.
SNI has been supported since 0.5.32.
The shared SSL session cache has been supported since 0.5.6.
Version 0.8.19 and later: the default SSL protocols are SSLv3 and TLSv1.
Version 0.8.18 and earlier: the default SSL protocols are SSLv2, SSLv3, and TLSv1.
Version 0.8.20 and later: the default SSL ciphers are “HIGH:!ADH:!MD5”.
Version 0.8.19: the default SSL ciphers are “ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM”.
Version 0.8.18 and earlier: the default SSL ciphers are
“ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP”.