Resolved http/3 supported by plesk?

[AYamshanov]

If someone is faced with an error like

plesk bin http3_pref --enable -panel -nginx
Execution failed.
Command: pleskrc
Arguments: Array
(
[0] => sw-cp-server
[1] => try-reload
)

Details: Job for sw-cp-server.service failed.
See "systemctl status sw-cp-server.service" and "journalctl -xe" for details.


exit status 1

We have prepared a KB article with a resolution on how to make the control panel available again,

• https://support.plesk.com/hc/en-us/...rus-cannot-be-enabled-in-Mail-Server-Settings.

 

[Leonardo N]

Hello,

after running: plesk bin http3_pref --enable -panel -nginx
I got this log:

[2024-05-16 05:27:02.385] 56149:6645c3565ddc2 ERR [util_exec] proc_close() failed ['/opt/psa/admin/bin/sslmng' '--protocols=+TLSv1.3'] with exit code [1]
sslmng failed: Job for sw-cp-server.service failed.
See "systemctl status sw-cp-server.service" and "journalctl -xe" for details.
ERROR: Command '['/opt/psa/admin/sbin/pleskrc', 'sw-cp-server', 'reload']' returned non-zero exit status 1.

Please, Do i need to change some nginx config before running it?

Thank's

 

[AYamshanov]

[2024-05-16 05:27:02.385] 56149:6645c3565ddc2 ERR [util_exec] proc_close() failed ['/opt/psa/admin/bin/sslmng' '--protocols=+TLSv1.3'] with exit code [1]

@Leonardo N , could you please post the output of the `plesk version` command and check the output of the command `plesk sbin sslmng --show-config` (c) https://support.plesk.com/hc/en-us/...ons-or-SSL-ciphers-via-CLI-in-Plesk-for-Linux. It seems the issue is because the attempt to enable TLSv1.3 is failed.

Alternatively you can open a ticket with Plesk support so the support team can investigate the issue on your server, it could help to solve the issues faster.

 

[Leonardo N]

Hi @AYamshanov , thanks for your help.

Abou plesk version i got this:
Product version: Plesk Obsidian 18.0.61.1
OS version: Ubuntu 20.04 x86_64
Build date: 2024/05/14 15:00
Revision: eb6e8f6cb63fcb88cd5e5bf531b40823c2e63c98

And about plesk sbin sslmng --show--config , this json:

{
"full": {
"all": {
"dhparams_size": 2048,
"ciphers": "EECDH+AESGCM+AES128:EECDH+AESGCM+AES256:EECDH+CHACHA20:EDH+AESGCM+AES128:EDH+AESGCM+AES256:EDH+CHACHA20:EECDH+SHA256+AES128:EECDH+SHA384+AES256:EDH+SHA256+AES128:EDH+SHA256+AES256:EECDH+SHA1+AES128:EECDH+SHA1+AES256:EDH+SHA1+AES128:EDH+SHA1+AES256:EECDH+HIGH:EDH+HIGH:AESGCM+AES128:AESGCM+AES256:CHACHA20:SHA256+AES128:SHA256+AES256:SHA1+AES128:SHA1+AES256:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK:!KRB5:!aECDH:!kDH",
"strong_dh": true,
"protocols": [
"TLSv1.2",
"TLSv1.3"
],
"cipher_server_order": true
},
"dovecot": {
"ciphers": "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256",
"protocols": [
"TLSv1.2"
]
},
"mail-imap-pop3": {},
"postfix": {
"ciphers": "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256",
"protocols": [
"TLSv1.2"
]
},
"autoinstaller": {
"ciphers": "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256",
"protocols": [
"TLSv1.2"
]
},
"nginx": {
"ciphers": "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256",
"protocols": [
"TLSv1.2"
]
},
"sw-cp-server": {
"ciphers": "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256",
"protocols": [
"TLSv1.2"
]
},
"mail-smtp": {},
"apache": {
"ciphers": "TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256",
"protocols": [
"TLSv1.3"
]
},
"mail": {
"cert": "/opt/psa/var/certificates/scfgbVRR8",
"certificate": true
},
"proftpd": {
"ciphers": "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256",
"protocols": [
"TLSv1.2"
]
}
},
"effective": {
"dovecot": {
"dhparams_size": 2048,
"ciphers": "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256",
"strong_dh": true,
"protocols": [
"TLSv1.2"
],
"cipher_server_order": true,
"cert": "/opt/psa/var/certificates/scfgbVRR8",
"certificate": true
},
"postfix": {
"dhparams_size": 2048,
"ciphers": "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256",
"strong_dh": true,
"protocols": [
"TLSv1.2"
],
"cipher_server_order": true,
"cert": "/opt/psa/var/certificates/scfgbVRR8",
"certificate": true
},
"autoinstaller": {
"ciphers": "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256",
"protocols": [
"TLSv1.2"
],
"cipher_server_order": true
},
"nginx": {
"dhparams_size": 2048,
"ciphers": "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256",
"strong_dh": true,
"protocols": [
"TLSv1.2"
],
"cipher_server_order": true
},
"sw-cp-server": {
"dhparams_size": 2048,
"ciphers": "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256",
"strong_dh": true,
"protocols": [
"TLSv1.2"
],
"cipher_server_order": true
},
"apache": {
"ciphers": "TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256",
"protocols": [
"TLSv1.3"
],
"cipher_server_order": true
},
"proftpd": {
"dhparams_size": 2048,
"ciphers": "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256",
"strong_dh": true,
"protocols": [
"TLSv1.2"
],
"cipher_server_order": true
},
"qmail": {
"ciphers": "EECDH+AESGCM+AES128:EECDH+AESGCM+AES256:EECDH+CHACHA20:EDH+AESGCM+AES128:EDH+AESGCM+AES256:EDH+CHACHA20:EECDH+SHA256+AES128:EECDH+SHA384+AES256:EDH+SHA256+AES128:EDH+SHA256+AES256:EECDH+SHA1+AES128:EECDH+SHA1+AES256:EDH+SHA1+AES128:EDH+SHA1+AES256:EECDH+HIGH:EDH+HIGH:AESGCM+AES128:AESGCM+AES256:CHACHA20:SHA256+AES128:SHA256+AES256:SHA1+AES128:SHA1+AES256:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK:!KRB5:!aECDH:!kDH",
"cert": "/opt/psa/var/certificates/scfgbVRR8",
"certificate": true
},
"courier": {
"dhparams_size": 2048,
"ciphers": "EECDH+AESGCM+AES128:EECDH+AESGCM+AES256:EECDH+CHACHA20:EDH+AESGCM+AES128:EDH+AESGCM+AES256:EDH+CHACHA20:EECDH+SHA256+AES128:EECDH+SHA384+AES256:EDH+SHA256+AES128:EDH+SHA256+AES256:EECDH+SHA1+AES128:EECDH+SHA1+AES256:EDH+SHA1+AES128:EDH+SHA1+AES256:EECDH+HIGH:EDH+HIGH:AESGCM+AES128:AESGCM+AES256:CHACHA20:SHA256+AES128:SHA256+AES256:SHA1+AES128:SHA1+AES256:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK:!KRB5:!aECDH:!kDH",
"strong_dh": true,
"protocols": [
"TLSv1.2",
"TLSv1.3"
],
"cert": "/opt/psa/var/certificates/scfgbVRR8",
"certificate": true
}
}
}

