From W3C Wiki

Note: The HTTPS in Local Network Community Group has been launched. If you have an interest in this topic, please join us!

Why do local network devices want HTTPS/WSS?

Devices in a local network

For now, there are various kinds of devices which would implement HTTP server capability, e.g.:

  • In-vehicle infotainment (IVI)
  • Smart TVs and Set-top boxes
  • Wi-Fi enabled storage devices, like Eyefi (

Such devices are often accessed by mobile browsers on smartphones, tablets, etc. via a local network. Since these devices would not usually have publicly valid certificates to establish TLS session without adding private CA's certificate to mobile browsers, these devices might have no choice but to establish HTTP and/or WebSocket connection without TLS.


  • Mixed Content: When web apps is in Secure Contexts (e.g. cloud services), the web apps cannot connect to local network device's URL such as http:// and ws://.
  • Features permitted in Secure Contexts: When web apps is in local network device's origin (not in Secure Contexts), powerful features like getUserMedia, WebBluetooth, etc. become unavailable.


In this session, our goal is to incubate how to enable local network devices to establish HTTPS/WSS without insecure and incompatible ways.

Analysis and discussions

Presentation 1: HTTP migration in Local Network

This presentation was an introduction to the session.

The talker picked up vehicle and local video storage as examples where local servers play a big role. To mash up cloud services and local devices(services), TLS certificates for these devices is raised as an issue to be addressed. PLEX’s technique was explained as a solution but it could be improved in the aspect of privacy consideration, service discovery and certificate management. The talker also emphasized that the solution should be widely acceptable one by various stakeholders such as browser bender, device maker, automaker, network operator etc.


  • Brad: Plex’s solution would be acceptable by the CA/Browser forum guidance. The point of the guide is, for instance, when looking up 'mail' that returns different certs in different environment.
  • Giribhar: You can have trusted association between local devices and private certs can work.

Presentation 2: Local Discovery and HTTPS

This presentation addresses problem of discovery of local devices. UA can have local CA's certificates (or self-signed) if well-managed locally. However, self-signed certs are regarded as insecure by modern browsers and often cause Mixed Content.

Local network traffic should be encrypted as well. Thus, our straw man proposal is to use TLS server certs with FQDN and public DNS for LAN devices. First, the local device registers its LAN address FQDN to a dynamic DNS server. Then, local mDNS responds CNAME to the (public) dynamic DNS server.

Use cases are like below:

  1. local media server page can be displayed in WebView. EME in Secure Context is possible.
  2. Presentation API discovery is possible.


  • Brad: CNAME approach could be problematic because trust between DNS servers is not enough.
  • Cullen: mDNS in public Wifi can be easily spoofed.

Presentation 3: “.local” Server Certificate for HTTPS migration on local network

This presentation focuses on not only the mixed content problem that UAs don't allow secure origins to access to local network devices, but also additional problems below:

  • local network device discovery
  • user authorization and third-party validation to allow cross-origin access from secure origins to local network devices
  • synchronization of user authentication between the secure origin and the local network device.

To solve these problems, the presentation proposes a candidate solution:

  • UA uses ".local" server certificates for local domains (e.g., media-cache-server.local) only if a user and the UA grant it. The ".local" server certificates probably don’t chain up to trusted root CAs.
  • UA provides a new API to allow secure origins to access to local network devices by issuing the .local server certificates and controlling the use of them.

In addition, the presentation proposes requirements for the API and shows a PoC implementation built on Web Bluetooth API.


  • Anne: Focus with user consent is good. Tap on the device could approve establishing secure connections.
  • mkwst: Host name + hash of public key might be one way to achieve this.
  • Cullen: If we assume dynamic DNS, nothing stops that the device decides it's unique host name.
  • Anne: Local IP address disclosure is different between these solutions.

Next steps

  • The session proposers will continue to incubate HTTPS/WSS capability for local network devices.
  • Further abstraction seems to be needed.
  • The session proposers would like to prepare a place to have an open discussion, e.g. a mailing list and/or a new CG.

Breakout session summary



Kay Ashimura(W3C), Kaoru Maeda(Lepidum), Daisuke Ajitomi(Toshiba), Junichi Hashimoto (KDDI), Tomoyuki Shimizu(KDDI), Giri Mandyam(Qualcomm), Tatsuya Igarashi(Sony), Tomohiro Yamada(NTT), Kiyoshi Tanaka(NTT), Matsuo Suzuki(SoftBank), YounJae Shin(SoftBank), Hamid Amir Alikhani(Panasonic), Licheng Yin(Qihoo360), Francois Daoust(W3C), Yves Lafon(W3C), Mike West(Google), Mike Smith(W3C), Brad Hill(Facebook), Jiajia Li(Alibaba), Roulant Solomakhin(Google), Joe Hall(Center for Democracy and Technology), Mohammed Dadas(Orange), Jin Peng(China Mobile), Yingying Chen(W3C), Olive Xu(W3C), Kazuhiro Hoya(J-BA), Claes Nilsson(Sony), Jetinder Mann(Microsoft), Yoshiaki Ohsumi(Panasonic), Kauz Kajimoto(Panasonic), Takeshi Kanai(Sony), Cullen Jennings(Cisco), Ari Keranen(Ericsson), Carsten Bormann(TZI), Toshihiko Yamakami(ACCESS), Natasha Rooney(GSMA), Vivien Lacourba(W3C), Osamu Nakamura(W3C), Adam Roach(Mozilla), Koichi Takagi(KDDI), J.C. Jones(Mozilla), Rik Cabanier(Adobe), Mark Foltz(Google), Hyojin Song(LGE), Kenichi Nunokawa(Keio), Satoshi Nishimura(NHK), Anne van Kesteren(Mozilla), James Graham(Mozilla), Wonsuk Lee(ETRI)

Session proposers

  • Presenters: Junichi Hashimoto (KDDI), Tatsuya Igarashi (Sony), Daisuke Ajitomi (Toshiba)
  • Moderator: Tomoyuki Shimizu (KDDI)