QUIC Connection Closure with TLS Internal Error

[LZJ0913]

I use the tquic (Tencent Quic) Client to communicate with OpenLiteSpeed via HTTP3, OpenLiteSpeed decides to close the connection during the QUIC handshake.

[LZJ0913]

I use the tquic (Tencent Quic) Client to communicate with OpenLiteSpeed via HTTP3, OpenLiteSpeed decides to close the connection during the QUIC handshake.

The specific error message of CONNECTION_ClOSE frame is:

I have tried the following two methods to generate and configure the SSL Private Key & Certificate: The first method is:

openssl genpkey -algorithm RSA -out private_key.pem -pkeyopt rsa_keygen_bits:2048
openssl genpkey -algorithm RSA -out ca_private_key.pem -pkeyopt rsa_keygen_bits:2048
openssl req -new -key private_key.pem -out csr.pem
openssl x509 -signkey private_key.pem -in csr.pem -req -days 365 -out certificate.pem
openssl req -x509 -new -nodes -key ca_private_key.pem -days 1024 -out ca_certificate.pem

In this way, my SSL configuration for the Listener and Virtual Host is:

Private Key File = /usr/local/lsws/mylocation/private_key.pem
Certificate File = /usr/local/lsws/mylocation/certificate.pem
CA Certificate File = /usr/local/lsws/mylocation/ca_certificate.pem

The second method is: openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -sha256 -days 365 In this way, my SSL configuration for the Listener and Virtual Host is:

Private Key File = /usr/local/lsws/mylocation/key.pem
Certificate File = /usr/local/lsws/mylocation/cert.pem
Chained Certificate = Yes

The error.log(debug mode) is:

2024-06-03 02:25:40.066707 [NOTICE] [25637] sendKillCmdToWatchdog: 'extappkill:26690:-3:0'.
2024-06-03 02:25:40.822138 [NOTICE] [25635] Cmd from child: [extappkill:26690:-3:0]
2024-06-03 02:25:40.822245 [INFO] [25635] Failed to get process [26690] start time, not running, skip killing.

I would like to know what the cause of the error is. Could you please provide some ideas or guidance on how to resolve this issue? Any help would be greatly appreciated.

[litespeedtech]

Make sure the regular TCP HTTPS works properly with the cert/key, using TLS 1.3. then try HTTP/3, if not work, enable OLS debug logging check the log. it is likely a TLS 1.3 handshake problem.

[LZJ0913]

Thank you for your suggestion. Then I used curl as the client to test both TCP HTTPS and HTTP3 (both using the same self-signed certificate).

It seems that the issue did not occur with TCP HTTPS communication. From the packet capture, it can be seen that the server sent an HTTP 200 response code, and the connection was actively closed by the client (curl: (60) SSL certificate problem: self signed certificate).

curl -Iv https://localhost:8088
*   Trying 127.0.0.1:8088...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 8088 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (OUT), TLS alert, unknown CA (560):
* SSL certificate problem: self signed certificate
* Closing connection 0
curl: (60) SSL certificate problem: self signed certificate

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

However, in HTTP3 communication, the same issue occurred as before. From the packet capture, it can be seen that the server was still the one sending the Connection Close Frame, and the curl error message also changed (curl: (8) Failed to connect to 10.144.74.180 port 443 after 86 ms: Weird server reply).

curl --http3 -Iv https://10.144.74.180:443 
* Uses proxy env variable no_proxy == 'localhost,127.0.0.1,192.168.0.0/16,10.0.0.0/8,172.16.0.0/12,::1'
*   Trying 10.144.74.180:443...
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* connect to 10.144.74.180 port 443 failed: Weird server reply
*   Trying 10.144.74.180:443...
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* connect to 10.144.74.180 port 443 failed: Weird server reply
* Failed to connect to 10.144.74.180 port 443 after 86 ms: Weird server reply
*   Trying 10.144.74.180:443...
* Connected to 10.144.74.180 (10.144.74.180) port 443
* ALPN: curl offers http/1.1
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* 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 (OUT), TLS alert, unknown CA (560):
* SSL certificate problem: self signed certificate
* Closing connection
curl: (8) Failed to connect to 10.144.74.180 port 443 after 86 ms: Weird server reply

I have set the log level to debug. Below is the new log information generated during the http3 testing process.

2024-06-04 03:34:03.064955 [NOTICE] [60386] sendKillCmdToWatchdog: 'extappkill:60535:-3:0'.
2024-06-04 03:34:03.811000 [NOTICE] [60384] Cmd from child: [extappkill:60535:-3:0]
2024-06-04 03:34:03.811073 [INFO] [60384] Failed to get process [60535] start time, not running, skip killing.

By the way, when I used lsquic previously , I also used a self-signed certificate, and both sides were able to communicate normally. Below are the test commands.

sudo ./http_client -H www.example.com -s 127.0.0.1:4433 -p /123000K
sudo ./http_server -c www.example.com,cert.pem,key.pem -s 0.0.0.0:4433

The above are my records. Is there any solution?

[litespeedtech]

Please make sure you have the certificate configured at both listener level and vhost level, otherwise, SNI wont work. it is required for HTTP3.