SSL Now Properly Certified. Other Problems Remain.

Submitted by C B Wright on

So I added the new site certificate and everything should be hunky-dory on that front. But I've run into another problem and I hope you can help me troubleshoot it. Strangely enough, it only occurs in Firefox.

Chrome: Type ubersoft.net in your browser. You will be redirected to https://www.eviscerati.org/comics

Firefox: Type ubersoft.net in your browser. You will be redirected to https://www.ubersoft.net and will see an untrusted certificate page.

Firefox: Type paymebug.com in your browser. You will be redirected to https://www.eviscerati.org/fiction/pay-me-bug without any issues whatsoever.

Click "Read More" to see the relevant .htaccess entries.

OK, here is the .htaccess entry for ubersoft.net. This works when you use Chrome, but does not work when you use Firefox.


RewriteCond %{HTTP_HOST} ^ubersoft.net [OR]
RewriteCond %{HTTP_HOST} ^www.ubersoft.net
RewriteRule ^(.*)$ "https\:\/\/www\.eviscerati\.org/comics/$1" [R=301,L]

Here is the .htaccess entry for paymebug.com. This works for every browser, including Firefox:


RewriteCond %{HTTP_HOST} ^paymebug.com [OR]
RewriteCond %{HTTP_HOST} ^www.paymebug.com
RewriteRule ^(.*)$ "https\:\/\/www\.eviscerati\.org/fiction/pay-me-bug" [R=301,L]

The only difference is the /$1 on the end of ubersoft.net -- that allows all the old ubersoft.net links to be converted into new eviscerati.org links (the directory structure is a little different). It works in Chrome, not in Firefox.

Does anybody know why? It's driving me crazy...

Comments

Comments are active for 30 days after publication. If you wish to comment after 30 days please use the Forums.

A few ideas...

