This addresses an issue where connecting to multiple Server instances from a single tab in Firefox would result in an SSL handshake error. Using the same certificate across all Server instances fixes the issue, so I've implemented a way of doing that.
I opted to share the entire openssl::SslConnector since it can be trivially wrapped in an Arc. I exposed the Crypto type but kept it opaque, and added a Server::with_crypto constructor to optionally allow passing in a Crypto instance.
Usage example:
// Create a new Crypto instance, creating a new certificate
let crypto = Crypto::init().expect("WebRTC server could not initialize OpenSSL primitives");
// Instantiate two servers sharing the same Crypto instance
let server1 = Server::with_crypto(listen_addr, public_addr, crypto.clone()).await.unwrap();
let server2 = Server::with_crypto(listen_addr, public_addr, crypto).await.unwrap();
I can change it to a constructor that takes an openssl::pkey::PKey if you prefer not exposing Crypto. Would give the user more flexibility but a more complicated API.
I can also change the Server::with_crypto constructor to be a builder API or something if you prefer.
This addresses an issue where connecting to multiple Server instances from a single tab in Firefox would result in an SSL handshake error. Using the same certificate across all
Server
instances fixes the issue, so I've implemented a way of doing that.I opted to share the entire
openssl::SslConnector
since it can be trivially wrapped in anArc
. I exposed theCrypto
type but kept it opaque, and added aServer::with_crypto
constructor to optionally allow passing in aCrypto
instance.Usage example:
I can change it to a constructor that takes an
openssl::pkey::PKey
if you prefer not exposingCrypto
. Would give the user more flexibility but a more complicated API.I can also change the
Server::with_crypto
constructor to be a builder API or something if you prefer.I'll add doc comments when the API is decided.