I'm going to open a ticket as you suggested. Thanks

 

[Leonardo N]

@Leonardo N , could you please post the output of the `plesk version` command and check the output of the command `plesk sbin sslmng --show-config` (c) https://support.plesk.com/hc/en-us/...ons-or-SSL-ciphers-via-CLI-in-Plesk-for-Linux. It seems the issue is because the attempt to enable TLSv1.3 is failed.

Alternatively you can open a ticket with Plesk support so the support team can investigate the issue on your server, it could help to solve the issues faster.

The support team solved my problem, the issue was:

Missing TLSv1.3 ; I installed it and the command works! Thanks for your help!!

 

[AYamshanov]

Missing TLSv1.3 ; I installed it and the command works! Thanks for your help!

Could you please share details on how you installed the TLSv1.3?

 

[Leonardo N]

Could you please share details on how you installed the TLSv1.3?

Sure, in sequence:

ran this:

plesk bin http3_pref --disable -panel

and

plesk bin http3_pref --enable -nginx

to enable HTTP/3 only for websites, not Plesk panel

plesk bin server_pref -u -ssl-protocols 'TLSv1.2 TLSv1.3'

to install TLS

nginx -t

to check config and then

plesk bin http3_pref --enable -panel -nginx

to add HTTP3 (it took about 30 seconds)

 

[AYamshanov]

Thank you for sharing this information!

 

[Patrick Dankers]

Following this as while I can run the command just fine, for each and every website im still seeing it being served by HTTP2.
I also followed the above sequence, but to no avail. Having HTTP3 not show up on multiple servers. in which locally and at host the needed ports have been made open for UDP.

So not sure what I am missing.

For quick reference;

[root@srvtrans-p24 pdtemp]# plesk version

Product version: Plesk Obsidian 18.0.61.1
OS version: AlmaLinux 8.9 x86_64
Build date: 2024/05/14 15:00
Revision: eb6e8f6cb63fcb88cd5e5bf531b40823c2e63c98

[root@srvtrans-p24 pdtemp]# plesk sbin sslmng --show-config
{
"full": {
"all": {
"protocols": [
"TLSv1.2",
"TLSv1.3"
],
"ciphers": "EECDH+AESGCM+AES128:EECDH+AESGCM+AES256:EECDH+CHACHA20:EECDH+SHA256+AES128:EECDH+SHA384+AES256:EECDH+SHA1+AES128:EECDH+SHA1+AES256:EECDH+HIGH:AESGCM+AES128:AESGCM+AES256:CHACHA20:SHA256+AES128:SHA256+AES256:SHA1+AES128:SHA1+AES256:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK:!KRB5:!aECDH:!kDH:!EDH",
"cipher_server_order": true,
"strong_dh": true,
"dhparams_size": 2048
},
"apache": {
"ciphers": "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305HE-RSA-AES128-GCM-SHA256HE-RSA-AES256-GCM-SHA384",
"cipher_server_order": false
},
"nginx": {
"ciphers": "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305HE-RSA-AES128-GCM-SHA256HE-RSA-AES256-GCM-SHA384",
"cipher_server_order": false
},
"mail-imap-pop3": {},
"mail-smtp": {},
"mail": {
"certificate": true,
"cert": "/usr/local/psa/var/certificates/certCEJwrmT"
},
"autoinstaller": {
"ciphers": "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305HE-RSA-AES128-GCM-SHA256HE-RSA-AES256-GCM-SHA384",
"cipher_server_order": false
},
"proftpd": {
"ciphers": "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305HE-RSA-AES128-GCM-SHA256HE-RSA-AES256-GCM-SHA384",
"cipher_server_order": false
},
"sw-cp-server": {
"ciphers": "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305HE-RSA-AES128-GCM-SHA256HE-RSA-AES256-GCM-SHA384",
"cipher_server_order": false
}
},
"effective": {
"apache": {
"protocols": [
"TLSv1.2",
"TLSv1.3"
],
"ciphers": "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305HE-RSA-AES128-GCM-SHA256HE-RSA-AES256-GCM-SHA384",
"cipher_server_order": false
},
"nginx": {
"protocols": [
"TLSv1.2",
"TLSv1.3"
],
"ciphers": "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305HE-RSA-AES128-GCM-SHA256HE-RSA-AES256-GCM-SHA384",
"cipher_server_order": false,
"strong_dh": true,
"dhparams_size": 2048
},
"autoinstaller": {
"protocols": [
"TLSv1.2",
"TLSv1.3"
],
"ciphers": "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305HE-RSA-AES128-GCM-SHA256HE-RSA-AES256-GCM-SHA384",
"cipher_server_order": false
},
"proftpd": {
"protocols": [
"TLSv1.2",
"TLSv1.3"
],
"ciphers": "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305HE-RSA-AES128-GCM-SHA256HE-RSA-AES256-GCM-SHA384",
"cipher_server_order": false,
"strong_dh": true,
"dhparams_size": 2048
},
"sw-cp-server": {
"protocols": [
"TLSv1.2",
"TLSv1.3"
],
"ciphers": "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305HE-RSA-AES128-GCM-SHA256HE-RSA-AES256-GCM-SHA384",
"cipher_server_order": false,
"strong_dh": true,
"dhparams_size": 2048
},
"postfix": {
"protocols": [
"TLSv1.2",
"TLSv1.3"
],
"ciphers": "EECDH+AESGCM+AES128:EECDH+AESGCM+AES256:EECDH+CHACHA20:EECDH+SHA256+AES128:EECDH+SHA384+AES256:EECDH+SHA1+AES128:EECDH+SHA1+AES256:EECDH+HIGH:AESGCM+AES128:AESGCM+AES256:CHACHA20:SHA256+AES128:SHA256+AES256:SHA1+AES128:SHA1+AES256:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK:!KRB5:!aECDH:!kDH:!EDH",
"cipher_server_order": true,
"strong_dh": true,
"dhparams_size": 2048,
"certificate": true,
"cert": "/usr/local/psa/var/certificates/certCEJwrmT"
},
"qmail": {
"ciphers": "EECDH+AESGCM+AES128:EECDH+AESGCM+AES256:EECDH+CHACHA20:EECDH+SHA256+AES128:EECDH+SHA384+AES256:EECDH+SHA1+AES128:EECDH+SHA1+AES256:EECDH+HIGH:AESGCM+AES128:AESGCM+AES256:CHACHA20:SHA256+AES128:SHA256+AES256:SHA1+AES128:SHA1+AES256:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK:!KRB5:!aECDH:!kDH:!EDH",
"certificate": true,
"cert": "/usr/local/psa/var/certificates/certCEJwrmT"
},
"dovecot": {
"protocols": [
"TLSv1.2",
"TLSv1.3"
],
"ciphers": "EECDH+AESGCM+AES128:EECDH+AESGCM+AES256:EECDH+CHACHA20:EECDH+SHA256+AES128:EECDH+SHA384+AES256:EECDH+SHA1+AES128:EECDH+SHA1+AES256:EECDH+HIGH:AESGCM+AES128:AESGCM+AES256:CHACHA20:SHA256+AES128:SHA256+AES256:SHA1+AES128:SHA1+AES256:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK:!KRB5:!aECDH:!kDH:!EDH",
"cipher_server_order": true,
"strong_dh": true,
"dhparams_size": 2048,
"certificate": true,
"cert": "/usr/local/psa/var/certificates/certCEJwrmT"
},
"courier": {
"protocols": [
"TLSv1.2",
"TLSv1.3"
],
"ciphers": "EECDH+AESGCM+AES128:EECDH+AESGCM+AES256:EECDH+CHACHA20:EECDH+SHA256+AES128:EECDH+SHA384+AES256:EECDH+SHA1+AES128:EECDH+SHA1+AES256:EECDH+HIGH:AESGCM+AES128:AESGCM+AES256:CHACHA20:SHA256+AES128:SHA256+AES256:SHA1+AES128:SHA1+AES256:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK:!KRB5:!aECDH:!kDH:!EDH",
"strong_dh": true,
"dhparams_size": 2048,
"certificate": true,
"cert": "/usr/local/psa/var/certificates/certCEJwrmT"
}
}
}

