User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050124 Firefox/1.0+ Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050124 Firefox/1.0+ In the URL listed, "https://sannas.ca/2005/ffbug.html/" this page loads correctly, however a second after it does, for some reason it attempts to connect to some page at "https://www.sannas.ca". The certificate that this domain is using only covers the domain "sannas.ca" and not "www.sannas.ca" which results in an error. Note that this page has absolutely no external references. I tried forcing a favicon fetch on the "sannas.ca" domain and this error still occured. This error occured on the Nightly builds of both Firefox and Mozilla. Reproducible: Always Steps to Reproduce: 1. Go to https://sannas.ca/2005/ffbug.html 2. If you say cancel, you can view the page fine, until you attempt to grab another page off of the site. More generic reproduction steps: 1. Create a web page at "domain.com" 2. Setup a domain specific certificate for "domain.com", such as SSL123 through Thawte 3. Point firefox or mozilla at "https://domain.com" 4. Get an error about "https://www.domain.com" not being secured properly. 3. Actual Results: I get this message, even though I never attempted to access "www.sannas.ca", just "sannas.ca". You have attempted to establish a connection with "www.sannas.ca". However, the security certificate presented belongs to "sannas.ca". It is possible, though unlikely, that someone may be trying to intercept your communication with this web site. If you suspect the certificate shown does not belong to "www.sannas.ca", please cancel the connection and notify the site administrator. Expected Results: Should have loaded the certificate correctly, and not attempted to contact "www.sannas.ca" after resolving, connecting and fetching entire page from "sannas.ca" I've been in contact with Thawte, and they claim that the certificate is installed correctly. These pages all work as expected on Internet Explorer 6.0. The workaround is to essentially have a certificate that covers both domains. I havn't attempted it, but assumingly moving the certificate to cover the "www" version of the domain might fix it as well.
The agressive favicon loading from Firefox results in a redirect with a domain mismatch. HTTP request sent, awaiting response... 302 Found Location: https://www.sannas.ca/error_docs/not_found.html [following] That's the reason why this works in Mozilla but not with firefox.
Assignee: firefox → bugs
Status: UNCONFIRMED → NEW
Component: General → Location Bar and Autocomplete
Ever confirmed: true
QA Contact: general → davidpjames
Summary: attempts to add "www." to domain even when resolve is successful without it → Favicon request is causing a Domain Mismatch Error
Strange, I received the same error with Mozilla. Confirmed, I created another page at https://sannas.ca/2005/ffbug2.html with a favicon reference that exists. This is a possible workaround, however any response from the favicon fetch that doesn't result in an icon coming back without an error should be ignored should. This icon is never requested by the user, and therefore adds to confusion when they're told they can't have it.
"Strange, I received the same error with Mozilla." Only if you changed the hidden favicon settings because Mozilla only fetches favicons if they are referenced in the page. "This icon is never requested by the user" -> That doesn`t matter if it's requested by the document via link.
Mass edit: Changing QA to default QA Contact
QA Contact: davidpjames → password.manager
Mass edit: Setting correct QA for location bar/autocomplete. My bad. I forgot I had once been Autocomplete QA too. Hmm, why can't I just set the QA of bugs to the default QA of the component in a mass edit rather than having to do it manually...?
QA Contact: password.manager → location.bar
I am unable to connect to the test page (https://www.sannas.ca/) - I get a 404. I don't think there's anything actionable in this bug.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.