louaybassbouss
commented
2 years ago @jpiesing in WMAS is less an issue since we don't access the tests via IP Address, but it requires to setup all required WPT domain and subdomains properly (these are more than 200 subdomains required for different tests). This is already done for the hosted WMAS instances on AWS. For local deployment, we decided in WMAS2019/WMAS2020 development to provide a local DNS Server (part of docker deployment) that can resolve all required domains/subdomains. This is still WIP.
In DPCTF we don't need this complexity this is why we activated the option to access the Test Runner via IP Address. But this can cause the issue for https tests you mentioned. My proposal:
- Step1: update the documentation and warn about this if the test runner is accessed via IP Address
- Step2: Enable the option to use the test runner via local DNS server as in WMAS. For DPCTF we need to resolve only the domain
web-platform.test. For this option, the IP of local DNS server needs to be configured on the DUT.
@jpiesing wdyt?
jpiesing
gitwjr
FritzHeiden
The docker web server needs to use TLS for the encrypted content tests and uses a certificate that is not descended from a normal root certificate supported in web browsers.
Depending on the browser, you may get an option to add a temporary exception or a permanent exception or no choice at all.
I don't know if there's a way around this. There may not be.
At least there should be something in the documentation warning people to add an exception if the device they are testing permits this. If the device does not permit this then it may be necessary to side-load the appropriate root certificate - a reference to this should be provided. I guess this is a WMAS issue as well?