Nginx configurato con http2 non fornisce HTTP / 2

Ho un problema con la mia configurazione Nginx. Ho eseguito l'aggiornamento a nginx 1.9.6 per testare http / 2 ma non funziona sul mio server.

Ho usato Ubuntu 14.04.2 LTS

Questo è l'output nginx -V:

nginx version: nginx/1.9.6
built with OpenSSL 1.0.2d 9 Jul 2015
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-log-path=/var/log/nginx/access.log --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --lock-path=/var/lock/nginx.lock --pid-path=/var/run/nginx.pid --with-pcre-jit --with-debug --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_geoip_module --with-http_gzip_static_module --with-http_image_filter_module --with-http_realip_module --with-http_stub_status_module --with-http_ssl_module --with-http_sub_module --with-http_xslt_module --with-http_v2_module --with-stream --with-ipv6 --with-mail --with-mail_ssl_module --with-openssl=/build/nginx-GFP362/nginx-1.9.6/debian/openssl-1.0.2d --add-module=/build/nginx-GFP362/nginx-1.9.6/debian/modules/nginx-auth-pam --add-module=/build/nginx-GFP362/nginx-1.9.6/debian/modules/nginx-echo --add-module=/build/nginx-GFP362/nginx-1.9.6/debian/modules/nginx-upstream-fair --add-module=/build/nginx-GFP362/nginx-1.9.6/debian/modules/nginx-dav-ext-module --add-module=/build/nginx-GFP362/nginx-1.9.6/debian/modules/nginx-cache-purge

E questa è la mia configurazione del vhost:

server {
    listen         80;
    server_name    localhost;
    return         301 https://$server_name$request_uri;
}

server {
    listen 443 ssl http2; ## listen for ipv4; this line is default and implied

    root /var/www/rendez-vous;
    index index.phtml index.html index.htm;

    # Make site accessible from http://localhost/
    server_name localhost;
    ssl_certificate /etc/nginx/certificates/myeventsportal/server.crt;
    ssl_certificate_key /etc/nginx/certificates/myeventsportal/server.key;

/...

Se accedo al mio sito con l'ultima versione di Chrome, viene offerto solo su http / 1.1.

Ho appena incontrato lo stesso problema, ma penso di sapere perché succede. nginx 1.9.6 non è un pacchetto stock su Ubuntu 14.04, quindi probabilmente lo si ottiene da un PPA nginx . Va bene, ma quei pacchetti sono costruiti con le librerie di magazzino dal 14.04, vale a dire OpenSSL 1.0.1f. Sfortunatamente quella versione di OpenSSL non contiene il supporto ALPN RFC7301 necessario per una corretta negoziazione HTTP / 2; supporta solo l'NPN ora deprecato. Sembra che Chrome abbia già rimosso il supporto per NPN, quindi non è in grado di negoziare una connessione HTTP / 2 senza ALPN. Firefox 41 d'altra parte, ha ancora il supporto NPN e dovresti essere in grado di usare HTTP / 2 con quello.

Puoi testare il tuo server in questo modo - avrai bisogno di OpenSSL 1.0.2d installato sul tuo client (esegui openssl versionper verificare):

Test con ALPN:

echo | openssl s_client -alpn h2 -connect yourserver.example.com:443 | grep ALPN

Se ALPN funziona, dovresti vedere:

ALPN protocol: h2

altrimenti otterrai:

No ALPN negotiated

Test con NPN:

echo | openssl s_client -nextprotoneg h2 -connect yourserver.example.com:443

Se funziona, otterrai:

Next protocol: (1) h2
No ALPN negotiated

Ciò significa che sta negoziando con successo una connessione HTTP / 2 tramite NPN, che è ciò che fa Firefox.

Quindi come risolverlo? L'unico modo in cui posso vedere è installare una build successiva di openssl da un PPA (io uso questa per PHP, che contiene anche openssl) e creare la tua nginx collegata ad essa. Puoi trovare i parametri di configurazione per la tua build nginx esistente eseguendo nginx -Ve dovresti essere in grado di usarla per creare la tua versione.

Aggiornamento : ho scoperto che il motivo per cui Chrome non supporta HTTP / 2 con NPN non è che non supporta NPN (anche se verrà abbandonato a un certo punto), ma che in particolare non supporta h2 con NPN, come mostrato nella pagina chrome: // net-internals / # http2:

Versione breve.

Ho scoperto che l'antivirus ESET può impedire il funzionamento di HTTP / 2 quando il filtro SSL / TLS è attivato sul computer di navigazione. Verifica che l'antivirus non stia filtrando SSL / TLS.

Versione TLDR

Ho riscontrato lo stesso problema del poster, ma con una svolta interessante. Ho aggiornato la configurazione del mio server a nginx 1.12.1. compilato con OpenSSL 1.0.2.g e durante l'ispezione iniziale aveva "risolto" il problema di HTTP / 2 non funzionante. Nel mio browser, ho potuto vedere che il certificato del server è stato verificato da Let's Encrypt. Anche il contenuto veniva offerto con HTTP / 2.

Qualche tempo dopo, ho scoperto che la stessa pagina e le stesse risorse non venivano più offerte su HTTP / 2. Per coincidenza, il sito non è stato più verificato da Let's Encrypt, ma da Eset? !!?! Con mia grande sorpresa, il nuovo problema http2 non aveva assolutamente nulla a che fare con la configurazione del mio server. Si è scoperto che avevo il filtro SSL / TLS attivato nel mio antivirus sul mio computer locale e questo stava causando il problema. La soluzione era disattivare il filtro SSL / TLS nell'antivirus. Una volta spento (e riavviato il computer) HTTP / 2 ha funzionato di nuovo e il certificato è stato nuovamente verificato da Let's Encrypt.

Per istruzioni su come disattivare SSL / TLS in ESET, consultare http://support.eset.com/kb3126/?locale=en_US

Come dice Synchro nella sua risposta, il problema è che la maggior parte dei pacchetti nginx non sono compilati con OpenSSL 1.0.2. La compilazione di ALPN richiede simboli presenti solo nella fonte di sviluppo OpenSSL pertinente.

Potresti provare a usare la distribuzione ufficiale di nginx , selezionando xenial piuttosto che fidato. Questo funziona per me con Debian Jessie e jessie-backports OpenSSL 1.0.2 - potrebbe funzionare per te. Tuttavia, tieni presente che si tratta di una configurazione non supportata: ricostruirla è la risposta "giusta".