Matthew Hardeman wrote: > 6. Thus, the direction this goes is that the developer creates a self-signed > cert and imports it into the trust store. The developer may do this on the > software host, but historically is more likely to just create one and package > it just like they did with the trusted ones before. Only now, the developer > has to annoyingly ask for admin permission to install the certificate to the > trust store. All because they want to be able to run web-sockets or HTTP(s) > to the local host at the command of the browser, as directed by a remote web > site. Mere revocation of the trusted certificates is not sufficient to stop > the bad practices which will arise (and have already arisen) in response to > revoked certificates. > > 7. My proposal would almost certainly halt the interest in trusted > certificates which refer back to the local endpoint -- particularly for > shared certs/keys. > > Thanks, > > Matt Hardeman
In the case of "localhost" there's even no need to import the certificate to the certificate store: browsers can be told to automatically skip certificate validation for 'localhost'. Chrome is one of the browsers that implemented this validation bypass for localhost, you need only to set a flag in settings to enable it and you don't need to mess with the certificate store after that: chrome://flags/#allow-insecure-localhost *Allow invalid certificates for resources loaded from localhost.* Allows requests to localhost over HTTPS even when an invalid certificate is presented. Mac, Windows, Linux, Chrome OS, Android Also, these restrictions should fit in nicely with the upcoming standard https://tools.ietf.org/html/draft-ietf-dnsop-let-localhost-be-localhost-02 ~~~~ Adrian R. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