[root@srvtrans-p24 pdtemp]# curl -I Foodtruck huren - De lekkerste BBQ en Snacks op Locatie - Food on Tour
HTTP/2 200
server: nginx
date: Thu, 16 May 2024 14:46:08 GMT
content-type: text/html; charset=UTF-8
x-powered-by: PHP/8.3.7
strict-transport-security: max-age=63072000; includeSubDomains;preload
x-xss-protection: 0
x-content-type-options: nosniff
referrer-policy: strict-origin-when-cross-origin
permissions-policy: accelerometer=(*), autoplay=(*), camera=(*), encrypted-media=(*), fullscreen=(*), geolocation=(*), microphone=(*), midi=(*), payment=(*), display-capture=(*)
x-frame-options: SAMEORIGIN
cross-origin-opener-policy: same-origin-allow-popups
cross-origin-resource-policy: same-site
cross-origin-embedder-policy: same-origin
content-security-policy: upgrade-insecure-requests;
x-flying-press-cache: MISS
x-flying-press-source: PHP
cache-control: max-age=0
expires: Thu, 16 May 2024 14:46:07 GMT
vary: Accept-Encoding
alt-svc: h3=":443"; ma=86400
x-cache-status: MISS
strict-transport-security: max-age=15768000; includeSubDomains

[root@srvtrans-p24 pdtemp]# curl -I De lekkerste Friet en Snacks op Locatie - Frietje on Tour
HTTP/2 200
server: nginx
date: Thu, 16 May 2024 14:46:30 GMT
content-type: text/html; charset=UTF-8
x-powered-by: PHP/8.3.7
strict-transport-security: max-age=63072000; includeSubDomains;preload
x-xss-protection: 0
x-content-type-options: nosniff
referrer-policy: strict-origin-when-cross-origin
permissions-policy: accelerometer=(*), autoplay=(*), camera=(*), encrypted-media=(*), fullscreen=(*), geolocation=(*), microphone=(*), midi=(*), payment=(*), display-capture=(*)
x-frame-options: SAMEORIGIN
cross-origin-opener-policy: same-origin-allow-popups
cross-origin-resource-policy: same-origin
cross-origin-embedder-policy: same-origin
content-security-policy: upgrade-insecure-requests;
x-flying-press-cache: MISS
x-flying-press-source: PHP
cache-control: max-age=0
expires: Thu, 16 May 2024 14:46:30 GMT
vary: Accept-Encoding
alt-svc: h3=":443"; ma=86400
x-cache-status: MISS
strict-transport-security: max-age=15768000; includeSubDomains

 

[AYamshanov]

[root@srvtrans-p24 pdtemp]# curl -I Foodtruck huren - De lekkerste BBQ en Snacks op Locatie - Food on Tour

I have checked it with `curl` from my laptop, and it seems the server does not respond to the requests over UDP (HTTP/3, QUIC),

% /opt/homebrew/opt/curl/bin/curl -vDI https://foodontour.nl/ --http3-only
* Host foodontour.nl:443 was resolved.
* IPv6: (none)
* IPv4: 93.119.2.12
*   Trying 93.119.2.12:443...
* connection closed by idle timeout
* connect to 93.119.2.12 port 443 failed: Failed sending data to the peer
* Failed to connect to foodontour.nl port 443 after 120013 ms: Failed sending data to the peer
* Closing connection
curl: (55) connection closed by idle timeout

