4 ms·
You can always manually trust certificates via various means, it's the basis for almost any corporate network, most browsers also offer a simply dialog to bypas
by tscs37 8y ago
You can always manually trust certificates via various means, it's the basis for almost any corporate network, most browsers also offer a simply dialog to bypass certificate warnings.
- detaro 8y agoYou can also just use HTTP, since sci-hub doesn't force HTTPS.
- 0x00000000 8y agoBrowsers seem to be moving towards making it harder to bypass, which is probably a good thing for the average user. I wouldn't be surprised to see the ability to ignore https errors (or access http sites at all) locked behind a developer setting or something.
- tscs37 8y agoOn Chrome I can see that but I doubt Firefox would make that move. Plus, they won't remove the functionality to manually trust a cert (Business Users would complain).
- Sir_Substance 8y ago> On Chrome I can see that but I doubt Firefox would make that move. Firefox has implemented the same rules around .dev tld's as google. I use vivaldi when accessing internal company .dev domains because firefox won't let me tell it to accept the self-signed certificate.
- detaro 8y agoAn option could be to use certificates signed by a self-signed CA added to your trust store.
- Sir_Substance 8y agoThat's exactly how it's set up. Doesn't help, I'm apparently not allowed to tell my browser what to do in this instance.
- pfg 8y agoFirefox will happily accept self-signed certificates chaining to manually imported CAs. However, there are a lot of severely outdated guides on creating self-signed certificates out there, and many of the certificates produced that way won't be accepted by any modern browser. OpenSSL's terrible command-line UX certainly doesn't help matters. I've found easypki[1] to be the most convenient tool for this purpose. [1]: https://github.com/google/easypki https://github.com/google/easypki
- tialaramex 8y agoThe person you're replying to doesn't have any problem with certs. Their problem is that they (or their employer) hijack a TLD for whatever ludicrous reason, and HSTS pre-loading applies to their hijacked names the same as it would to real names.
- Kadin 8y agoAh, got it. Well, another argument in favor of not overloading TLDs for internal domains, then, and just buying an additional domain if you really want to have separate internal and external domains.
- pfg 8y agoAre you sure? The initial post was about .dev being HSTS-preloaded, but the comment I was replying to was an answer to the suggestion that they could use self-signed certificates after importing them to the trust store.
- Sir_Substance 8y agoYeah, and having read over this thread about three times I'm actually less sure than I was. I'll be checking today.
- tscs37 8y agoIIRC that's because Mozilla sources their HSTS Preload List from Chromium
- ceejayoz 8y agoChrome's already moving in this direction. Bypassing a HSTS error means you have to type "thisisunsafe", and they change the keyword sometimes (it used to be "badidea").
- detaro 8y agoFirefox makes working around HSTS even harder. But to be fair, HSTS is the domain owner explicitly declaring "do require a valid certificate here!".
- fasj82 8y agoTo disable HSTS permanently just do this: https://security.stackexchange.com/a/102315 https://security.stackexchange.com/a/102315
- userbinator 8y agoAs a user, it's hard to bypass, but as a developer, it is literally easier to "crack" the browser by patching the jump/value to always go to "cert is good" than try to find and make the corresponding changes in the source and then figure out how to recompile everything else identically. I'm not sure what to think of that...