Chrome 47 WebRTC and ssl

Some time ago I wrote this WebRTC peer to peer tutorial. It worked well until 2 weeks ago when I tried some WebRTC testing with the new Chrome version 47. With version 47 it did not longer work. Google declared HTTP support for the getUserMedia functionality as depraceted already some time ago. And now it happened. The node.js signaling server which is part of the tutorial provides the WebRTC application via HTTP and that is not longer supported. This is another example that WebRTC is still under heavy development and that a product developer must follow the change processes carefully.

Starting with version 47 Chrome does not longer support getUserMedia on non ssl Domains. It is not longer possible to access the video and audio from a Web camera in Web applications which are loaded from a non ssl origin. If a page is loaded via HTTP one gets the error:

"getUserMedia() no longer works on insecure origins. To use this feature, you should consider switching your application to a secure origin, such as HTTPS. See for more details."

For the development and test of WebRTC applications that means that one must provide the WebAPP from an ssl domain - at least for testing with Chrome. The current Firefox version 43 and Opera version 33 still allow getUserMedia on HTTP domains. Here one gets the familiar browser dialog to confirm the access to the camera. After that one can test the WebRTC application.

For testing WebRTC / getUserMedia applications with Chrome without ssl one can load the WebRTC application from:

  • a local file.

  • a local Web server with http://localhost/... or

Of course that just allows testing on the local machine. Distributed scenarios with multiple machines for WebRTC applications cannot be tested and demonstrated well by these means - even within the local intranet.

So the developper is forced to use either Firefox or Opera for demonstrations or to provide ssl certificates for the test Web- and signaling server server. It may be assumed that getUserMedia access will be restricted in the future on all browser platforms to secure ssl origins. That's why one should change the local WebRTC test environment already now. Fortunately self signed ssl certificates are still accepted - and hopefully remain so. You may create a self signed certificate for example with openssl. The browser produces a warning for domains which use such a certificate. If you confirm that you trust such a domain nevertheless the browser loads it and you have the right to access the camera via getUserMedia.

Modifications of the SimpleP2P sample

To provide the WebRTC tutorial application from an ssl origin the node.js server code (app.js) had to be changed in the following way.

var fs      = require("fs");
var https   = require("https");
var express = require("express");
var io      = require("");

// setup https express WebServer and WebSocket Server
var app = express();
var webServer = https.createServer(
        key  : fs.readFileSync("server.key"),
        cert : fs.readFileSync("server.crt")
    }, app).listen(7000);
app.use(express.static(__dirname + "/static/"));
var SocketServer = io.listen(webServer);
  • the server still listens on test port 7000 but now it starts an ssl listener

  • the server loads the 2 certificate files server.key and server.crt which had been created with openSSL

  • the 2 ssl certificate files have been added to the project at github to have again a running hello world

The client code in peer.html had to be changed as well. Because it uses jQuery from a CDN the reference had to be changed to an HTTPS source instead of HTTP. Otherwise the browser produces mixed content errors because it does not accept to load Javascript code from insecure HTTP origins into an Web application which was provided from an ssl origin.