[Blocked on libWebRTC] PixelStreaming, TURNS + LetsEncrypt = does not work?

[Zeouterlimits]

Component your question relates to

• Signalling server
• Frontend library
• Frontend UI library
• Matchmaker
• SFU
• This repo
• Other

Background

• Running our own coturn servers
• Generating certs using letsencrypt
• Pixel Streaming is working with our coturn on non TLS + port 5349
• For turns, trickleIce succeeds, gets a relay
• For turns, the browser client seems to succeed but the Pixel Streaming client does not [both 5.4 + 5.6]
• Coturn error log: reason: TLS/TCP socket buffer operation error (callback)
• Running wireshark on the pixel streaming client finds this error: TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Unknown CA
• libwebrtc library seems to previously had hardcoded certificate authorities that didn't include letsencrypt (Unable to get relay candidates via turns (TLS) coturn/coturn#247 (comment), https://issues.webrtc.org/issues/42221823)

Question

1. Have others encountered this? Am I right in that it seems to be an issue with the bundled libwebrtc in Pixel Streaming?
2. Are there any suggested fixes other than a different (not LetsEncrypt) certificate authority

[lukehb]

@Zeouterlimits Any updates on this one?

This is personally not a combination we have tried (let's encrypt + CoTURN) but I don't see any issue why it shouldn't work, though the linked bug does seem compelling that this may require a WebRTC upgrade to resolve.

[Zeouterlimits]

Unfortunately nothing we have done has resolved this, occurs in both 5.4 + 5.6, we will likely try another cert provider.

[github-actions]

Issues go stale after 30 days of inactivity. Please comment or re-open the issue if you are still interested in getting this issue fixed.

[Zeouterlimits]

Still interested in getting this fixed 🙏

[lukehb]

The bug ticket related to the underlying libWebRTC issue appears to still be in "in progress" - https://issues.webrtc.org/issues/42221823

Hopefully it is fixed in such a way that Let's Encrypt becomes a default CA in their hardcoded list. If that happens and is landed in libWebRTC we can update to that version and it should fix the issue.

However, as of now (10th Oct 2025), the problem I see is the libWebRTC authors still have not made any changes on the linked issue to use the OS's trust store or Let's Encrypt in the default list of CAs. Without that, it would mean we would have to patch our libWebRTC on the UE side or use the run-time API to add the Let's Encrypt CA, e.g.

rtc::InitializeSSL();
// Set the verifier before creating PeerConnections.
rtc::SSLIdentity::SetCertificateVerifier(std::make_unique<CustomCertVerifier>("/path/to/your/ca.pem"));

BUT even if we did all that, that is only one side of the equation, the other side is the browsers, without them adding Let's Encrypt in the default list of CA then all Chrome-based browsers would still be an issue... so for now we wait. I would consider giving that ticket a few bumps perhaps?

[Zeouterlimits]

There has been a patch on libWebRTC:
https://issues.webrtc.org/issues/42221823#comment18

Currently, the SSLCertificateVerifier interface in WebRTC only provides 
    the leaf certificate to the Verify() method. This is insufficient for 
    environments that require full certificate chain validation (e.g., when 
    using private CAs or custom trust models). 

This CL extends the `SSLCertificateVerifier` interface to accept an
`SSLCertChain` as input to the new `VerifyChain()` method, enabling
custom verifiers to access the entire certificate chain for validation.
For backward compatibility, the original `Verify()` method is retained
and internally calls `VerifyChain()` with a single-element chain.

[lukehb]

Okay that bodes well! I think we might be doing a WebRTC upgrade some time after UE 5.7 ships btw.