Hi, > On 27 Jun 2024, at 10:17 AM, Riccardo Brunetti Host > <riccardo.brune...@host.it> wrote: > > > >> On 26 Jun 2024, at 17:56, Roman Arutyunyan <a...@nginx.com >> <mailto:a...@nginx.com>> wrote: >> >> Hi, >> >>> On 26 Jun 2024, at 7:21 PM, Riccardo Brunetti Host >>> <riccardo.brune...@host.it <mailto:riccardo.brune...@host.it>> wrote: >>> >>> Hello, thanks for the answer. >>> >>>> On 26 Jun 2024, at 16:45, Roman Arutyunyan <a...@nginx.com >>>> <mailto:a...@nginx.com>> wrote: >>>> >>>> Hi, >>>> >>>>> On 26 Jun 2024, at 6:15 PM, Riccardo Brunetti Host >>>>> <riccardo.brune...@host.it <mailto:riccardo.brune...@host.it>> wrote: >>>>> >>>>> Hello. >>>>> >>>>> I have a Nginx server which acts as a reverse proxy for a given number of >>>>> different domains and I’m trying to enable http3 for a subset of them. >>>>> >>>>> I placed the directives: >>>>> >>>>>> http3 on; >>>>>> listen xx.xx.xx.xx:443 default_server quic reuseport; >>>>>> quic_retry on; >>>>> >>>>> in the default.conf file and then, only for those domains which I want >>>>> http3 enabled I also add in the corresponding virtual host: >>>>> >>>>>> http3 on; >>>>>> listen xx.xx.xx.xx:443 quic; >>>>>> quic_retry on; >>>>> >>>>> In the server section and >>>>> >>>>>> add_header Alt-Svc 'h3=":8443"; ma=86400'; >>>>> >>>>> Inside the location. >>>>> >>>>> Now, what happens is that if I try to open the sites *with* http3 >>>>> enabled, everything works as expected. If I try to open a site *without* >>>>> http3 enabled, sometimes I have an SSL error because the server returns >>>>> the “default virtual host” certificate. >>>>> It seems related to the type of browser. >>>>> >>>>> Is it an expected behaviour or I am doing something wrong with the server >>>>> configuration? >>>> >>>> If you use http/3 to access a virtual server that does not support http/3, >>>> the default http/3 server will be used. >>>> >>>> Make sure the above add_header does not affect the servers which do not >>>> support http/3. >>> >>> I add the header above only on the virtual hosts which I want to support >>> http/3, thus it should not interfere with the other non http/3 domains. >>> Nevertheless, if I try with curl: >>> >>> 1) Site http/3 enabled: >>> >>>> # curl --http3 -I -v https://<fqdn> >>>> * Host <fqdn>t:443 was resolved. >>>> * IPv6: (none) >>>> * IPv4: <ip> >>>> * WARNING: no socket in pollset, transfer may stall! >>>> * Trying <ip>:443... >>>> * Server certificate: >>>> * subject: CN=<fqdn> >>>> * start date: May 14 07:39:37 2024 GMT >>>> * expire date: Aug 12 07:39:36 2024 GMT >>>> * subjectAltName: host “<fqdn>" matched cert's “<fqdn>" >>>> * issuer: C=US; O=Let's Encrypt; CN=R3 >>>> * SSL certificate verify ok. >>>> * Connected to <fqdn> (<ip>) port 443 >>>> * using HTTP/3 >>>> * [HTTP/3] [0] OPENED stream for https://<fqdn>/ >>> … >>> … >>> >>> So it gets the correct certificate and it goes on using http/3 >>> >>> 2) Site non http/3 enabled: >>> >>>> # curl --http3 -I -v https://<fqdn> >>> >>>> * Host <fqdn>:443 was resolved. >>>> * IPv6: (none) >>>> * IPv4: <ip> >>>> * WARNING: no socket in pollset, transfer may stall! >>>> * Trying <ip>:443... >>>> * SSL certificate problem: unable to get local issuer certificate >>>> * connect to <ip> port 443 failed: SSL peer certificate or SSH remote key >>>> was not OK >>>> * Failed to connect to<fqdn> port 443 after 33 ms: SSL peer certificate or >>>> SSH remote key was not OK >>>> * Trying <ip>:443... >>>> * Connected to<fqdn> (<ip>) port 443 >>>> * ALPN: curl offers h2,http/1.1 >>>> * TLSv1.2 (OUT), TLS handshake, Client hello (1): >>>> * TLSv1.2 (IN), TLS handshake, Server hello (2): >>>> * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): >>>> * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): >>>> * TLSv1.3 (IN), TLS handshake, Certificate (11): >>>> * TLSv1.3 (IN), TLS handshake, CERT verify (15): >>>> * TLSv1.3 (IN), TLS handshake, Finished (20): >>>> * TLSv1.3 (OUT), TLS handshake, Finished (20): >>>> * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / [blank] / UNDEF >>>> * ALPN: server accepted h2 >>>> * Server certificate: >>>> * subject: CN=<fqdn> >>>> * start date: Apr 16 08:36:25 2024 GMT >>>> * expire date: Jul 15 08:36:24 2024 GMT >>>> * subjectAltName: host "<fqdn>" matched cert's "<fqdn>" >>>> * issuer: C=US; O=Let's Encrypt; CN=R3 >>>> * SSL certificate verify ok. >>>> * using HTTP/2 >>>> * [HTTP/2] [1] OPENED stream for https://<fqdn>/ >>> >>> >>> So it tries with http/3, gets a wrong certificate (the server default one), >>> then it switches to http/2 and goes on. >>> The first attempt with http/3 probably gives problems with some browsers? >>> If this is the case, is there a way to avoid this or should I simply >>> configure http/3 on all domains? >> >> Why would you (or client) connect to an http/3 port for a server which does >> not support http/3? >> What would be your expectation in this case? The same will happen for http/1 >> and http/2 as well. >> You can connect to an http/1 ssl port, request a missing server and receive >> a default server certificate. >> It's just there is no fallback for http/1 and client will just give up. >> >> The add_header suggests that http/3 is supported for a certain server. >> It should not be sent for servers which do not support http/3, and clients >> should not use http/3 for them. > > I agree with you, mine was an example just to show with curl what seems to > happen with some browsers. > It seems to me that they try http/3 even if the server doesn’t advertise the > header and then stop because of the error on the certificate. > I don’t know if this is something known. > Anyway, I think I will bypass this by enabling http/3 on all sites.
One more thing you can do is to reject handshake for default server: https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_reject_handshake > > Thanks a lot for you help > > Riccardo > >> >>>> If it does, this will mislead clients by offering them to switch to >>>> unsupported http/3. >>>> >>>>> Nginx version: nginx/1.26.1 on ubuntu 22.04 >>>>> >>>>> Thanks. >>>>> Riccardo >>>>> _______________________________________________ >>>>> nginx mailing list >>>>> nginx@nginx.org <mailto:nginx@nginx.org> >>>>> https://mailman.nginx.org/mailman/listinfo/nginx >>>> >>>> ---- >>>> Roman Arutyunyan >>>> a...@nginx.com <mailto:a...@nginx.com> >>>> >>> >>> Riccardo >>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> nginx mailing list >>>> nginx@nginx.org <mailto:nginx@nginx.org> >>>> https://mailman.nginx.org/mailman/listinfo/nginx >>> >>> _______________________________________________ >>> nginx mailing list >>> nginx@nginx.org <mailto:nginx@nginx.org> >>> https://mailman.nginx.org/mailman/listinfo/nginx >> >> ---- >> Roman Arutyunyan >> a...@nginx.com <mailto:a...@nginx.com> >> >> >> >> >> _______________________________________________ >> nginx mailing list >> nginx@nginx.org <mailto:nginx@nginx.org> >> https://mailman.nginx.org/mailman/listinfo/nginx > > _______________________________________________ > nginx mailing list > nginx@nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx ---- Roman Arutyunyan a...@nginx.com
_______________________________________________ nginx mailing list nginx@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx
