Nginx SSL

Da biste konfigurisali HTTPS server, potrebno je da uključite parametar ssl na slušajućim soketima u bloku server, kao i da navedete lokaciju datoteka sa sertifikatom servera i tajnim ključem:

server {
    listen              443 ssl;
    server_name         www.example.com;
    ssl_certificate     www.example.com.crt;
    ssl_certificate_key www.example.com.key;
    ssl_protocols       SSLv3 TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers         HIGH:!aNULL:!MD5;
    ...
}

Sertifikat servera je javan. On se šalje svakom klijentu koji se povezuje sa serverom. Tajni ključ treba čuvati u datoteci sa ograničenim pristupom (prava pristupa moraju dozvoliti glavnom procesu nginx da čita tu datoteku). Tajni ključ se takođe može čuvati u istoj datoteci kao i sertifikat:

    ssl_certificate     www.example.com.cert;
    ssl_certificate_key www.example.com.cert;

uz ograničavanje prava pristupa datoteci. Iako se i sertifikat i ključ čuvaju u istoj datoteci, klijentu se šalje samo sertifikat.

Komandama ssl_protocols i ssl_ciphers može se ograničiti povezivanje tako da se koriste samo „jake“ verzije i šifre SSL/TLS. Počevši od verzije 1.0.5, nginx podrazumevano koristi „ssl_protocols SSLv3 TLSv1“ i „ssl_ciphers HIGH:!aNULL:!MD5“, pa je njihovo eksplicitno podešavanje smisleno samo za starije verzije nginx-a. Počevši od verzija 1.1.13 i 1.0.12, nginx podrazumevano koristi „ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2“.

Poznato je da šifre sa CBC režimom rane su na niz napada, uključujući BEAST napad (vidi CVE-2011-3389). Podešavanje šifri može se promeniti tako da se preferira RC4-SHA:

    ssl_ciphers RC4:HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers on;

Optimizacija HTTPS servera

SSL operacije zahtevaju dodatne resurse procesora. Na sistemima sa više procesora treba pokrenuti više radnih procesa, najmanje onoliko koliko ima dostupnih procesorskih jezgara. Najzahtevnija operacija za procesor je SSL rukovanje (handshake), tokom kojeg se formiraju kriptografski parametri sesije. Postoje dva načina za smanjenje broja ovih operacija koje se izvršavaju za svakog klijenta: korišćenje trajnih (keepalive) veza, koje omogućavaju obradu više zahteva unutar jedne veze, i ponovno korišćenje parametara SSL sesije kako bi se sprečila potreba za izvršavanjem SSL rukovanja za paralelne i naredne veze. Sesije se čuvaju u kešu SSL sesija, koji je podeljen između radnih procesa i konfigurisan komandom ssl_session_cache. U 1 megabajt keša stane oko 4000 sesija. Podrazumevani timeout keša je 5 minuta. Može se povećati pomoću komande ssl_session_timeout. Evo primera konfiguracije optimizovane za sistem sa više jezgara sa 10-megabajtnim podeljenim kešem sesija:

worker_processes auto;