% sudo tcpdump -ni en0 -c 100 udp and port 443
Password:
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on en0, link-type EN10MB (Ethernet), snapshot length 524288 bytes
18:12:39.871587 IP 10.0.0.1.58152 > 93.119.2.12.443: quic, initial, dcid 2745fe4cc8c39519cf646604f9d10520, scid bc17fcd61fc8fb71c11716b14435d54e105d4f98, length 272
18:12:40.875016 IP 10.0.0.1.58152 > 93.119.2.12.443: quic, initial, dcid 2745fe4cc8c39519cf646604f9d10520, scid bc17fcd61fc8fb71c11716b14435d54e105d4f98, length 272
18:12:42.878461 IP 10.0.0.1.58152 > 93.119.2.12.443: quic, initial, dcid 2745fe4cc8c39519cf646604f9d10520, scid bc17fcd61fc8fb71c11716b14435d54e105d4f98, length 272
18:12:42.878518 IP 10.0.0.1.58152 > 93.119.2.12.443: quic, initial, dcid 2745fe4cc8c39519cf646604f9d10520, scid bc17fcd61fc8fb71c11716b14435d54e105d4f98, length 21
18:12:46.881339 IP 10.0.0.1.58152 > 93.119.2.12.443: quic, initial, dcid 2745fe4cc8c39519cf646604f9d10520, scid bc17fcd61fc8fb71c11716b14435d54e105d4f98, length 272
18:12:46.881392 IP 10.0.0.1.58152 > 93.119.2.12.443: quic, initial, dcid 2745fe4cc8c39519cf646604f9d10520, scid bc17fcd61fc8fb71c11716b14435d54e105d4f98, length 21
^C
6 packets captured
179 packets received by filter
0 packets dropped by kernel

As you can see, there are only requests to 93.119.2.12 and no answers from 93.119.2.12. I think you need to check firewall rules (on a server, and external firewall on a cloud provider level if applicable).

 

[Patrick Dankers]

Ok I do see what you mean, but I have openend up the ports;
Using the Plesk firewall extension, manually using iptables;
[root@srvtrans-p24 pdtemp]# iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N f2b-ssh
-A INPUT -p tcp -m tcp --dport 22 -j f2b-ssh
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -p udp -m udp --dport 443 -j ACCEPT
-A f2b-ssh -j RETURN

I openend the port for UDP/TCP on the hostings firewall panel. (TransIP)
I also tried disabling both the firewall on the server as well as the hostings firewall panel.
But nothing seems to get me passed;

patrickd@Patricks-MBP ~ % /opt/homebrew/opt/curl/bin/curl -vDI https://foodontour.nl/ --http3-only
* Host foodontour.nl:443 was resolved.
* IPv6: (none)
* IPv4: 93.119.2.12
*   Trying 93.119.2.12:443...
* QUIC: connection to 93.119.2.12 port 443 refused
* connect to 93.119.2.12 port 443 failed: Couldn't connect to server
* Failed to connect to foodontour.nl port 443 after 18 ms: Couldn't connect to server
* Closing connection
curl: (7) QUIC: connection to 93.119.2.12 port 443 refused

Hence I also made a ticket at TransIP's end, to see if they can tell me anything more about the connection being refused.
If I get any further I will get back to you all.

 

[Patrick Dankers]

Not sure what is going on now;

patrickd@Patricks-MacBook-Pro output % /opt/homebrew/opt/curl/bin/curl -vDI https://foodontour.nl/ --http3-only
* Host foodontour.nl:443 was resolved.
* IPv6: (none)
* IPv4: 93.119.2.12
*   Trying 93.119.2.12:443...
* connection closed by idle timeout
* connect to 93.119.2.12 port 443 failed: Failed sending data to the peer
* Failed to connect to foodontour.nl port 443 after 120043 ms: Failed sending data to the peer
* Closing connection
curl: (55) connection closed by idle timeout

It seems not to get refused anymore, but never gets anything back?
Hence the failed sending data to the peer.
I veriffied once again;

[root@srvtrans-p24 pdtemp]# plesk bin http3_pref --enable -panel -nginx
HTTP/3 support was activated for Plesk. Make sure your firewall allows 8443/UDP [in/out].
HTTP/3 support was activated for nginx. Make sure your firewall allows 443/UDP [in/out].
You can use the Firewall extension to manage HTTP/3 ports in Plesk.

[root@srvtrans-p24 pdtemp]# ss -tulpn
Netid      State       Recv-Q      Send-Q                                   Local Address:Port            Peer Address:Port      Process
udp        UNCONN      0           0                                              0.0.0.0:8443                 0.0.0.0:*          users:(("sw-cp-serverd",pid=40780,fd=12),("sw-cp-serverd",pid=40779,fd=12))
udp        UNCONN      0           0                                            127.0.0.1:323                  0.0.0.0:*          users:(("chronyd",pid=791,fd=5))
udp        UNCONN      0           0                                          93.119.2.12:443                  0.0.0.0:*          users:(("nginx",pid=40855,fd=21),("nginx",pid=40854,fd=21),("nginx",pid=40853,fd=21))
udp        UNCONN      0           0                                                 [::]:8443                    [::]:*          users:(("sw-cp-serverd",pid=40780,fd=9),("sw-cp-serverd",pid=40779,fd=9))
udp        UNCONN      0           0                                                [::1]:323                     [::]:*          users:(("chronyd",pid=791,fd=6))
udp        UNCONN      0           0                [2a01:7c8:bb0a:2ba:5054:ff:fe79:6517]:443                     [::]:*          users:(("nginx",pid=40855,fd=18),("nginx",pid=40854,fd=18),("nginx",pid=40853,fd=18))
tcp        LISTEN      0           511                                          127.0.0.1:7080                 0.0.0.0:*          users:(("httpd",pid=39712,fd=3),("httpd",pid=39194,fd=3),("httpd",pid=39193,fd=3),("httpd",pid=39192,fd=3),("httpd",pid=39166,fd=3),("httpd",pid=8605,fd=3))
tcp        LISTEN      0           511                                          127.0.0.1:7081                 0.0.0.0:*          users:(("httpd",pid=39712,fd=4),("httpd",pid=39194,fd=4),("httpd",pid=39193,fd=4),("httpd",pid=39192,fd=4),("httpd",pid=39166,fd=4),("httpd",pid=8605,fd=4))
tcp        LISTEN      0           80                                           127.0.0.1:3306                 0.0.0.0:*          users:(("mariadbd",pid=24698,fd=16))
tcp        LISTEN      0           511                                        93.119.2.12:80                   0.0.0.0:*          users:(("nginx",pid=40854,fd=23),("nginx",pid=40853,fd=23))
tcp        LISTEN      0           511                                            0.0.0.0:8880                 0.0.0.0:*          users:(("sw-cp-serverd",pid=40780,fd=8),("sw-cp-serverd",pid=40779,fd=8))
tcp        LISTEN      0           128                                            0.0.0.0:22                   0.0.0.0:*          users:(("sshd",pid=2264,fd=3))
tcp        LISTEN      0           511                                        93.119.2.12:443                  0.0.0.0:*          users:(("nginx",pid=40854,fd=22),("nginx",pid=40853,fd=22))
tcp        LISTEN      0           511                                            0.0.0.0:8443                 0.0.0.0:*          users:(("sw-cp-serverd",pid=40780,fd=7),("sw-cp-serverd",pid=40779,fd=7))
tcp        LISTEN      0           511              [2a01:7c8:bb0a:2ba:5054:ff:fe79:6517]:80                      [::]:*          users:(("nginx",pid=40854,fd=20),("nginx",pid=40853,fd=20))
tcp        LISTEN      0           511                                               [::]:8880                    [::]:*          users:(("sw-cp-serverd",pid=40780,fd=11),("sw-cp-serverd",pid=40779,fd=11))
tcp        LISTEN      0           64                                                   *:21                         *:*          users:(("xinetd",pid=2305,fd=5))
tcp        LISTEN      0           128                                               [::]:22                      [::]:*          users:(("sshd",pid=2264,fd=4))
tcp        LISTEN      0           511              [2a01:7c8:bb0a:2ba:5054:ff:fe79:6517]:443                     [::]:*          users:(("nginx",pid=40854,fd=19),("nginx",pid=40853,fd=19))
tcp        LISTEN      0           511                                               [::]:8443                    [::]:*          users:(("sw-cp-serverd",pid=40780,fd=10),("sw-cp-serverd",pid=40779,fd=10))

