PfSense Source - Mirror downloads - NET::ERR_CERT_COMMON_NAME_INVALID
-
Chrome - Version 45.0.2454.101 m - will not allow downloads from Austin or Kentucky.
Went to the devil's side and ran MS Edge and it downloaded!!
Turning pfBlocker and Snort back on since that was not the hang up.
-
Dude, there are NO https links whatsover. Uninstall your broken addon forcing HTTPS where none should be forced. Third one in two weeks or so. Why people install utter crap in their browsers?
-
Here we go again. Maybe a dozen people seeing this and no clue why, it's 100% certain it's not coming from us as we never link those as HTTPS. What extensions do you have in your Chrome? Does it happen in your Chrome when in incognito mode?
-
Went into Chrome and made the following changes:
1. Thought it was Privacy Badger - turned off - no change left as such.
2. Protect you and your devices from dangerous sites - unchecked
3. Cleared browsing history
4. Manage HTTPS/SSL - manager certificates - 'removed' a single Personal tab certificate??
5. restarted Chrome and then it downloaded while in HTTPS mode -Conclusion 1: It has nothing to do with "Dude… HTTPS Why people put this crap in your browser?"
I am sure we can narrow this down but I have billable work to get done.
-
Previous reports of people trying to download something via HTTPS when that protocol wasn't in use were found to be browser plugins like HTTPS Everywhere. Check the simple stuff first.
-
@cmb:
Here we go again. Maybe a dozen people seeing this and no clue why, it's 100% certain it's not coming from us as we never link those as HTTPS. What extensions do you have in your Chrome? Does it happen in your Chrome when in incognito mode?
IMHO if your server is public-facing and is responding to HTTPS requests on TCP/443 it should have a valid certificate installed.
-
Conclusion 1: It has nothing to do with "Dude… HTTPS Why people put this crap in your browser?"
Look at the source of the mirror page. You are clicking on an http link and YOUR BROWSER is changing it to https.
-
I see this behaviour in Chrome sometimes. I go to the webconfig of a hardware device on my network and assume it's HTTPS when it's HTTP. From then on, any reference to that URL in Chrome comes up as HTTPS, and not HTTP. It's like it remembers the very first protocol specified even if it fails to connect and refuses to update when a connection is successful.
-
I am sure we can narrow this down but I have billable work to get done.
Yeah. It was already found. You are downloading something via HTTPS when you are not supposed to. There's nothing linking to HTTPS. When you decide to use HTTPS when not told to, then pick up the pieces and deal with the certificates prompt. WTF.
-
IMHO if your server is public-facing and is responding to HTTPS requests on TCP/443 it should have a valid certificate installed.
They have valid certificates installed. Wildcard certs just don't match subdomains.
Thanks to doktornotor who I believe found what was causing the issue. We've had HSTS enabled for quite some time, with includeSubdomains which is undesirable in this case. How that only applies very sporadically to only a very small portion of people I'm not sure, but I'm pretty sure that's the source of the issue. includeSubdomains has been disabled now, so hopefully this goes away. I never saw it anywhere to begin with so not sure whether or not that's really the case, but it appears to be. If anyone can confirm, it'd be appreciated.
-
@cmb:
IMHO if your server is public-facing and is responding to HTTPS requests on TCP/443 it should have a valid certificate installed.
They have valid certificates installed. Wildcard certs just don't match subdomains.
Then it's invalid for the host answering. :/
Hopefully your HSTS wasn't set to something like forever.
-
