HTTP2 domain redirect error with ssl_verify_client

[Jan Trejbal]

server {
        server_name www.domain.tld;
        listen 443 ssl;
        listen 80;
        ssl_certificate         /etc/nginx/certs/...;
        ssl_certificate_key     /etc/nginx/certs/...;
        include ssl.conf;
        ssl_trusted_certificate /etc/nginx/certs/...;

        rewrite ^ https://domain.tld$request_uri? permanent;
}
server {
        server_name domain.tld;
        listen 443 ssl http2;
        listen 80;
        ssl_certificate         /etc/nginx/certs/...; #trusted
        ssl_certificate_key     /etc/nginx/certs/...;
        include ssl.conf;
        ssl_trusted_certificate /etc/nginx/certs/...;

        ssl_client_certificate  /etc/nginx/certs/.../ca.crt; #not trusted
        ssl_verify_client       optional; #use this produce error

        location /log {
                if ($ssl_client_verify != SUCCESS) {
                        return 403;
                }
                ...
        }

        location / {
                ...
        }
}

ssl.conf:

ssl_dhparam dhparam.pem;
    
ssl_prefer_server_ciphers on;
    
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers 'EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4:EECDH:EDH+aRSA:RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4';

ssl_session_cache shared:SSL:50m;
ssl_session_timeout 5m;

ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;

Redirect in Chrome from ​https://www.domain.tld to ​https://domain.tld produce 400 Bad Request (on ​https://domain.tld) and browser do not ask for certificate.

In log I see:

2015/12/04 00:38:38 [notice] 48#48: *448 "^" matches "/", client: MY_IP, server: www.domain.tld, request: "GET / HTTP/2.0", host: "www.domain.tld"
2015/12/04 00:38:38 [notice] 48#48: *448 rewritten redirect: "https://domain.tld/", client: MY_IP, server: www.domain.tld, request: "GET / HTTP/2.0", host: "www.domain.tld"
2015/12/04 00:38:38 [info] 48#48: *448 client attempted to request the server name different from that one was negotiated while processing HTTP/2 connection, client: MY_IP, server: www.domain.tld, host: "domain.tld"

This occurs when ssl_verify_client is set to optional|optional_no_ca|on
With not used http2 all is well. (Browser redirect and ask for client certificate)

[Maxim Dounin]

No connection reuse between different SNI-selected server{} blocks is allowed by nginx as long as SSL client certificates are used. It looks like HTTP/2 authors didn't learn anything from early versions of SPDY and again try to reuse connections to different servers.

Valentin, please take a look, see ​https://tools.ietf.org/html/rfc7540#section-9.1.1 for details.

[Valentin V. Bartenev]

Please try the following patch:

diff -r b1858fc47e3b -r 4b24c76a65ef src/http/ngx_http_header_filter_module.c
--- a/src/http/ngx_http_header_filter_module.c  Fri Nov 06 15:22:43 2015 +0300
+++ b/src/http/ngx_http_header_filter_module.c  Mon Dec 07 16:02:22 2015 +0300
@@ -100,7 +100,7 @@ static ngx_str_t ngx_http_status_lines[]
     /* ngx_null_string, */  /* "418 unused" */
     /* ngx_null_string, */  /* "419 unused" */
     /* ngx_null_string, */  /* "420 unused" */
-    /* ngx_null_string, */  /* "421 unused" */
+    ngx_string("421 Misdirected Request"),
     /* ngx_null_string, */  /* "422 Unprocessable Entity" */
     /* ngx_null_string, */  /* "423 Locked" */
     /* ngx_null_string, */  /* "424 Failed Dependency" */
diff -r b1858fc47e3b -r 4b24c76a65ef src/http/ngx_http_request.c
--- a/src/http/ngx_http_request.c       Fri Nov 06 15:22:43 2015 +0300
+++ b/src/http/ngx_http_request.c       Mon Dec 07 16:02:22 2015 +0300
@@ -2062,7 +2062,7 @@ ngx_http_set_virtual_server(ngx_http_req
             ngx_log_error(NGX_LOG_INFO, r->connection->log, 0,
                           "client attempted to request the server name "
                           "different from that one was negotiated");
-            ngx_http_finalize_request(r, NGX_HTTP_BAD_REQUEST);
+            ngx_http_finalize_request(r, NGX_HTTP_MISDIRECTED_REQUEST);
             return NGX_ERROR;
         }
     }
diff -r b1858fc47e3b -r 4b24c76a65ef src/http/ngx_http_request.h
--- a/src/http/ngx_http_request.h       Fri Nov 06 15:22:43 2015 +0300
+++ b/src/http/ngx_http_request.h       Mon Dec 07 16:02:22 2015 +0300
@@ -95,6 +95,7 @@
 #define NGX_HTTP_REQUEST_URI_TOO_LARGE     414
 #define NGX_HTTP_UNSUPPORTED_MEDIA_TYPE    415
 #define NGX_HTTP_RANGE_NOT_SATISFIABLE     416
