W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

AW: AW: AW: WebSocket API: close and error events

From: Tobias Oberstein <tobias.oberstein@tavendo.de>
Date: Tue, 25 Oct 2011 14:11:58 -0700
To: Simon Pieters <simonp@opera.com>, Ian Hickson <ian@hixie.ch>
CC: "public-webapps@w3.org" <public-webapps@w3.org>
Message-ID: <634914A010D0B943A035D226786325D42D0B0374E0@EXVMBX020-12.exch020.serverdata.net>
> > Does that mean Opera might just _silently_ reject untrusted certs
> > without giving the user a dialog to accept the cert?
> Right.
> > That would be unfortunate IMHO. Since then there is no way to get an
> > acceptable user experience any longer.
> >
> > I can't present a JS created notification and act accordingly, since
> > JS won't be allowed to detect "invalid cert".
> >
> > I can't rely on the browser rendering a builtin dialog for the user to
> > accept the cert.
> >
> > WSS just fails silently.
> >
> > How is a JS app using WSS supposed to create an acceptable user
> > experience?
> By using a cert that isn't rejected.

There are situations when self-signed certs are quite common like on
private networks or where self-signed certs might be "necessary",
like with a software appliance that auto-creates a self-signed cert
on first boot (and the user is too lazy / does not have own CA).

The latter is our deployment scenario.

We won't ship a fresh key / cert created by an official CA with every appliance.

We won't force users to upload such a key/cert before they can use the appliance
with https and wss.

We need a smooth user experience for users to accept permanently the auto-created
self-signed certs for https and wss the appliance uses.

We will offer them a way to upload keys/certs when and if they want to.

Do you think thats an invalid use case / approach?

Received on Tuesday, 25 October 2011 21:12:40 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:36 UTC