Nginx is listening on 443 udp ... so yeah Im at a loss as to where to look into now, any help perhaps?

 

[Patrick Dankers]

Ok, UDP is connectionless so ok it makes some sense.
So the Alt SVC header is now there,

But why would the protocol still be H2 instead of H3 in dev console? Am I overlooking something?
I tried multiple browsers which serve other website with h3 just fine.

 

[learning_curve]

@Patrick Dankers
FWIW If we try to curl --http3 to the site you've already posted, then yes, it's HTTP/2 only
It appears to be the inability to established the QUIC connection for HTTP/3 aka a misconfig somewhere, but you'll need to verify this locally.

iMac:~ zqx$ curl -vDI Foodtruck huren - De lekkerste BBQ en Snacks op Locatie - Food on Tour --http3-only
* Host foodontour.nl:443 was resolved.
* IPv6: (none)
* IPv4: 93.119.2.12
* Trying 93.119.2.12:443...
* QUIC: connection to 93.119.2.12 port 443 refused
* connect to 93.119.2.12 port 443 failed: Couldn't connect to server
* Failed to connect to foodontour.nl port 443 after 327 ms: Couldn't connect to server
* Closing connection
curl: (7) QUIC: connection to 93.119.2.12 port 443 refused
iMac:~ zqx$

iMac:~ zqx$ curl --http3 Foodtruck huren - De lekkerste BBQ en Snacks op Locatie - Food on Tour -I
HTTP/2 200
server: nginx
date: Fri, 17 May 2024 15:46:04 GMT
content-type: text/html; charset=utf-8
content-length: 155605
vary: User-Agent,Accept-Encoding
~ ~ ~
iMac:~ zqx$

Once you've resolved the misconfig, it should be / will be fine after that.
Example of a domain that we host, but the data has been sanitized to avoid posting the domain name / its IPv4 & IPv6 addresses here on a forum

iMac:~ zqx$ curl -vDI https://*****.*** --http3-only
* Host *****.***:443 was resolved.
* IPv6: ***:***:***:***::*
* IPv4: **.**.**.***
* Trying [***:***:***:***::*]:443...
* Trying **.**.**.***:443...
* subjectAltName: host "*****.***" matched cert's "*****.***"
* Verified certificate just fine
* Connected to *****.*** (***:***:***:***::*) port 443
* using HTTP/3
~ ~ ~
iMac:~ zqx$

NB This post will convert your url to the FQDN in the data unfortunately.

 

[Patrick Dankers]

Thanks for sharing, yeah I am assuming something of a config issue.
The big question being as to where as I tried, Pure Nginx, Nginx as reverse proxy, dedicated fpm, normal nginx fpm.

I did some more attempts; with Plesk

[root@srvtrans-p24 jottentransip.nl]# sudo firewall-cmd --permanent --add-port=443/tcp
Warning: ALREADY_ENABLED: 443:tcp
success
[root@srvtrans-p24 jottentransip.nl]# sudo firewall-cmd --permanent --add-port=443/udp
Warning: ALREADY_ENABLED: 443:udp

What I am a bit confused about is this

[root@srvtrans-p24 jottentransip.nl]# firewall-cmd --list-all
plesk (active)
  target: default
  icmp-block-inversion: no
  interfaces: ens3
  sources:
  services:
  ports: 22/tcp 21/tcp 25/tcp 53/tcp 53/udp 80/tcp 110/tcp 143/tcp 443/tcp 465/tcp 587/tcp 993/tcp 995/tcp 8443/tcp 8447/tcp 8880/tcp 49152-65535/tcp
  protocols:
  forward: no
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

Shouldn't 443 have udp there??

When I check or try to add that;

[root@srvtrans-p24 jottentransip.nl]# firewall-cmd --zone=plesk --add-port 443/udp --permanent
Warning: ALREADY_ENABLED: 443:udp
success

Also checked with good old iptables;

