Opened 5 years ago

Last modified 5 years ago

#9837 assigned Bug/Something is broken

* forwards to untrusted https

Reported by: Owned by:
Priority: Urgent Component: Tech
Keywords: subdomain ssl Cc:
Sensitive: no

Description (last modified by

Hello there,

I've got a site on ossie I'm getting set up,, but whenever I enter that URL, it forwards to https.

I ain't seeing https in the apache config.

Is this a bug or is this "works as designed?"

Specifically, I see this error, "The certificate is only valid for the following names:,"

Firefox isn't offering to let me add an exception as it normally does with self-signed certs, and I actually just tried to add an exception manually and it won't let me.

Peace, jj

Change History (20)

comment:1 Changed 5 years ago by

  • Description modified (diff)

comment:2 Changed 5 years ago by

  • Description modified (diff)

comment:3 Changed 5 years ago by

  • Description modified (diff)

comment:4 Changed 5 years ago by

  • Keywords subdomain ssl added
  • Owner set to
  • Status changed from new to assigned

Hi Jeremy,

I'm looping Ross in to answer your ticket.


comment:5 Changed 5 years ago by

Hi jj,

I think this must be something specific with your version of firefox. I am not getting the behavior you describe. Can you try to open a new profile in firefox and test the address:

firefox --no-remote -ProfileManager

Let me know,


comment:6 Changed 5 years ago by

  • Resolution set to invalid
  • Status changed from assigned to closed

Well I'll be. Yep, it's Firefox. Opening in a new profile with no settings fixes the problem. That is, it doesn't forward from http to https.

Closing as invalid. If I come up with the particular extension that's at fault I'll post that here.

Thanks for your help!

Odd behavior, didn't suspect the browser and can't think of an extension that would be the culprit.


comment:7 Changed 5 years ago by

  • Resolution invalid deleted
  • Status changed from closed to assigned

Hey all,

I ran into a similar issue a couple of weeks back when trying to visit and it also was pointing me to the https for the site, which is not configured. Upon chat conversation with ross I too did the same thing and changed my profile and that seemed to resolve the issue until yesterday when it happened again. This is also happening on The catch is that i am certain this is Iceweasel/Firefox related as I visited both sites successfully in chromium when entering & but when I visit in Iceweasel it redirects to the https://<version of both above listed sites>

I am at a loss on what to do but felt this should be reopened to further investigation.


comment:8 Changed 5 years ago by

Okay, we tracked down a defining symptom of this problem. Apparently, anything with a sub-domain produces this behavior when the firefox/iceweasel instance is in the redirect state. I'm not sure why this is, but it definitely is related to how firefox is handling redirecting to https versions of

Still trying to figure this out,


comment:9 Changed 5 years ago by

hm, first off, we shouldn't have any MF/PL sites that involve authentication over http in the first place. secondly, should probably be

It looks to me like the redirection is done because we're now mentioning includeSubDomains in the STS header for

0 dkg@alice:~$ wget -O- -q -S 2>&1 | grep Strict-Transport
  Strict-Transport-Security: max-age=31536000; includeSubDomains
0 dkg@alice:~$ 

I'm a little surprised by this -- i would have thought that we didn't want to includeSubDomains for, since we have so many end-user sites that probably don't do https. Maybe this happened as a result of the implementation of #9777? But i don't see any documentation of that decision. Was there discussion about this tradeoff somewhere else?

Anyway, that max-age is a full year, so we've publicly committed to it for the next 365 days for anyone who has ever visited Not sure what the best next thing to do is...

comment:10 Changed 5 years ago by

Yes this is a result of #9777, thanks for figuring this out dkg. I wonder why firefox seems to exhibit this behavior but chromium does not.

comment:11 Changed 5 years ago by

  • Priority changed from Medium to Urgent

hi, apparently this issue if affecting which is redirecting to and now shows "Unable to connect" error message.

Unfortunately today (in 30min), a working group of Mutual Assistance Technical Communities had scheduled to run a test of evaluation of BBB in this instance, with participation of more-less ten persons of different latinamerican countries.

  • Is there a chance we could put back online in a few minutes?
  • Do we have another instance available to share with this working group?

I will ask Apolinar about the condition of this installation.

comment:12 Changed 5 years ago by


BBB is still on line, you just need to use another firefox profile or a different browser.


comment:13 Changed 5 years ago by

From the above: "Anyway, that max-age is a full year, so we've publicly committed to it for the next 365 days for anyone who has ever visited ​"

Are we saying that anybody who has in their browser history will now hit an error on any subdomain of until they clear their browser's history of visited sites? Seems like that would affect a fair number of people involved with mayfirst, possibly even strangers that would think that various MF hosted sites were down.

I don't know how difficult this would be, but it seems that a fix for this could be allowing https for all subdomains.

comment:14 Changed 5 years ago by

Hi Jeremey,

There are probably too many sub-domains for this to be viable. I've been experimenting with firefox, and what I've determined is that you can remove the permissions.sqlite file from your ~/.mozilla/firefox/profile, and the problem is resolved. It also may be possible to go to about:permissions and choose "Forget About This Site", for to resolve the problem.

I have not experienced the problem in chromium, so I'm not sure what would be the fix there.


P.S. I have removed the includeSubDomains directive for

Last edited 5 years ago by (previous) (diff)

comment:15 follow-up: Changed 5 years ago by

hm, i recommend strongly against removing permissions.sqlite -- that database is probably quite useful for many other things, and removing it is pretty drastic.

Instead, go visit and hard-refresh the page.

since ross removed includeSubDomains from, that should reset the flag in your browser's history.

after that, visiting should *not* get an automatic redirection. if it still does, then you might try closing your browser and restarting it -- i haven't tested how the caching of this info works.

comment:16 in reply to: ↑ 15 Changed 5 years ago by

Replying to

hm, i recommend strongly against removing permissions.sqlite -- that database is probably quite useful for many other things, and removing it is pretty drastic.

As far as I can tell this database creates default site permissions for a small sub-set of sites one visits. Unless you've done some significant modifications to your permissions, I don't think it's that drastic to have this database re-created.

comment:17 Changed 5 years ago by

0 dkg@alice:~$ echo .dump | sqlite3 .mozilla/firefox/*.default/permissions.sqlite | wc -l
0 dkg@alice:~$ 

that seems like a lot of data to discard when you just want to tweak one setting which should be tweakable by revisiting a single webpage.

comment:18 Changed 5 years ago by

Yes dkg, you should not remove your permissions.sqlite file. Mine was about 1/20th the size of yours. Yet again proving that size does matter! :-)

comment:19 Changed 5 years ago by

btw, i tested the suggested workflow from comment:15 (without a browser restart), and it is sufficient to fix the reported problem.

comment:20 Changed 5 years ago by


I can confirm that too! good work both of you on debugging this thing :)


Please login to add comments to this ticket.

Note: See TracTickets for help on using tickets.