+#define NGX_HTTP_MISDIRECTED_REQUEST       421
 
 
 /* Our own HTTP codes */

[maxim]

Ticket retargeted after milestone closed

[Jan Trejbal]

Now it produce HTTP code 421 instead of 400, but same problem (do not show content of website)

[Maxim Dounin]

Well, if it doesn't work with 421 either, it's probably nothing that can be done on nginx side to prevent such inappropriate connection reuse. You should complain to browser vendors instead.

[Jan Trejbal]

Solved adding

server {
        server_name www.domain.tld;
        listen 443 ssl;

        http2_idle_timeout 10ms;
}

[hostmaster.myevo.net@…]

I have the same problem.
I'm using ssl_verify_client optional and different subdomains to identify different projects.
If someone has a valid certificate and then changes subdomain to access a different project, authentication is required again and everything works fine.
If someone hasn't any valid certificate, he can access the first subdomain without problems, but if he changes subdomain, he gets a 400 error (client attempted to request the server name different from that one was negotiated while reading client request headers).

I think that the server should simply authenticate again if subdomain changes in order to solve this.
Edit: I think that the server should simply accept connections for different subdomains if the server certificate is valid for both subdomains, since this is what it does when ssl_verify_client is turned off.

If ssl_verify_client is set to on or off, the problem disappears but I have to make changes to my web application to use only/avoid certificate authentication.
This happens with both Firefox and Chrome so I think I can't complain to browser vendors.
Meanwhile, I set http2_idle_timeout to 1s, but this reduces http2 advantages.

[hostmaster.myevo.net@…]

I upgraded now to 1.10.0. The problem is still there.

[Jan Trejbal]

Do you use same certificate to both subdomains?

[hostmaster.myevo.net@…]

Yes, certificate is the same for both subdomains.

[Valentin Bartenev <vbart@…>]

In 6556:654d2dae97d3/nginx:

HTTP/2: the "421 Misdirected Request" response (closes #848).

Since 4fbef397c753 nginx rejects with the 400 error any attempts of
requesting different host over the same connection, if the relevant
virtual server requires verification of a client certificate.

While requesting hosts other than negotiated isn't something legal
in HTTP/1.x, the HTTP/2 specification explicitly permits such requests
for connection reuse and has introduced a special response code 421.

According to RFC 7540 Section 9.1.2 this code can be sent by a server
that is not configured to produce responses for the combination of
scheme and authority that are included in the request URI. And the
client may retry the request over a different connection.

Now this code is used for requests that aren't authorized in current
connection. After receiving the 421 response a client will be able
to open a new connection, provide the required certificate and retry
the request.

Unfortunately, not all clients currently are able to handle it well.
Notably Chrome just shows an error, while at least the latest version
of Firefox retries the request over a new connection.

[hostmaster.myevo.net@…]

I am sure you're right, but I think the problem is a bit different from what you wrote.
I recap:
ssl_verify_client off, all subdomains can be browsed
ssl_verify_client on, all subdomains can be browsed
ssl_verify_client optional and client with certificate, all subdomains can be browsed
ssl_verify_client optional and client without certificate, error 400 (not 421) with the second subdomain (page appears without problems when I browse to the first subdomain).

This happens with latest versions of all browsers. Are you sure that this is on client's side?
Thanks again for your help.

[Valentin V. Bartenev]

ssl_verify_client off, all subdomains can be browsed

In this case client authorization isn't required and browser is allowed to request any domain in connection.

ssl_verify_client on, all subdomains can be browsed
ssl_verify_client optional and client with certificate, all subdomains can be browsed

It seems the fact that the client certificate is used prevents browser from connection reuse. In these cases browser uses separate connections as it should be.

ssl_verify_client optional and client without certificate

But in this case browser tries to reuse connection and gets 400. If you upgrade to 1.11.0, then the browser will get 421. This fixes Firefox since it handles 421 well.

Unfortunately, Chrome has a ticket about 421: ​https://bugs.chromium.org/p/chromium/issues/detail?id=546991

Browsers should either don't try to reuse connection, or handle the 421 response and resend request over a separate connection.

[Valentin Bartenev <vbart@…>]

In 6749:f88a145b093e/nginx:

HTTP/2: the "421 Misdirected Request" response (closes #848).

Since 4fbef397c753 nginx rejects with the 400 error any attempts of
requesting different host over the same connection, if the relevant
virtual server requires verification of a client certificate.

While requesting hosts other than negotiated isn't something legal
in HTTP/1.x, the HTTP/2 specification explicitly permits such requests
for connection reuse and has introduced a special response code 421.

According to RFC 7540 Section 9.1.2 this code can be sent by a server
that is not configured to produce responses for the combination of
scheme and authority that are included in the request URI. And the
client may retry the request over a different connection.

Now this code is used for requests that aren't authorized in current
connection. After receiving the 421 response a client will be able
to open a new connection, provide the required certificate and retry
the request.

Unfortunately, not all clients currently are able to handle it well.
Notably Chrome just shows an error, while at least the latest version
of Firefox retries the request over a new connection.