- From: James Graham <james@hoppipolla.co.uk>
- Date: Tue, 23 Sep 2014 19:05:52 +0100
- To: "public-test-infra@w3.org" <public-test-infra@w3.org>
This is, I think, the next important thing to work on since it is required for testing a large number of things. It's also rather complicated since real CAs can't let us do the things that would be needed to let everyone run their own web-platform.test domain. Instead I propose that we adopt a variation of the method that Mozilla already uses. This will rather depend on running the tests in some automated way (e.g. using wptrunner) since it's an essential requirement of the approach that the profile used for running tests is transient. Essentially the approach is to use a "fake" CA. When the profile for testing is created, the certificate for that CA will be installed into the browser's profile such that certificates signed by that CA will be trusted by the browser. One such host certificate will be issued covering the test domains, and will be used to enable https and wss in wptserve and pywebsocket, respectively. Obviously letting this happen in a profile used by a real user would be terrible, so we can't do anything like this to solve the "interactive" use case (i.e. running python serve.py and loading urls in a normal browser instance). I don't know that there's a good solution for that case. Quite a bit of this is, or can be, browser-specific. In fact the only generic API is going to be something like Browser.get_host_certificate() which will return the certificate file needed when starting the server. However I expect there will be utility functions for all the other parts i.e. generating a CA and issuing a certificate from that UA, so the amount of browser-specific implementation work will be small; the main requirement will be doing whatever's needed so that browser trusts the fake CA. Does this sound like a sensible plan? Will it work with test setups other than Mozilla's?
Received on Tuesday, 23 September 2014 18:06:19 UTC