Enable http3 for a subset of domains

[Riccardo Brunetti Host]

Hello, thanks for the answer.

> On 26 Jun 2024, at 16:45, Roman Arutyunyan <arut at nginx.com> wrote:
> 
> Hi,
> 
>> On 26 Jun 2024, at 6:15 PM, Riccardo Brunetti Host <riccardo.brunetti at 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 at nginx.org
>> https://mailman.nginx.org/mailman/listinfo/nginx
> 
> ----
> Roman Arutyunyan
> arut at nginx.com
> 

Riccardo

> 
> 
> 
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20240626/36c233da/attachment-0001.htm>