Waku v2 bootstrap after moving from unencrypted WS to WSS: DNS discovery and certificate validation expectations

Question

I'm planning a configuration change for a node running Waku v2: the bootstrap path currently relies on EIP-1459 DNS discovery (enrtree TXT records) to find fleet peers, and I want to require secure websockets (WSS) for those connections instead of plain WS.

The uncertainty is where trust is actually anchored in each step. My understanding is that the enrtree domain itself must be trusted to hand out valid bootstrap records, and that WSS certificate validation falls back to the host system's CA bundle rather than anything Waku-specific. If that is correct, a missing or outdated root certificate on the host would surface as a TLS handshake failure even though DNS discovery succeeded.

I'm also unsure how version-sensitive this is: older Waku implementations reportedly defaulted to unencrypted connections, so I want to confirm what current releases enforce before assuming WSS validation is strict by default.

Specifically:

Does Waku v2 perform any validation of the enrtree DNS records beyond trusting the configured domain, or is domain selection the entire trust decision?
For WSS bootstrap connections, is certificate validation always delegated to the system CA store, and can it be pinned or overridden?
Is there a documented release boundary where WSS with certificate validation became the expected default for fleet bootstrap?

Tasadduq Burney · Answer

Answer
Waku v2 does validate the enrtree TXT record beyond simply trusting the domain; it checks the record's cryptographic signature. For WSS bootstrap connections, certificate verification is performed by the underlying TLS library using the host's CA bundle, but you can override or pin verification via Waku's TLS configuration options. Starting with the v2.0.0 release (early 2023), the bootstrap process defaults to WSS with strict certificate validation; earlier pre‑v2 releases allowed plain WS as the default and did not enforce TLS verification by default.
Confirmed facts

Enrtree TXT record validation: signature check performed by Waku's discovery module.
WSS certificate handling: delegated to the system TLS library's root store; configurable via custom root pool or disabling verification.
Version boundary: Waku v2.0.0 introduced WSS-only bootstrap with strict TLS verification as the default.

Likely explanation
If DNS discovery succeeds but the WSS handshake fails, the most probable cause is an outdated or missing root certificate in the host's CA bundle, because Waku relies on that store for trust anchoring.
Steps to ensure WSS bootstrap works

Confirm you are running Waku v2.0.0 or later (check waku version).
Verify that the system's CA certificates are up to date (e.g., sudo update-ca-certificates on Debian-based hosts).
Optionally provide a custom root CA pool via Waku's TLS config (--tls-root-ca-file) if you need to pin or supplement the system store.
Enable verbose logging (--log-level=debug) to see "enrtree signature verified" and TLS handshake details.

One missing detail that would change the recommendation: what exact Waku v2 version are you currently running?

Waku v2 bootstrap after moving from unencrypted WS to WSS: DNS discovery and certificate validation expectations

1 answer

Answer

Confirmed facts

Likely explanation

Steps to ensure WSS bootstrap works

Your perspective belongs here.

0 question comments