[GitHub issue by krupa on 2012-06-12T23:25:44Z, https://github.com/mozilla-b2g/gaia/issues/1678] Sometimes SSL certs on websites expire. When this happens, users end up seeing a warning where they explicitly need to add an exception. On a browser, this userflow is pretty simple. How does this work within a webapp?

[GitHub comment by benfrancis on 2012-06-13T11:37:13Z] I think this is a good question for both web apps and web sites used inside the browser app, labelling for UX & security input. Currently we don't have any UI designs for dealing with SSL certificates at all so this is a wider issue.

[GitHub comment by pauljt on 2012-06-13T21:04:12Z] At a glance, I think that an app residing on a https origin should fail to load with no override possibility, ie it should use the copy from the app-cache if there is a certificate failure, or just not load. (not sure about mixed content though) Note this will be a very frequent event, since this will happen every time you are on wifi with a captive portal. The broader question of SSL handling I think requires a lot more treatment.

[GitHub comment by asutherland on 2012-06-13T22:17:31Z] Is the question about SSL errors in general, or just recent expiration? I'm with Paul on the "no easy override in the general case" call. Especially since you can now get free SSL certs (https://www.startssl.com/?app=1), so the barrier to having a valid SSL cert is very low. I got a free cert earlier today via that mechanism to test it. While the website's user interface could use some UX love, it was fairly painless and rather fast. The recent expiration case seems like one where a grace period with or without prompting does not sound unreasonable if the certificate has been previously seen and is the most recently seen certificate for the website. (So it didn't go from expires 1/1/2013 to expires to 1/1/2015, then suspiciously back to 1/1/2013.) A grace period would probably not be suitable for higher confidence certs like EV certs. The expiration case seems like something that would need to be discussed in the context of the gecko platform and certificate UX in general since it's a trade-off of the real world pragmatism of users when faced with poorly maintained websites/services and the security implications of the alternatives.

[GitHub comment by jcarpenter on 2012-06-14T06:02:12Z] I can't speak to the technical or security particulars (not my area of expertise), and given current workload / timelines am not confident we have UX bandwidth to run this down as thoroughly as it probably requires. So I think we may need you guys to come up with the appropriate policy (as you've started to do, above), ideally err on side of not yelling at user unnecessarily, and hit UX up for necessary UI bits (eg: an Alert modal with "add exception" option?)

[GitHub comment by pauljt on 2012-06-29T01:48:33Z] Has there been further discussion on SSL at the work week. The current state as far I was tracking it is: - In general, no SSL indicator as there is no chrome. * We will however provide an interface for apps to open one page for logins/payments. This will have URL bar over-layed over the status bar as per page 13 of https://wiki.mozilla.org/images/7/76/Gaia_Popups_1.pdf - Handling certificate errors: * Option A) Treat all certificate errors are network connection error. App data loaded from cache if exists, or error page is returned. * Option B) Prompt using existing modal dialog mechanism for cert errors. (Modal dialog is likely the only option for V1.0 I think?) Personally, I prefer Option A, but not sure if that is either viable or "inline with the web".

[GitHub comment by nhirata on 2012-07-06T23:52:36Z] Is this related to bug : https://github.com/mozilla-b2g/gaia/issues/1361 with captive portals as well?

[GitHub comment by jds2501 on 2012-09-21T21:24:41Z] Extending this to also cover self-signed certs, as the use case is similar to the case when an expired cert is hit. Noming mainly because the behavior right now is unacceptable - we don't provide any context at all that an expired cert or self-signed cert is hit and on top of that, don't allow the user to override and add an exception to still view the content for https URL with a self-signed cert or an expired cert. As a result, you are basically stuck if you hit this scenario.

Renoming this since as per the above comment. I don't know if there is any plan here, but at the moment the error that is shown is "The address isn't valid" which is really misleading.

Triage: This has been discussed many times before, an interface to manage certificates is out of scope for v1 and we don't yet have a suggested alternative of what to do in these cases. Please renominate if there's a specific suggestion about how this can be improved for v1. Is it possible to display a different error message in specific cases for example?

This is related with bug 769183, and 769178, if not a duplicate/aggregate of both.

apperror-004 https://moztrap.mozilla.org/results/case/62953/

This was fixed as part of bug 796362.

(In reply to Jason Smith [:jsmith] from comment #12) > This was fixed as part of bug 796362. > > *** This bug has been marked as a duplicate of bug 769178 *** Meant to say - fixed as part of bug 769178.