[root@srvtrans-p24 jottentransip.nl]# iptables -S
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT DROP
-N f2b-ssh
-A INPUT -p tcp -m tcp --dport 22 -j f2b-ssh
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j REJECT --reject-with tcp-reset
-A INPUT -m state --state INVALID -j DROP
-A INPUT -i lo -j ACCEPT
-A INPUT -p udp -m udp --dport 68 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 49152:65535 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8447 -j ACCEPT
-A INPUT -p udp -m udp --dport 8443 -j ACCEPT
-A INPUT -p udp -m udp --dport 443 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8443 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8880 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 21 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 587 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 25 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 465 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 110 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 995 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 143 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 993 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 106 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 3306 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 5432 -j ACCEPT
-A INPUT -p udp -m udp --dport 137 -j ACCEPT
-A INPUT -p udp -m udp --dport 138 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 139 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 445 -j ACCEPT
-A INPUT -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8/0 -j ACCEPT
-A INPUT -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j REJECT --reject-with tcp-reset
-A FORWARD -m state --state INVALID -j DROP
-A FORWARD -i lo -o lo -j ACCEPT
-A FORWARD -j ACCEPT
-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j REJECT --reject-with tcp-reset
-A OUTPUT -m state --state INVALID -j DROP
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -j ACCEPT
-A f2b-ssh -j RETURN
[root@srvtrans-p24 jottentransip.nl]#

I could actually see packets coming through when using this on the server;

[root@srvtrans-p24 jottentransip.nl]# tcpdump -ni ens3 -c 100 udp and port 443
dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens3, link-type EN10MB (Ethernet), capture size 262144 bytes
20:34:54.415360 IP 185.231.25.22.61977 > 93.119.2.12.https: UDP, length 1200
20:35:11.385934 IP 185.231.25.22.63441 > 93.119.2.12.https: UDP, length 1200

That is me trying from home with;

