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 adalah entitas publik. Ini akan dikirim ke setiap klien yang terhubung ke server. Sedangkan
private key
adalah entitas keamanan dan harus disimpan dalam berkas dengan akses
terbatas, tapi walau terbatas harus bisa dibaca oleh master proses
nginx.
Private key bisa juga disimpan dalam berkas sama sebagai
certificate:
ssl_certificate www.nginx.com.cert;
ssl_certificate_key www.nginx.com.cert;
|
yang dalam kasus ini akses ke berkas juga harus dibatasi. Meskipun
sertifikat dan kuncinya disimpan dalam satu berkas, hanya bagian
certificate yang akan dikirim ke klien.
Direktif “
ssl_protocols” dan “
ssl_chipers” mungkin bisa 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 jika 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 adalah pada saat
SSL handshake.
Ada dua cara untuk meminimalkan jumlah operasi ini per klien: yang pertama adalah mengaktifkan
keepalive connections untuk mengirimkan beberapa
request melalui satu koneksi dan yang kedua adalah 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 bisa menyimpan sekitar 4000 sesi. Nilai
default untuk cache timeout adalah 5 menit. Dan bias dinaikkan
menggunakan direktif “
ssl_session_timeout“.
Berikut ini adalah contoh 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 tentang sertifikat yang ditandatangani oleh
well-kown certificate authority,
sementara peramban lainnya mungkin menerima sertifikat tanpa masalah.
Hal ini terjadi karena yang mengeluarkan otoritas telah menandatangi
sertifikat server menggunakan sertifikat perantara (intermediate
certificate) yang tidak tersedia di basis sertifikat dari
well-known trusted certificate authorities,
tapi dilain sisi sertifikat ini mungkin didistribusikan di sebagian
peramban lainnya. Dalam kasus ini si otoritas biasanya menyediakan satu
bundle chained certificates yang harus di gabungkan (concatenated) ke
sertifikat 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 sertifikat server yang seharusnya.
Peramban biasanya menyimpan sertifikat perantara yang mereka terima
dan yang ditandatangani oleh otoritas terpercaya, jadi peramban yang
sudah digunakan secara aktif mungkin sudah memiliki sertifikat perantara
yang dibutuhkan dan tidak akan komplen tentang sertifikat yang dikirim
tanpa bundle. Untuk meyakinkan server mengirimkan certificate chain yang
lengkap, Anda bisa 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 contoh ini subject (“s”) dari sertifikat server www.GoDaddy.com #0
ditandatangani oleh issuer (“i”) yang merupakan subject dari sertifikat
#1, yang juga ditandatangani oleh issuer yang merupakan subject dari
certificate #2, yang ditandatangani oleh well-known issuer ValiCert,
Inc. Semua sertifikat 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 sejak awal. Meskipun mungkin
fungsionalitas mereka terlihat mirip, tapi ini bisa saja berubah secara
signifikan di masa yang akan datang dan menggunakan server yang
digabung mungkin akan menjadi masalah. Walau demikian, jika server HTTP
dan HTTPS adalah sama, dan Anda tidak ingin berfikir tentang masa yang
akan datang, Anda bisa 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”:
Name-based HTTPS servers
Biasanya muncul masalah 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 menerima sertifikat 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, dia hanya
akan menawarkan satu sertifikat dari default server.
Cara lama dan yang paling tokcer untuk mengatasi masalah ini adalah 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 berbagi alamat IP antara beberapa HTTPS server,
meskipun demikian, semuanya memiliki kelemahan. Salah satu cara adalah
menggunakan sertifikat dengan beberapa nama pada bagian SubjectAltName
di sertifikat. Sebagai contoh misalnya, www.nginx.com dan www.nginx.org.
Tapi, bagian SubjectAltName memiliki panjang yang terbatas.
Cara lain adalah menggunakan sertifikat 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, bisa juga dikombinasikan. Sertifikat bisa saja berisikan exact
dan wildcard name pada bagian SubjectAltName, misalnya, nginx.org dan
*.nginx.org.
Akan lebih baik untuk menyimpan berkas sertifikat dengan beberapa
nama dan berkas kunci privatenya pada level http dari berkas
konfigurasi, agar 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 adalah menggunakan TLSv1.1 Server Name
Indication extension (SNI, RFC3546), dimana dia membolehkan peramban
melanjutkan request server name pada saat SSL handshake, dan
selanjutnya, server akan tahu sertifikat yang mana yang harus digunakan
untuk koneksi tersebut. Tapi SNI memiliki dukungan peramban yang
terbatas. Saat ini dukungan 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 saat nginx dibangun juga oleh pustakan yang sedang
ditautkan secara dinamik saat dijalankan. OpenSSL sudah mendukung SNI
sejak versi 0.9.8f jika dia dibangun dengan opsi konfigurasi “
--enable-tlsext“.
Sejak OpenSSL 0.8.9j opsi ini diaktifkan secara default. Jika nginx
sudah dibangun dengan dukungan SNI, maka nginx akan menampilkan ini
ketika dijalankan dengan pilihan “-V”:
$ nginx -V
...
TLS SNI support enabled
...
Akan tetapi, jika nginx yang sudah diaktifkan SNI nya, tapi ditautkan
secara dinamik ke pustaka OpenSSl yang tidak memiliki dukungan 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”.
