Thanks for the answer.
Our doubt is where into react-native-webrtc must be set our certificate. We thought that the change must be done into RTCPeerConnection, but we tried to change that at JitsiMeetSDK implementation of this class or using RTCPeerConnection.generateCertificate at webrtc.js, but none of these things worked.
Alas we don’t currently have RTCPeerConnection.generateCertificate implemented in the React Native wrapper. If this is something you are interested in working on, I’d be happy to take a PR.
But you think that only with the implementation of generateCertificate method into the wrapper, it would be enough to be used as the DTLS certificate? Or WebRTC code should be modified also?
Our case is to avoid Man-in-the-middle attacks, and use our own certificate to verify the client on server side.
The article says that you can include it into a call to a connection’s setConfiguration(), but we couldn´t find how can certificates be included into the configuration. Example of how to inclue iceservers is easy to find.
So, I don´t know if it is going to be possible wrap the logic of generateCertificate method into react-native-webrtc or if something more is going to be needed.
I think setting it in the constructor makes more sense, to avoid having to reconnect.
Either way, there is no way to pass that at the moment, and since we have no WebCrypto APIs in RN I’m not sure how we’d pass it around. Maybe we could use a Blob with the base64 encoded data, and then set it properly in native.