I'm not sure what to suggest, as the syntax looks correct. There's a few nitpicky things I could point out (I'll save those for last), but I don't see anything glaring.

The "untrusted certificate" error in Firefox, of course, is because the cert is for eviscerati.org, not ubersoft.net. So it's a name miss-match, not that the cert is invalid. However, since certs are tied to a domain and not an IP or individual server, a name miss-match should be considered untrusted.

The only thing I can think of would be related to how you have your virtual hosts set up, and on that I can only guess without looking directly at your configuration files. On the GPF server, I redirect a bunch of "alias domains" to the main domain in a similar fashion. Each domain has its own virtual host in the main Apache config file. (Since I have root access, I prefer putting these directives in the main config file rather than .htaccess files. The main config gets loaded once when the server gets started, while .htaccess files get read and parsed for ever request under the directory that contains it.) My rules are pretty similar to yours, and in some cases I preserve the request's path like you do for Ubersoft while in others I redirect everything to the root like you do with Pay Me Bug. So I would look to see how you have the "ubersoft.net" and "paymebug.com" virtual hosts configured first and see what's different.

Another thought: There could be a directive somewhere that's getting parsed and executed first that redirects "http://ubersoft.net/" to "https://www.ubersoft.net" before you even get to the directives described above. You'll need to start with your main config file and step through it, including delving into any included files, to see what order things get processed in. That's the only way to know for sure.

Now the nitpicky items:

  • The quotes around the target URLs in both RewriteRules are unnecessary, as are the backslashes. The target URL is not a regex; just the match expression. The quotes are only necessary if the target somehow includes spaces (which a true URL shouldn't anyway).
  • The "^(.*)$" regex in the paymebug.com RewriteRule is also unnecessary, as you're not trying to redirect an old URL. You're redirecting all requests for that domain to a single URL. You can use a simple dash ("-") to signify "everything" in this case. The regex will still work, of course, but it may create unused back-references (the $1 variable and friends) that become just wasted memory.
  • Hope some of this helps....

yeah, but...

... I know the reason why it's throwing the untrusted certificate thing. BUT... it works in Chrome. I use .htaccess to make sure everything redirects to eviscerati.org, which means it should be redirecting to the correct certificate. paymebug.com is the same way -- the domain points to my server's ip address, just like ubersoft.net does, but why does Firefox parse its .htaccess entry properly and not ubersoft.net's?

--
Writer, former musician, occasional cartoonist, and noted authority on his own opinions.

Fixed now?

I just tired ubersoft.net in Firefox and was correctly directed. Could it be that it populated correctly, or perhaps something is in your cache or cookies that is mucking it up?

Still borked for me.

I didn't consider that it might have been just my problem.

... odd.

--
Writer, former musician, occasional cartoonist, and noted authority on his own opinions.

I'm going to echo Jeffrey

I'm going to echo Jeffrey above, it may be something in your Apache config files… Using the domain http://paymebug.com does an immediate redirect to https://www.eviscerati.org/fiction/pay-me-bug

Using the domain http://ubersoft.net first redirects me to https://www.ubersoft.net and then to https://www.eviscerati.org/comics

Using the domain http://www.ubersoft.net redirects to https://www.eviscerati.org/comics with no SSL error.

So far, its the only thing I can think of… :-\

So essentially...

... Firefox is handling the response in a way no other browser is, including Internet Explorer. Sigh. This must be a new feature.

--
Writer, former musician, occasional cartoonist, and noted authority on his own opinions.

Gah... OK, your comment

Gah... OK, your comment system doesn't work the way I expected. Sorry for separate entries.

I think David Ellis has your clue. The rules you quoted above should catch both "ubersoft.net" and "www.ubersoft.net" and redirect them to "www.eviscerati.org". However, the "naked" "ubersoft.net" is redirecting to "www.ubersoft.net" first. That goes back to my "another thought" bit above. You probably have a rule somewhere that's redirecting the naked domain to the "www" domain that's getting executed first before the rules quoted above. You'll need to find that rule and remove it (or at least comment it out) so this rule is the first one that gets hit when a request comes in for "ubersoft.net".

As for why different browsers handle things differently... dude, you and I were both around when everyone was complaining about Netscape 2.x and IE 1.x not working the same way. You should be used to that by now. ;) I couldn't tell you why specifically, but my guess is that Chrome tries to handle things as transparently as possible, while Firefox tries to be as strict as possible. Chrome likely hides the ubersoft.net -> www.ubersoft.net -> www.eviscerati.org transition, only showing the end result. Firefox tends to be pretty strict, so it likely doesn't hide it, throwing the error. It's just a guess, but it's the best I have without parsing each individual step.

For the record, IE 9, Safari 5, and Opera 12 all on Win7 operate the same as Chrome, making the transition transparent. Even the old text browser Lynx on Linux seems to do the same. I'd have to do some deep analysis to figure out why Firefox is working differently.

I can see your point...

More information...

Type "ubersoft.net" in Firefox and it automatically appends the "/" (so it's "ubersoft.net/")
... but if you delete the "/" then it works just fine.

Chrome, by default, doesn't use the "/" and if you try to type in "ubersoft.net/" it removes the "/".

If you type in "http://ubersoft.net/", however, it gives you exactly the same redirect problem as firefox.

So it's not browser-specific. You just have to work harder to reproduce it.

Except that when you type "thepointsbetween.com/" directly into Firefox, IT STILL WORKS. AUGH!

If it's something happening before .htaccess even comes into play, then it's an Apache thing. But I don't know where to look.

--
Writer, former musician, occasional cartoonist, and noted authority on his own opinions.

OK, I figured part of it out.

So the reason Firefox adds that trailing "/" has to do with the Privacy tab in the Firefox Preferences dialog. When I set the "Location Bar" drop-down to "Nothing" it will not add the trailing slash.

This does not explain why the trailing slash is causing the problem. I'm also not sure why Firefox is so damn sure I want a trailing slash at the end of the URL. Also, I can't very well expect every Firefox user to go into their Privacy settings and make the same change. Maybe they like having the location bar remember their link history, so they only have to type a few letters of a URL to get it to load.

So I still have to solve the problem.

--
Writer, former musician, occasional cartoonist, and noted authority on his own opinions.

OK, one more thing.

So with the location bar setting set to "nothing," if I type "ubersoft.net/" into the location bar, do you know what happens?

IT REDIRECTS NORMALLY.

... I have a headache.

--
Writer, former musician, occasional cartoonist, and noted authority on his own opinions.

Gremlins then...

... I'm going to have to chalk up the entire thing to gremlins.

--
Writer, former musician, occasional cartoonist, and noted authority on his own opinions.

Found the issue.

Firefox tries to match it with the most recent bookmark or history item, this has https in so firefox basically goes to the bookmark/history url straight to the https site. This is good from a security standpoint acting somewhat like HSTS (only without the compulsory nature).

The good news is that this won't effect new visitors, old visitors should clear their ubersoft.net entries out of their history and update any bookmarks.

Genius!

Thank you sir. So it *is* Firefox's fault! :D

--
Writer, former musician, occasional cartoonist, and noted authority on his own opinions.

Yeah, now I wonder why the

Yeah, now I wonder why the first 2 comments didn't post? Very strange.

Also I would suggest you send HSTS headers (only applies for a full SSL/TLS connection with properly validated certificates) so chrome/firefox go straight to https:// on eviscrati.org on subsequent visits.

That sounds like a great idea...

... how do I do that? Assume I'm clueless. Because basically I am. ;-)

--
Writer, former musician, occasional cartoonist, and noted authority on his own opinions.

Oh!

Hey, that looks easy. I mean, every time I say that I wind up doing something horribly wrong, but it really, really does look easy. Thanks for the link!

--
Writer, former musician, occasional cartoonist, and noted authority on his own opinions.

It's fairly self explanatory,

It's fairly self explanatory, max-age is in seconds, includeSubdomains is optional to if you want to apply it to the subdomains. It needs to be sent in https headers (probably a seperate apache vhost. It's totally irrelevant if they are seen on HTTP too before the redirect).

This is from http://dev.chromium.org/sts : "When the browser sees this, it will remember, for the given number of seconds, that the current domain should only be contacted over HTTPS. In the future, if the user types http:// or omits the scheme, HTTPS is the default. In fact, all requests for URLs in the current domain will be redirected to HTTPS. (So you have to make sure that you can serve them all!)."

Oooh. Actually...

... I may not want to do that.

If it does that for EVERYTHING then it will try to connect to RSS feeds over https, and that breaks the RSS standard (things like feedburner, etc. do not support https.

Is this *only* for Firefox and Chrome? Might be worth it then, but if other technologies adopt this standard it might kill my feeds if I use it.

--
Writer, former musician, occasional cartoonist, and noted authority on his own opinions.

It gets ignored by browsers

It just gets ignored by HTTP clients that don't understand it, currently supported are firefox 4+ or Firefox with HTTPSEverywhere or NoScript, Google Chrome 4+ (and any chromium based browser) and Opera 12+. So firefox or google chrome will load the feed over HTTPS, the rest will go on as they always have.

The only caveats are if you have a page only available on HTTP, and the browser is going to enforce https unless max-age has run out since the last load from the domain over HTTPS.

Finally, the browser only remembers it if it saw it on HTTPS in the first place and if the certificate validated okay and no certificate exception is in place.

Not that I want to throw more

Not that I want to throw more fat on this fire or anything, but...

I'm using the latest version of Chrome, and my bookmark points at: https://www.ubersoft.net ...and I got the untrusted site warning.

Well I recommend...

... editing the bookmark to remove the https. That should work.

--
Writer, former musician, occasional cartoonist, and noted authority on his own opinions.