Node unable to sync via WSS

[senseless]

I'm attempting to test the WSS listeners needed when operating bootnodes according to new specifications listed here:
https://forum.polkadot.network/t/community-bootnodes-and-snapshot-providers/630/2?u=bkchr

I've deployed haproxy with a SSL frontend to redirect to the listener port defined for WS in the service file. To test the deployment of wss I have compiled a node with only a single defined bootnode in the chain-specs file. When I launch the bootnode it fails to connect and I only see "SSL handshake failure" on the server side. It appears that the node is not attempting to communicate via SSL to the termination point. If I remove the ssl certificate and haproxy everything works correctly and the node is able to retrieve a list of network peers.

To recreate:

1. Setup a boot node websockets listener with a SSL certificate in front of it ("--listen-addr /ip4/0.0.0.0/tcp/32335/ws")
2. Attempt to use that web sockets address as a bootnode ("/dns/domain/tcp/32334/wss/p2p/12D3...")

Note: My haproxy listens on port 32334 and redirects the decrypted connection to 32335.

[BulatSaif]

Thank you for submitting the issue.

Can you please provide more information on which certificate are you using?
We tested it with Let's Encrypt certificate it works as expected,

Here is the Nginx configuration which we used for testing.

upstream websocket {
  server 127.0.0.1:30334;
}

map $http_upgrade $endpoint {
  default websocket;
  '' close;
}


server {
  listen                443 ssl;
  server_name           example.org;
    ssl_certificate /etc/letsencrypt/live/example.org/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/example.org/privkey.pem; # managed by Certbot

  location / {
    limit_req zone=zone burst=10;
    proxy_buffers 16 4k;
    proxy_buffer_size 2k;
    proxy_pass http://$endpoint; 
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "Upgrade";
    proxy_set_header Host $host;
   }
}

Node was started with --listen-addr=/ip4/0.0.0.0/tcp/30334/ws flag.

[senseless]

I'm using a Let's Encrypt certificate as well my haproxy configuration is as follows:

global
   log 127.0.0.1 local2
   chroot /var/lib/haproxy
   pidfile /var/run/haproxy.pid
   maxconn 250000
   user  haproxy
   group haproxy
   daemon
   nbthread 8
   tune.bufsize 131072
   tune.ssl.default-dh-param 4096
   stats socket /var/run/haproxy.sock mode 600 level admin
   stats timeout 2m
   maxcompcpuusage 50

defaults
   log global
   option httplog
   retries 3
   maxconn 250000
   timeout connect 5s
   timeout client 300s
   timeout server 300s

frontend frontend
   bind *:32334 ssl crt /etc/pki/boot.stake.plus.pem
   mode http
   default_backend backend

backend backend
   mode http
   server local 127.0.0.1:32335 check inter 2s

You can verify that the ssl certificate is functional at https://boot.stake.plus:32334/

In this section of your nginx configuration, are you forcibly upgrading the connection to a websocket?

map $http_upgrade $endpoint {
  default websocket;
  '' close;
}

[senseless]

I attempted to force the websocket/upgrade headers necessary and still receiving the following:

frontend/1: SSL handshake failure

[BulatSaif]

I don't have big experience with Haproxy, But I think the issue is not in Haproxy. SSL handshake failure means you have an issue even before HTTP connection was upgraded to the WebSocket.

Please, check the chainspec, your bootNodes section should look like that:

  "bootNodes": [
    "/dns/boot.stake.plus/tcp/32334/wss/p2p/12D3KooWGFYW6hJYn3pkpJawyMk6souXh7sznK8yvPmVQ7ktfHbV"
  ],

[senseless]

Yes, it's entered like that and I also tested with it manually on the CLI with the --bootnodes options. The weird thing is that I do see that other clients are connecting to that port and connecting without SSL issues. Is there a specific tag or branch I should be using when attempting to compile and test? I'm currently using master.

  "name": "Westend",
  "id": "westend2",
  "bootNodes": [
    "/dns/boot.stake.plus/tcp/32334/wss/p2p/12D3KooWK8fjVoSvMq5copQYMsdYreSGPGgcMbGMgbMDPfpf3sm7"
  ],

[BulatSaif]

Is there a specific tag or branch I should be using when attempting to compile and test?

Hmm, how are you planning to compile JS code? Look like we had a misunderstanding.
Websockets endpoint is used by a light client. The light client is the JavaScript package https://docs.substrate.io/fundamentals/light-clients-in-substrate-connect

1. You deploy the regular node with flags "--listen-addr /ip4/0.0.0.0/tcp/32335/ws"
2. Set up http-proxy with a certificate
3. Use the JS light client to connect and test.

[senseless]

Does that mean it is not intended that a node at boot will use /wss/p2p/ to find its' initial peers? Maybe this is where my confusion is coming from. I expected the node to be able to utilize this /wss/p2p/ endpoint for peer discovery. When deploying bootnodes for inclusion in source for merge, should I include both /p2p/ and /wss/p2p/?

Thanks

  "name": "Westend",
  "id": "westend2",
  "bootNodes": [
    "/dns/boot.stake.plus/tcp/32334/wss/p2p/12D3KooWK8fjVoSvMq5copQYMsdYreSGPGgcMbGMgbMDPfpf3sm7"
  ],

or

  "name": "Westend",
  "id": "westend2",
  "bootNodes": [
    "/dns/boot.stake.plus/tcp/32333/p2p/12D3KooWK8fjVoSvMq5copQYMsdYreSGPGgcMbGMgbMDPfpf3sm7",
    "/dns/boot.stake.plus/tcp/32334/wss/p2p/12D3KooWK8fjVoSvMq5copQYMsdYreSGPGgcMbGMgbMDPfpf3sm7"
  ],

[xlc]

/wss/p2p is not supported by Substrate paritytech/substrate#12024