http {
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 10m;

    server {
        listen              443 ssl;
        server_name         www.example.com;
        keepalive_timeout 70;

        ssl_certificate     www.example.com.crt;
        ssl_certificate_key www.example.com.key;
        ssl_protocols       SSLv3 TLSv1 TLSv1.1 TLSv1.2;
        ssl_ciphers         HIGH:!aNULL:!MD5;
        ...

Lanci SSL sertifikata

Neki preglednici mogu prikazati upozorenje o sertifikatu koji je potpisao dobro poznati centar za sertifikaciju, dok drugi preglednici bez problema prihvataju isti taj sertifikat. Do toga dolazi zato što je centar koji je izdao sertifikat potpisao ga pomoću međusertifikata, koji se ne nalazi u bazi podataka sertifikata dobro poznatih poverljivih centara za sertifikaciju, koja se distribuira zajedno sa preglednikom. U takvim slučajevima centar za sertifikaciju obezbeđuje „snop“ sertifikata koji treba da se pridruži sertifikatu servera. Sertifikat servera treba da bude postavljen ispred snopa sertifikata u kombinovanom fajlu:

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

Dobijeni fajl treba da se navede u direktivi ssl_certificate:

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

Ako su sertifikat servera i snop sertifikata spojeni u pogrešnom redosledu, nginx će odbiti da pokrene i prikazaće poruku o grešci:

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

jer će nginx pokušati da koristi tajni ključ sa prvim sertifikatom iz snopa, umesto sertifikata servera.

Preglednici obično čuvaju dobijene međusertifikate koje su potpisali poverljivi centri za sertifikaciju, tako da aktivno korišćeni preglednici već mogu imati potrebne međusertifikate i neće prikazati upozorenje o sertifikatu koji je poslat bez lanca sertifikata koji mu pripada. Možete se uveriti da server šalje pun lanac sertifikata pomoću alata u komandnoj liniji openssl, na primer:

$ 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
...

U ovom primeru subjekt („s“) sertifikata br. 0 servera www.GoDaddy.com je potpisan od strane izdavača („i“), koji je ujedno subjekt sertifikata br. 1, koji je potpisan od strane izdavača, koji je ujedno subjekt sertifikata br. 2, potpisan od strane dobro poznatog izdavača ValiCert, Inc., čiji se sertifikat nalazi u ugrađenoj bazi podataka sertifikata preglednika (koja se u tamnom ormariću čuva u kući koju je sagradio Džek).

Ako snop sertifikata nije dodat, biće prikazan samo sertifikat servera br. 0.

Jedinstveni HTTP/HTTPS server

Može se konfigurisati jedinstveni server koji obrađuje i HTTP i HTTPS zahteve:

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

Do verzije 0.7.14 SSL se nije mogao uključiti selektivno za pojedinačne socketove slušanja, kao što je prikazano gore. SSL se mogao uključiti samo za ceo server, pomoću direktive ssl, što nije omogućavalo konfigurisanje jedinstvenog HTTP/HTTPS servera. Za rešavanje ovog problema dodata je opcija ssl direktive listen. Stoga se u modernim verzijama ne preporučuje korišćenje direktive ssl.

Izbor HTTPS servera po imenu

Tipičan problem nastaje pri konfigurisanju dva ili više HTTPS servera koji slušaju na istoj IP adresi:

server {
    listen          443 ssl;
    server_name     www.example.com;
    ssl_certificate www.example.com.crt;
    ...
}

server {
    listen          443 ssl;
    server_name     www.example.org;
    ssl_certificate www.example.org.crt;
    ...
}

U ovoj konfiguraciji, pregledač će dobiti podrazumevani sertifikat servera, odnosno www.example.com, bez obzira na traženo ime servera. To je posledica ponašanja SSL protokola. SSL veza se uspostavlja pre nego što pregledač pošalje HTTP zahtev, pa nginx ne zna ime traženog servera. Stoga, on može da ponudi samo podrazumevani sertifikat servera.

Najstariji i najpouzdaniji način rešavanja ovog problema je dodeljivanje svakom HTTPS serveru sopstvene IP adrese:

server {
    listen          192.168.1.1:443 ssl;
    server_name     www.example.com;
    ssl_certificate www.example.com.crt;
    ...
}

server {
    listen          192.168.1.2:443 ssl;
    server_name     www.example.org;
    ssl_certificate www.example.org.crt;
    ...
}

SSL sertifikat sa više imena

Postoje i drugi načini koji omogućavaju korišćenje iste IP adrese za više HTTPS servera istovremeno. Međutim, svi oni imaju svoje mane. Jedan od takvih načina je korišćenje sertifikata sa više imena u polju SubjectAltName sertifikata, na primer www.example.com i www.example.org. Ipak, dužina polja SubjectAltName je ograničena.

Drugi način je korišćenje wildcard sertifikata, na primer *.example.org. Ovaj sertifikat štiti sve poddomene navedenog domena, ali samo na određenom nivou. Za ovaj sertifikat odgovara www.example.org, ali ne odgovaraju example.org i www.sub.example.org. Oba navedena načina se mogu kombinovati. Sertifikat može istovremeno sadržati i tačna i wildcard imena u polju SubjectAltName, na primer example.org i *.example.org.

Preporučuje se da se informacije o fajlu sertifikata sa više imena i fajlu sa njegovim tajnim ključem postave na nivou konfiguracije http, kako bi svi serveri nasledili jedinstvenu kopiju u memoriji:

ssl_certificate     common.crt;
ssl_certificate_key common.key;

server {
    listen          443 ssl;
    server_name     www.example.com;
    ...
}

server {
    listen          443 ssl;
    server_name     www.example.org;
    ...
}