The test was green. Every real connection would have failed.

The code in question for DEV's Summer Bug Smash: Smash Stories powered by Sentry involved WebRTC-Direct in libp2p, which allows connecting without a certificate authority. The multiaddr contained a hash of the peer's TLS certificate. For this to work, py-libp2p had to make aiortc use the libp2p-generated certificate instead of the auto-generated one.

The code pinned the certificate by creating an RTCConfiguration with the cert and then creating an RTCPeerConnection with that configuration. However, this approach was incorrect in two ways. First, the certificates= parameter was removed from RTCConfiguration in aiortc ≥ 1.5, causing a TypeError when passed. The fix was easy: move the cert onto the object after construction.

The second issue was that aiortc never reads the _certificates attribute, which was used to store the cert. Instead, it stores and reads the cert under self.__certificates, which is mangled to self._RTCPeerConnection__certificates. From the outside, setting pc._certificates would create a new attribute that aiortc reads, while setting pc._RTCPeerConnection__certificates would be the correct way to set the cert.

The loopback echo test passed, as it doesn't validate the DTLS fingerprint against the multiaddr. The root cause of the issue was in the seam between Python's language rule of name mangling and aiortc's library internals, which relied on the mangled name for its own encapsulation. When reaching into a library's private state from outside the class, the mangled name is the only name that works, making the un-mangled name a no-op that fails silently.

The fix involved setting the mangled attribute directly, after construction, before any SDP operation triggered the handshake. A test was added to assert that the pinned cert's fingerprint must appear in the SDP, catching the silent failure. The lessons learned were to test the invariant, not just the happy path.