| The problem with allowing self-signed certificates has always been distinguishing if a site should be signed by a CA or not. Consider the follow situation: Alice sends Bob a link: http://example.com Bob trusts Alice and now knows that example.com is probably ment to be accessed over HTTP. Now for the next example: Alice sends Bob a link: https://example.com With the current implementation of browsers Bob knows that example.com should present a CA signed certificate. But what if example.com wants to encrypt their data, but for whatever reason uses a self-signed certificate? Some people say that Bob's browser should not display a "big scary" warning, but instead display a UI similar to when accessing a HTTP site. However, in this situation HTTPS has lost some meaning. I think http2 should work as follows: http2:// - encrypted, not verified https2:// - encrypted and verified This way the protocol still conveys the same level of information. However, if it were completely up to me, I would say ditch the CAs and use namecoin to verify certificates. |
That's why self-signed certificates work in this context; the identity of the server's not supposed to be validated (unencrypted HTTP can't validate server identities), so the browser can accept a self-signed certificate without warning.
There's no change to how certificates are authenticated when accessing a site via an https:// URL.