Hello, thanks for the answer. > On 26 Jun 2024, at 16:45, Roman Arutyunyan <a...@nginx.com> wrote: > > Hi, > >> On 26 Jun 2024, at 6:15 PM, Riccardo Brunetti Host >> <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? > 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 >> https://mailman.nginx.org/mailman/listinfo/nginx > > ---- > Roman Arutyunyan > a...@nginx.com > Riccardo > > > > _______________________________________________ > nginx mailing list > nginx@nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx
_______________________________________________ nginx mailing list nginx@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx
