Ubuntu 16.04 SSL Cert

Possible Bug :

Did a fresh install, did not set hostname, installed QuickBox on ubuntu 16.04. I changed the hostname with the option during the script, but if i go to the newly created a-record, i get the following :

Attackers might be trying to steal your information from ENTERDOMAINHERE (for example, passwords, messages, or credit cards). NET::ERR_CERT_AUTHORITY_INVALID

Which google chrome is not allowing me to connect.

If i use the IP I can get in fine to the dashboard. I have edited /etc/hosts and added an entry there, and verified that the hostname was changed at /etc/hostname . Everything propagates fine with nslookup and ping, SSH allows me to connect as well.

Not quite sure if what you are reporting is a bug, or standard warning from self-signed issuance. If you are to assign the FQDN an A Record at your DNS provider, it would still produce an error in regards to the cert not being issued by a valid authority.

Although, this does annoy myself and I know there are others out there that are put off by the message, though it is common place with self-signing. This has brought me to potentially providing LetsEncrypt as a function for setting up a proper and free SSL during script install. I might even separate parts of this script for users whom already have QuickBox installed. The only thing that would be needed at that point is a fully qualified domain, as well as a Free DNS provider (of which I recommend CloudFlare)

I think there may even be free domain providers in the form of proxy/sub-domain services (assuming the name isn’t taken)

There could additionally, be a function in the script that asks for an FQDN as well as building the actual SSL, rather than this being used from hosts and the ssl silently self-signed on install.

1 Like

No, it’s not letting me select “Proceed”

Have you flushed the saved certificate sessions from your browsers cache?

Also, is there an exception to this particular domain/ip in your Chrome Advanced Settings?
Settings > Advanced > Privacy > > Notifications >

Something like this with domain/ip set to allow:

I’m trying to reproduce but the only thing I can think of is issues I have had in the past with production sites. Something like an exception being denied in that list… or having HSTS blocking at the DNS level due to the self-signed cert.

Also, see if flushing the browser cache produces more joy and less foobar.

Just as additional verification, I have set an A Record at CloudFlare and it still allows proceeding.