Hi! I think TURN/TLS certificate verification in the FFI is using an incomplete embedded root bundle.
Environment
livekit Python 1.1.13 / livekit-ffi 0.12.68 on macOS- Also reproduced with Python SDK 0.22.0, 1.0.0, and 1.0.25
- TURN/TLS on port 443 behind an AWS NLB, using an ACM certificate
Minimal reproduction
from livekit import rtc
config = rtc.RtcConfiguration(
ice_transport_type=rtc.IceTransportType.TRANSPORT_RELAY,
)
room = rtc.Room()
await room.connect(url, token, rtc.RoomOptions(rtc_config=config))The signaling connection and JoinResponse succeed, but the RTC connection times out with ICE error 701. A browser connects to the same room successfully.
A packet capture shows the server sending ServerHello and its certificate chain, followed by the client sending TLS fatal alert 48 (unknown_ca). No TURN allocation is attempted.
The chain ends at Starfield Services Root Certificate Authority - G2. WebRTC M144's embedded root bundle does not contain that root. I reproduced this directly with its BoringSSL build: verification fails with the embedded bundle, then succeeds after adding the missing root (SHA-256 56:8D:69:05:A2:C8:87:08:A4:B3:02:51:90:ED:CF:ED:B1:97:4A:60:6A:13:C6:E5:29:0F:CB:2A:E6:3E:DA:B5).
Could the embedded roots be updated, or could TURN/TLS use the OS trust verifier?
Hi! I think TURN/TLS certificate verification in the FFI is using an incomplete embedded root bundle.
Environment
livekitPython 1.1.13 /livekit-ffi0.12.68 on macOSMinimal reproduction
The signaling connection and
JoinResponsesucceed, but the RTC connection times out with ICE error 701. A browser connects to the same room successfully.A packet capture shows the server sending
ServerHelloand its certificate chain, followed by the client sending TLS fatal alert 48 (unknown_ca). No TURN allocation is attempted.The chain ends at
Starfield Services Root Certificate Authority - G2. WebRTC M144's embedded root bundle does not contain that root. I reproduced this directly with its BoringSSL build: verification fails with the embedded bundle, then succeeds after adding the missing root (SHA-25656:8D:69:05:A2:C8:87:08:A4:B3:02:51:90:ED:CF:ED:B1:97:4A:60:6A:13:C6:E5:29:0F:CB:2A:E6:3E:DA:B5).Could the embedded roots be updated, or could TURN/TLS use the OS trust verifier?