Although *you* know your certificate is OK because you know you created it and that you operate the server, the client software (Chrome or other) cannot know that with the information it has at run-time. That is why Chrome and most other browsers do not accept self-signed certificates for arbitrary hostnames. Software developed for developers and operations teams sometimes has a different policy, but software developed for a general audience cannot make the necessary simplifying assumptions that e.g. `curl` or `ssh` can.

You can choose to accept self-signed certificates by clicking on Advanced in the interstitial screen. (See screenshot.) Chrome remembers the decision for 1 week; the reason for that time frame is explained here: https://www.usenix.org/conference/soups2016/technical-sessions/presentation/weinberger

There has been discussion of exempting certain hostnames/domains from certificate validation checks, or altering the validation procedure for them, but it is a surprisingly complex problem. (For example, apparently in some circumstances, the name "localhost" may be resolved by DNS rather than static logic in libc or mappings in /etc/hosts. In such a case, it might not actually be safe to omit certificate validation checks for that hostname.)

There may already be a bug open for the "exempt certain hostnames" feature, but I can't seem to find it right now. There is a related bug: https://bugs.chromium.org/p/chromium/issues/detail?id=717340

I'll leave this bug open as a potential feature. +some people who know about this stuff

Deleted: self-signed.png 32.1 KB

	self-signed.png 32.1 KB View Download

I generally agree with rsleevi@'s reasoning on Issue 717340 (c#9) that we should focus on supporting and guiding users/developers to a good path rather than supporting every possible development case, particularly here where we might open a complex set of bugs around "local" reserved hostnames (I'll note that I'm not very familiar with the details of these and the DNS resolution for them -- I share the concerns that palmer@ mentioned in c#1).

If we were to go down this route, I think it might be better if instead of exempting these hostnames from certificate validation we instead special-cased them to a kind of "trust-on-first-use" interstitial (which might not even change the duration of the trust, but could have a different wording/expose the proceed button directly). For also handling the concerns in Issue 717340, we might need to treat these exempted page/certificates more leniently for feature access (e.g., being able to install/use service workers), instead of treating them as "dangerous". But this would add a fairly significant complication to our security state and interstitial logic.

This particular proposal is one that's been around for nearly two decades - it's one that cycles through every so often. As noted in Comment #1 and Comment #2, there's no reliable way for a browser to determine what constitutes locally resolved, and even in those situations, what constitutes the 'expected' certificate (even with a TOFU scenario).

palmer@: It's unclear by leaving this open if you agree it's a useful feature? Or were you deferring to other folks to close?

cthomp@: In the case of .example, .test, and .invalid, those should not resolve unless the user has modified their hosts. If they have power to modify their hosts, it seems like they have power to address the trust issues. With .localhost, it will run into the resolution issues mentioned (potentially going over DNS), and that also seems undesirable. I don't think we want to encourage or promote the use of these names.

#4: I defer to the experts on whether we should or should not do this feature.

I'm going to take this one since we're thinking of doing something to aid development (at least having a document with "best practices" for this types of cases), so this can serve as a tracking bug.