patrickd@Patricks-MBP ~ % curl -v -s https://foodontour.nl --http3 1> /dev/null
* Host foodontour.nl:443 was resolved.
* IPv6: (none)
* IPv4: 93.119.2.12
*   Trying 93.119.2.12:443...
* QUIC: connection to 93.119.2.12 port 443 refused
* connect to 93.119.2.12 port 443 failed: Couldn't connect to server
* Failed to connect to foodontour.nl port 443 after 75 ms: Couldn't connect to server
*   Trying 93.119.2.12:443...
* Connected to foodontour.nl (93.119.2.12) port 443
* ALPN: curl offers h2,http/1.1
} [5 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.2 (IN), TLS handshake, Server hello (2):
{ [122 bytes data]
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
{ [19 bytes data]
* TLSv1.3 (IN), TLS handshake, Certificate (11):
{ [2603 bytes data]
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
{ [264 bytes data]
* TLSv1.3 (IN), TLS handshake, Finished (20):
{ [36 bytes data]
* TLSv1.3 (OUT), TLS handshake, Finished (20):
} [36 bytes data]
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256 / [blank] / UNDEF
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=foodontour.nl
*  start date: Apr 19 08:05:27 2024 GMT
*  expire date: Jul 18 08:05:26 2024 GMT
*  subjectAltName: host "foodontour.nl" matched cert's "foodontour.nl"
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  SSL certificate verify ok.
} [5 bytes data]
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://foodontour.nl/
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: foodontour.nl]
* [HTTP/2] [1] [:path: /]
* [HTTP/2] [1] [user-agent: curl/8.8.0-DEV]
* [HTTP/2] [1] [accept: */*]
} [5 bytes data]
> GET / HTTP/2
> Host: foodontour.nl
> User-Agent: curl/8.8.0-DEV
> Accept: */*
>
* Request completely sent off
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
{ [249 bytes data]
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
{ [249 bytes data]
* old SSL session ID is stale, removing
{ [5 bytes data]
< HTTP/2 200
< server: nginx
< date: Fri, 17 May 2024 18:34:54 GMT
< content-type: text/html; charset=UTF-8
< x-powered-by: PHP/8.3.7
< strict-transport-security: max-age=63072000; includeSubDomains;preload
< x-xss-protection: 0
< x-content-type-options: nosniff
< referrer-policy: strict-origin-when-cross-origin
< permissions-policy: accelerometer=(*), autoplay=(*), camera=(*), encrypted-media=(*), fullscreen=(*), geolocation=(*), microphone=(*), midi=(*), payment=(*), display-capture=(*)
< x-frame-options: SAMEORIGIN
< cross-origin-opener-policy: same-origin-allow-popups
< cross-origin-resource-policy: same-site
< cross-origin-embedder-policy: same-origin
< content-security-policy: upgrade-insecure-requests;
< x-flying-press-source: PHP
< cache-tag: foodontour.nl
< cdn-cache-control: max-age=2592000
< x-flying-press-cache: HIT
< last-modified: Fri, 17 May 2024 13:10:30 GMT
< alt-svc: h3=":443"; ma=86400
< x-cache-status: STALE
< strict-transport-security: max-age=15768000; includeSubDomains
<
{ [8192 bytes data]
* Connection #0 to host foodontour.nl left intact

patrickd@Patricks-MBP ~ % curl -v -s https://foodontour.nl --http3-only 1> /dev/null
* Host foodontour.nl:443 was resolved.
* IPv6: (none)
* IPv4: 93.119.2.12
*   Trying 93.119.2.12:443...
* QUIC: connection to 93.119.2.12 port 443 refused
* connect to 93.119.2.12 port 443 failed: Couldn't connect to server
* Failed to connect to foodontour.nl port 443 after 24 ms: Couldn't connect to server
* Closing connection
patrickd@Patricks-MBP ~ %

So yeah a bit confused if that means;
A] Local issue with QUIC not being able to process (and then why would that happen)
OR
B] Are we still not reaching the server using 443 UDP.

Any help would be appreciated of course

 

[learning_curve]

~ ~ ~ yeah I am assuming something of a config issue.
The big question being as to where as I tried, Pure Nginx, Nginx as reverse proxy, dedicated fpm, normal nginx fpm ~ ~ ~

Caveats before going any further... Within the data you've posted, it's possible to see most of your server setup, but you don't (currently) have a forum signature, which would be a lot easier. We're on different OS ( AlmaLinux 8.9 - Ubuntu 22.04) and using different Firewall providers (Plesk - Danami Juggernaut) so several different local configs to factor in if/when any comparisons are used. (Space added below, between https:// and domain names, just to avoid the url resolving)

Established configs: You've already checked and posted confirmation that you've opened port 443 on your hosting provider (TransIP) and your Plesk Firewall. You've also checked and posted confirmation that you're using TLSv1.3 and it's easy to independently see, that you do have the required, valid SSL Cert too.

Observations: A simple Reverse IP Lookup i.e. an IP to Hostname Lookup, using the IPv4 address: 93.119.2.12 that you've already posted, always results in your Plesk Login Page: https:// srvtrans-p24.jottenheijm.com/login_up.php and that's on port 443. Usually, mainly for security reasons, you would only want to arrive at https:// srvtrans-p24.jottenheijm.com:8443/login_up.php You've not really mentioned port 8443 so far, apart from confirming (above) that all of the required ports for HTTP/3 are open, but 8443 is relevant. We use sub-domains when hosting Plesk, so any attempts to reach a sub-domain Plesk Login Page on port 443 are negated by config, but if it's simply the sub-domain url itself (not the sub-domain Plesk Login Page) then obviously that's resolved as expected. You've not mentioned your use of IPv6, but in all of the posts made so far that show the results of running this specific query: curl -vDI https:// foodontour.nl/ --http3-only then your IPv6 address is never resolved (which it could / should be IF you are actually using IPv6). Ironically, if you run another Reverse IP Lookup, but this time, using the IPv6 address that you've already posted in post #52 : 2a01:7c8:bb0a:2ba:5054:ff:fe79:6517 then that too, will always result in your Plesk Login Page: https:// srvtrans-p24.jottenheijm.com/login_up.php and again that's also on port 443 of course. Running the opposite checks i.e. a Domain to IP Lookup on https:// foodontour.nl/ provides the IPv4 address: 93.119.2.12 only. Not, the already mentioned IPv6 address: 2a01:7c8:bb0a:2ba:5054:ff:fe79:6517. Appreciate that none of these observations may directly relate to your HTTP/3 issues and in theory, none of those observations, should prevent you from accessing https:// foodontour.nl/ on HTTP/3 anyway, but it's not impossible, that some, small, related config glitch, might be involved in your HTTP/3 issues.

FWIW If we run a HTTP/3 curl test, one of our sub-domain Plesk Login Pages and on port 8443: iMac:~ zqx$ curl -vDI https://***.*****.***:8443 --http3-only
Then it does provide all of the expected (full) results, on both IPv4 and IPv6, on port 8443, all without any issues or delays, so thanks Plesk. Much appreciated.

Customisation of Plesk Login Pages & Plesk over IPv6 are well documented by Plesk already if you do need / want to investigate these items further.

 

[Patrick Dankers]

Thanks again
Always good to bounce ideas around with someone

Yeah the above server is merely a test server, so no worries, I picked that one for a reason.
Main thing is we have well a bunch of servers I plan on setting this up later on once it is clear what is holding us back in getting this running. All different to some degree, but all Plesk, all same host, firewalled (locals/host etc), all using key authentitcation, 2fa/mfa for plesk etc.

If anything happens we will spin up something new and all for this one. I am aware that posting the domain, hostname ip, and what I mentioned here could potentially open up some snakepits of sorts. I understand clearly what you are hinting at.

Yeah most of our installs in the past where CentOS as Plesk always provided features there first, since CentOS has gone the route it has chose we have gone the Almalinux route ourselves.

I can confirm 8443 is openend up in similair fashion to 443 when it comes to UDP and HTTP/3.
We are not using IPv6 for various reasons, one being it brings it own struggles with various thing and as all is using Ipv4, and seeing the IPv4 pool is not exhausted yet, we have not direct reason to as of yet.

I do hope that for the implemenation of HTTP/3 , IPv6 is not a requirement.
But perhaps a member of the Plesk team can comment on that.

Indeed the reverse DNS has been setup to always point to the server hostnames. Perhaps we should include port 8443 in that part. Or change the ports but it never has been a, issue. Also the used subdomain is just a naming convention ... Should not be any real harm in that being setup like it is.

Hope a member of the Plesk team can shed some light on it and perhaps give some insight as Im not clear on where to further look.

I did notice this though;

[root@srvtrans-p24 jottentransip.nl]# plesk bin http3_pref --status
HTTP/3 is enabled for nginx
[root@srvtrans-p24 jottentransip.nl]# service iptables save^C
[root@srvtrans-p24 jottentransip.nl]# plesk bin http3_pref --enable -panel -nginx
HTTP/3 support was activated for Plesk. Make sure your firewall allows 8443/UDP [in/out].
HTTP/3 support was activated for nginx. Make sure your firewall allows 443/UDP [in/out].
You can use the Firewall extension to manage HTTP/3 ports in Plesk.
[root@srvtrans-p24 jottentransip.nl]# plesk bin http3_pref --status
HTTP/3 is enabled for nginx

Should it not note for BOTH nginx and panel ... after just running the command to enable both?

And if it is enabled for Panel; then that is also still going the H2 protocol , not H3.
For reference, it is getting the Alt-Svc header at that point as well.

Thanks again for any suggestions!

 

[learning_curve]

~~~
I can confirm 8443 is openend up in similair fashion to 443 when it comes to UDP and HTTP/3.

Yet, on every curl --http3-only test (to any of the IP addresses / domain names you've posted & on ports 443 or 8443) the QUIC connection is refused. Config?

We are not using IPv6 for various reasons, one being it brings it own struggles with various thing and as all is using Ipv4, and seeing the IPv4 pool is not exhausted yet, we have not direct reason to as of yet. I do hope that for the implemenation of HTTP/3 , IPv6 is not a requirement. But perhaps a member of the Plesk team can comment on that.

Very much doubt that IPv6 is a requirement to use HTTP/3 via Plesk, but no doubt that will be confirmed by Plesk themselves, when answering your question.
Mentioned your IPv6 just in case there was any chance of a collateral damage type of misconfig which wouldn't be immediately seen.

Indeed the reverse DNS has been setup to always point to the server hostnames. Perhaps we should include port 8443 in that part. Or change the ports but it never has been a, issue. Also the used subdomain is just a naming convention ... Should not be any real harm in that being setup like it is. Hope a member of the Plesk team can shed some light on it and perhaps give some insight as Im not clear on where to further look.

All of that ^ is at your discretion, but yes, very much doubt that your use of a sub-domain is either involved or responsible (if it's been configured correctly).
For reference and as posted, we use sub-domains for Plesk and all work perfectly, including with HTTP/3

I did notice this though;
~~~
[root@srvtrans-p24 jottentransip.nl]# plesk bin http3_pref --status
HTTP/3 is enabled for nginx

"Think" that's the default return currently? It's been posted in this thread already and it's what we find too, despite us knowing that our panels are HTTP/3.

Should it not note for BOTH nginx and panel ... after just running the command to enable both?

See above.

And if it is enabled for Panel; then that is also still going the H2 protocol , not H3.
For reference, it is getting the Alt-Svc header at that point as well.

This is your original problem. The one that's not been resolved, so far. It's more and more looking like a UDP / QUIC connection config issue - somewhere!

Only one note to add (that Plesk can comment on) that might be of interest to you: All the posts in this thread and This Plesk Guide only refer to "incoming" UDP connections on ports 443 and 8443 (which is how ours have been congfigured and they work perfectly). Yet, in your last posted data set, it's different:

~~
[root@srvtrans-p24 jottentransip.nl]# plesk bin http3_pref --enable -panel -nginx
HTTP/3 support was activated for Plesk. Make sure your firewall allows 8443/UDP [in/out].
HTTP/3 support was activated for nginx. Make sure your firewall allows 443/UDP [in/out].
~~

 

[Patrick Dankers]

My lord I solved it. Let's track back what happened.

[root@srvtrans-p24 jottentransip.nl]# nc -vuzw 3 foodontour.nl 443
Ncat: Version 7.92 ( https://nmap.org/ncat )
Ncat: Connected to 93.119.2.12:443.
Ncat: UDP packet sent successfully
Ncat: 1 bytes sent, 0 bytes received in 2.01 seconds.
[root@srvtrans-p24 jottentransip.nl]#

Ok so it seems open ...
So still wondering why nothing is coming back.

[root@srvtrans-p24 jottentransip.nl]# nginx -V
nginx version: nginx/1.26.0
built with OpenSSL 1.1.1k  FIPS 25 Mar 2021
TLS SNI support enabled
configure arguments: --prefix=/usr/share --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --modules-path=/usr/share/nginx/modules --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --user=nginx --group=nginx --with-file-aio --with-compat --with-ld-opt=-L/var/jenkins/workspace/PLESK/plesk-aws-bootstrap/buck-out/gen/unix/plesk/packages/brotli/brotli.files/usr/lib64 --with-http_ssl_module --with-http_realip_module --with-http_sub_module --with-http_dav_module --with-http_gzip_static_module --with-http_stub_status_module --with-http_v2_module --with-http_v3_module --add-dynamic-module=mod_brotli --add-dynamic-module=mod_passenger/src/nginx_module --add-dynamic-module=mod_pagespeed --add-dynamic-module=mod_security --add-dynamic-module=mod_geoip2

Ok Nginx has the --with-http_v3_module.
Which it should have to be able to reply.

Thinking out loud;
Host has the ports opened up for sure.
Plesk Firewall (which should be the same as iptables, right?) has it open.
Almalinux also has firewalld (which uses firewall-cmd) ... which does have the ports open according to earlier tests.

Hmm but arent those two interfering with each other?
Let's try that;

systemctl stop firewalld
systemctl disable firewalld

Now only iptables / plesk firewall and host firewall should matter.

Lets double check that iptables is set to be enabled on reboot etc;

systemctl enable iptables

Ok moment of truth;

patrickd@Patricks-MBP test % curl -v -s https://foodontour.nl/contact/ --http3-only 1> /dev/null
* Host foodontour.nl:443 was resolved.
* IPv6: (none)
* IPv4: 93.119.2.12
*   Trying 93.119.2.12:443...
* Server certificate:
*  subject: CN=foodontour.nl
*  start date: Apr 19 08:05:27 2024 GMT
*  expire date: Jul 18 08:05:26 2024 GMT
*  subjectAltName: host "foodontour.nl" matched cert's "foodontour.nl"
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  SSL certificate verify ok.
* Connected to foodontour.nl (93.119.2.12) port 443
* using HTTP/3
* [HTTP/3] [0] OPENED stream for https://foodontour.nl/contact/
* [HTTP/3] [0] [:method: GET]
* [HTTP/3] [0] [:scheme: https]
* [HTTP/3] [0] [:authority: foodontour.nl]
* [HTTP/3] [0] [:path: /contact/]
* [HTTP/3] [0] [user-agent: curl/8.8.0-DEV]
* [HTTP/3] [0] [accept: */*]
> GET /contact/ HTTP/3
> Host: foodontour.nl
> User-Agent: curl/8.8.0-DEV
> Accept: */*
>
* Request completely sent off
< HTTP/3 200
< server: nginx
< date: Sun, 19 May 2024 10:38:06 GMT
< content-type: text/html; charset=UTF-8
< x-powered-by: PHP/8.3.7
< strict-transport-security: max-age=63072000; includeSubDomains;preload
< x-xss-protection: 0
< x-content-type-options: nosniff
< referrer-policy: strict-origin-when-cross-origin
< permissions-policy: accelerometer=(*), autoplay=(*), camera=(*), encrypted-media=(*), fullscreen=(*), geolocation=(*), microphone=(*), midi=(*), payment=(*), display-capture=(*)
< x-frame-options: SAMEORIGIN
< cross-origin-opener-policy: same-origin-allow-popups
< cross-origin-resource-policy: same-site
< cross-origin-embedder-policy: same-origin
< content-security-policy: upgrade-insecure-requests;
< x-flying-press-source: PHP
< cache-tag:
< cdn-cache-control: max-age=2592000
< x-flying-press-cache: HIT
< last-modified: Sun, 19 May 2024 10:16:15 GMT
< alt-svc: h3=":443"; ma=86400
< x-cache-status: MISS
< strict-transport-security: max-age=15768000; includeSubDomains
<
{ [1600 bytes data]
* Connection #0 to host foodontour.nl left intact
patrickd@Patricks-MBP test %

Ok that seems food let's use the suggested check;

https://http3check.net/?host=foodontour.nl

Also that seems good as well.
So let's consider that solved

The main takeway is that Almalinux seems to have firewalld / firewall-cmd from the get go, which seems like a bit of pain in this all.
iptables / plesk firewall + host firewall ... all do what they should and be the only ones needed.

Hope this helps anyone in the future

 

[Patrick Dankers]

Quick sidenote that might also help some people.

We should probably make the iptables rules persistent;

yum install iptables-services

And save the current setup rules;

iptables-save > /etc/sysconfig/iptables

If you have ipv6 rules as well

ip6tables-save > /etc/sysconfig/ip6tables